Thanks Geoff That helps! It's nice to be able to re-start with a clean 1.0.0 on a component after a long period of experimentation and intermediate versions.
Peter On Thu, Aug 29, 2019 at 2:33 PM Geoff Macartney <[email protected]> wrote: > > karaf:bundle:delete ..... But when I do a catalog add, it still > remembers the previous version. > > The karaf command just removes the bundle from Karaf, but the catalog data > is held by Brooklyn itself. There is a "br catalog delete" command to > remove entries from the catalog if that is what you want to do (I would do > this and then remove the bundle). > > Geoff > > > > On Thu, 29 Aug 2019 at 16:33, Juan Cabrerizo <[email protected]> wrote: > > > 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/ > > >
