Thanks Juan.
Finally discovered.... my main problem with the unrecognized provider was
that it couldn't resolve the ExternalConfigProvider import it was
implementing.  In Eclipse, I was just handing the project a reference to
the brooklyn 0.12.0 jar and it worked, but in the Brooklyin runtime, I'm
unable to resolve the osgi bundle of the same contents - it's a matter of
not knowing how to point  eclipse to $BROOKLYN_HOME/system as its runtime
repository.

....

On Thu, Aug 29, 2019 at 8:33 AM 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/
>

Reply via email to