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/

Reply via email to