Hi Peter, I've created a couple of implementation of the Brooklyn SecurityProvider. None of them are listed in catalog, so i don't think it is related. I suppose it is typo, but for removing bundles you have to use `bundle:uninstall`. `delete` is for deleting configurations. I've never used it,
What do you mean with "it remembers the previous version"? Does it give you an error message? The ID are sequential, so each time you restart the server after, probably you will get always the same ID due to it's the next available. Having more than one bundle with the same packages inside always gave me weird problems. Sorry Peter, I feel not very useful with this notes. I something gives you a clue. Juan On Wed, 28 Aug 2019 at 21:56, Peter Abramowitsch <[email protected]> wrote: > Hi Juan > Sorry it's taken me a while and thanks for your encouragement. I've done > the things you've suggested and they check out, but before getting back to > you, I just wanted to make sure that it wasn't some stupid mistake I've > been making. > > 454 │ Active │ 80 │ 1.0.0 │ ucsf_secrets_osgi > 475 │ Active │ 80 │ 1.0.1 │ ucsf_secrets_osgi > > I had a couple of questions. > > 1. In trying to clear out previous versions of my plugin, I've used > karaf:bundle:delete ..... and it works in the sense that when I do a > bundle list, the plugin is no longer there, But when I do a catalog add, > it still remembers the previous version. Even after clearing out the > entire data/cache it still seems to remember. My only recourse is to keep > bumping up the version number. Is this normal? > > 2. A related question, catalog add does add my plugin, but it doesn't > know what catalog type it is, and therefore I can not actually see my > provider in the catalog, even though karaf sees it as a bundle. For an > external provider, is this normal? Or do I need to add something in the > Manifest to say that my provider is actually an Entity or something else? > > This missing type may be the key to other problems, but the documentation > doesn't say what the catalog type should be > > Peter > > Peter > > > > On Wed, Aug 28, 2019 at 9:03 AM Juan Cabrerizo <[email protected]> wrote: > > > Hi Peter, > > Lets check the bundle is active and the class is exporter: > > > > From the Karaf console, you can run > > bundle:list -s | grep ctakes_auth_osgi > > > > The output should be similar to > > 127 ? Active ? 80 ? 2.1.0 ? <symbolic name> > > The first column is the bundle ID and the third the status. It must be > > active. > > > > It it is, running > > bundle:classes <bundle ID> > > You can see if your class is exported or not, but i think, looking to the > > manifest, it should be exported, you can grep the output if you have too > > much classes. > > > > To be sure that each server reboot is clear, i used to remove he content > of > > the data folder and the .brooklyn. May you are right and the class has > been > > cached somewhere. > > > > I hope this helps you to dig into the problem. > > > > Juan > > > > > > On Wed, 28 Aug 2019 at 00:43, Peter Abramowitsch < > [email protected]> > > wrote: > > > > > Hi Alex > > > > > > Progress but still very frustrating.... > > > > > > Finally created an osgi bundle with this manifest: > > > > > > Manifest-Version: 1.0 > > > Bundle-ManifestVersion: 2 > > > Bundle-Name: ctakes_auth_osgi > > > Bundle-SymbolicName: ctakes_auth_osgi > > > Bundle-Version: 1.0.0 > > > Export-Package: org.ucsf.ctakes_auth > > > Bundle-Vendor: Ucsf Bakar Institute > > > > > > From the dropins folder, it doesn't seem to be found, but using "br > > catalog > > > add" I can add it if I comment out the forward reference to it in > > Brooklyn > > > config and restart the server > > > > > > I can then see with karaf "classes" that my provider class has been > > found > > > > > > org/ucsf/ctakes_auth/AuthEncoder.class > > > org/ucsf/ctakes_auth/AuthEncryptor.class > > > org/ucsf/ctakes_auth/UcsfSecretsBuilder.class > > > org/ucsf/ctakes_auth/UcsfSecretsProvider.class <<<<<<< > > > karaf@brooklyn()> quit > > > > > > But when I refer to it in brooklyn.cfg > > > > > > > > > > > > brooklyn.external.ucsfsecrets=ctakes_auth_osgi:org.ucsf.ctakes_auth.UcsfSecretsProvider > > > > > > and restart the server, I get this: > > > > > > No class 'org.ucsf.ctakes_auth.UcsfSecretsProvider' in bundle > > > 'ctakes_auth_osgi' (using spec > > > 'ctakes_auth_osgi:org.ucsf.ctakes_auth.UcsfSecretsProvider') > > > > > > Am I going blind? > > > > > > One question: I have supplied my class's external dependencies, > > standard > > > jars like log4j2 and other stuff as jars in the lib/boot area. I have > > not > > > created an Import-Package entry in my bundle's Manifest. I read that > > this > > > should work. > > > > > > What's so odd is that yesterday I was getting much further - even > without > > > packaging my jar as an osgi bundle, and then everything stopped and it > > was > > > no longer found, as if it had been added to a blacklist somewhere. Is > > that > > > possible? > > > > > > Peter > > > > > > > > > > > > On Tue, Aug 27, 2019 at 9:33 AM Alex Heneveld <[email protected]> > wrote: > > > > > > > Hi Peter, > > > > > > > > It needs to be the JAR not the class. Either the dropins folder or > 'br > > > > catalog add' is fine. You can confirm the former in the karaf > > bin/client > > > > bundle:list or the latter in the Brooklyn catalog UI view. > > > > > > > > It may be that the reference in OSGi needs to be to > > > > 'your.bundle:package.Clazz'. > > > > > > > > Let us know how that goes. > > > > > > > > If someone could improve the docs here that would be great (including > > > > saying to put an OSGi bundle JAR not the classes into dropins!). > > > > > > > > Best > > > > Alex > > > > > > > > On Tue, 27 Aug 2019, 17:47 Juan Cabrerizo, <[email protected]> > wrote: > > > > > > > > > Hi Peter, I've installed it in two different way, but i'm using the > > > > drop-in > > > > > folder. (btw i think the current path is /deploy, or at least is > > what i > > > > > tried to use at seems working, but i found other unrelated > problems) > > > > > The easier way is using the CLI, running > > > > > * br login <SERVER> > > > > > * br catalog add <path to jar> > > > > > > > > > > The other approach i've used is installing it on the Karaf repo > > inside > > > > the > > > > > system folder and modify the brooklyn default feature. But this way > > is > > > > > error prone. I can give you more details if you need, but i > recommend > > > you > > > > > use the BR command. > > > > > > > > > > You can run the Karaf client to list the bundles and classes > > installed. > > > > Is > > > > > how I check if my classes are exported or not. > > > > > For that. you have to execute the script `client` in the bin > folder. > > It > > > > > will open the console. For listing the classes use the `class` with > > > grep: > > > > > class | grep -i UcsfSecretsProvider > > > > > if you don't grep the output it will take ages to cancel it. If you > > > class > > > > > is there, check it it is exported. > > > > > > > > > > I'm not sure if you only need to create a jar file with your > > > > > implementation. I think you check to be sure that this jar file is > a > > > > valid > > > > > OSGi bundle. Using the parent project I said before shall do it. > > > > > > > > > > Juan > > > > > > > > > > > > > > > > > > > > On Mon, 26 Aug 2019 at 17:16, Peter Abramowitsch < > > > > [email protected]> > > > > > wrote: > > > > > > > > > > > Hi Juan > > > > > > Thanks for responding. Your note implied something I was > > suspecting.. > > > > > The > > > > > > documentation literally says "Classes implementing this > interface > > > can > > > > be > > > > > > placed in the lib/dropins folder of Brooklyn" and that's what I > > > > initially > > > > > > did. But your note suggested its a jar file containing the > > > > > implementation > > > > > > class (and its dependencies) that needs to be put in lib/dropins > - > > > not > > > > > > naked class files > > > > > > > > > > > > So this morning I created a runnable jar with a no-op main method > > in > > > > the > > > > > > provider class. This guarantees that the provider and all its > > > > > dependencies > > > > > > are pulled into the jar. > > > > > > > > > > > > I verified this too, with jar > > > > > > jar tvf ./lib/dropins/ucsf_auth.jar | grep UcsfSecretsProvider > > > > > > 9673 Mon Aug 26 08:26:04 PDT 2019 > > > > > > org/ucsf/ctakes_auth/UcsfSecretsProvider.class > > > > > > > > > > > > So my problem seems to be elsewhere. > > > > > > > > > > > > In your implementation, did you put your security provider jar > in a > > > > > > ./lib/dropins of your Brooklyn install folder? > > > > > > Did you have to add a whitelist entry for your jar file anywhere > > > else? > > > > > > > > > > > > Peter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 26, 2019 at 2:28 AM Juan Cabrerizo < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > Hi Peter, > > > > > > > > > > > > > > I found a similar problem when I started working in an > > > implementation > > > > > of > > > > > > > SecurityProvider. My problem was the configuration of the > > > > > > > maven-bundle-plugin i wasn't exporting the class. You can check > > it > > > on > > > > > the > > > > > > > Manifest.MF file inside META-INF on the jar file. Look for the > > > > package > > > > > > > "org.ucsf.ctakes_auth" in the block "Export-Package" > > > > > > > > > > > > > > I solved it setting brooklyn-downstream-parent as parent > project. > > > I't > > > > > is > > > > > > > configured by default for exporting the classes built. > > > > > > > > > > > > > > <parent> > > > > > > > <groupId>org.apache.brooklyn</groupId> > > > > > > > <artifactId>brooklyn-downstream-parent</artifactId> > > > > > > > <version>1.0.0-SNAPSHOT</version> > > > > > > > </parent> > > > > > > > > > > > > > > I hope this helps > > > > > > > > > > > > > > Juan > > > > > > > > > > > > > > > > > > > > > On Sun, 25 Aug 2019 at 05:08, Peter Abramowitsch < > > > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi All > > > > > > > > > > > > > > > > I have created a small secrets provider and unit tested it on > > > it's > > > > > own > > > > > > > > first. But I am having an issue with Brooklyn loading up my > > > class > > > > > and > > > > > > > its > > > > > > > > dependencies. > > > > > > > > > > > > > > > > Following the instructions, I put the class file into a new > > > dropins > > > > > > > folder > > > > > > > > inside lib. And added a call to the provider in brooklyn.cfg > > > > > > > > > > > > > > > > >> > > > > > > > > > brooklyn.external.ucsfsecrets=org.ucsf.ctakes_auth.UcsfSecretsProvider > > > > > > > > > > > > > > > > I then put the class's dependent jars in the lib/boot folder. > > > Not > > > > > sure > > > > > > > > whether they should be there or in lib itself... because I'm > > not > > > > sure > > > > > > > which > > > > > > > > classloader the dropins will be using > > > > > > > > > > > > > > > > Because I wasn't sure what dropins was expecting, I put the > > class > > > > in > > > > > > > twice, > > > > > > > > as you see > > > > > > > > > > > > > > > > lib/dropins > > > > > > > > ├── UcsfSecretsProvider.class > > > > > > > > └── org > > > > > > > > └── ucsf > > > > > > > > └── ctakes_auth > > > > > > > > └── UcsfSecretsProvider.class > > > > > > > > > > > > > > > > My provider needs a couple of JVM defines, so I added these > to > > > the > > > > > > setenv > > > > > > > > script. > > > > > > > > > > > > > > > > On startup, the exception blew up the launch of the Brooklyn > > > > > container > > > > > > > > > > > > > > > > My error message is this Exception ( I put the entire trace > > at > > > > the > > > > > > > bottom > > > > > > > > of this message) > > > > > > > > > > > > > > > > .... > > > > > > > > 2019-08-24T20:47:24,463 ERROR 123 > > > > > > > > o.a.b.c.m.i.BasicExternalConfigSupplierRegistry > > [FelixStartLevel] > > > > > > Failed > > > > > > > to > > > > > > > > instantiate external config supplier named 'ucsfsecrets': > > > > > > > > java.lang.ClassNotFoundException: Class > > > > > > > > org.ucsf.ctakes_auth.UcsfSecretsProvider not found on the > > > > application > > > > > > > class > > > > > > > > path, nor in the bundle white list. > > > > > > > > java.lang.ClassNotFoundException: Class > > > > > > > > org.ucsf.ctakes_auth.UcsfSecretsProvider not found on the > > > > application > > > > > > > class > > > > > > > > path, nor in the bundle white list. > > > > > > > > > > > > > > > > The exception mentions a "bundle whitelist" which I don't see > > > among > > > > > any > > > > > > > of > > > > > > > > the config files in $BROOKLYN_HOME/etc. I also looked at > the > > > > unit > > > > > > test > > > > > > > > for drop-ins in the Brooklyn source, but was unable to relate > > > that > > > > to > > > > > > my > > > > > > > > situation. > > > > > > > > > > > > > > > > Clearly there is more to a custom provider than I see in the > > > > > > > > documentation. Do you have any more information to help me > > out? > > > > > > > > > > > > > > > > Many thanks in advance, Peter > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > > > > > > > > > > > > :`Caused by: java.lang.ClassNotFoundException: Class > > > > > > > > org.ucsf.ctakes_auth.UcsfSecretsProvider not found on the > > > > application > > > > > > > class > > > > > > > > path, nor in the bundle white list. > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.brooklyn.util.core.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:162) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.brooklyn.core.mgmt.internal.BasicExternalConfigSupplierRegistry.updateFromBrooklynProperties(BasicExternalConfigSupplierRegistry.java:116) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.brooklyn.core.mgmt.internal.BasicExternalConfigSupplierRegistry.<init>(BasicExternalConfigSupplierRegistry.java:61) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.brooklyn.core.mgmt.internal.AbstractManagementContext.<init>(AbstractManagementContext.java:183) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.brooklyn.core.mgmt.internal.LocalManagementContext.<init>(LocalManagementContext.java:170) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.brooklyn.launcher.common.BasicLauncher.initManagementContext(BasicLauncher.java:524) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.brooklyn.launcher.common.BasicLauncher.startPartOne(BasicLauncher.java:392) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.brooklyn.launcher.osgi.OsgiLauncherImpl.startPartOne(OsgiLauncherImpl.java:79) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.brooklyn.launcher.osgi.OsgiLauncherImpl.initOsgi(OsgiLauncherImpl.java:105) > > > > > > > > ~[?:?] > > > > > > > > at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > > > > Method) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > > > > > ~[?:?] > > > > > > > > at java.lang.reflect.Method.invoke(Method.java:498) > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:299) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:980) > > > > > > > > ~[?:?] > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:736) > > > > > > > > ~[?:?] > > > > > > > > ... 37 more > > > > > > > > 2019-08-24T20:47:24,486 INFO 15 > > > o.a.a.b.c.BlueprintContainerImpl > > > > > > > > [FelixStartLevel] Bundle > org.apache.brooklyn.karaf-start/0.12.0 > > > is > > > > > > > waiting > > > > > > > > for dependencies > > > > > > > > > [(objectClass=org.apache.brooklyn.launcher.osgi.OsgiLauncher)] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Juan Cabrerizo > > > > > > > Software Engineer > > > > > > > > > > > > > > *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the > > > Cloud > > > > > > > E: [email protected] > > > > > > > L: https://www.linkedin.com/in/juancabrerizo/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Juan Cabrerizo > > > > > Software Engineer > > > > > > > > > > *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the > Cloud > > > > > E: [email protected] > > > > > L: https://www.linkedin.com/in/juancabrerizo/ > > > > > > > > > > > > > > > > > > -- > > Juan Cabrerizo > > Software Engineer > > > > *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud > > E: [email protected] > > L: https://www.linkedin.com/in/juancabrerizo/ > > > -- Juan Cabrerizo Software Engineer *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud E: [email protected] L: https://www.linkedin.com/in/juancabrerizo/
