Hi Geoff Here's the problem... With an untyped bundle like a provider, you can't delete it from the catalog because that operation requires one to specify a type, like app, entity, etc. And when you uninstall a provider bundle just with karaf, it seems to disappear, but if you stop and restart the karaf instance, it reappears again. I can't find a way to remove it permanently, and thus can't guarantee I'm getting new code when I reuse a version number during the develop-test iteration. When processes are at rest, can one simply delete the bundle manually? Or do the entries live in an index somewhere.
Peter 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/ > > >
