You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@karaf.apache.org by Steinar Bang <sb...@dod.no> on 2018/09/09 12:30:42 UTC

Problems accessing SystemMBean from a DS component

Platform: debian 9.5 "stretch", amd64
          openjdk-8-jdk 8u181-b13-1~deb9u1
          karaf 4.1.5

(Note: This is a project very much in the start phase so I haven't pushed
anything to github yet)

I'm trying to inject a SystemMBean into a DS component.  When I try
this, loading the feature holding the component, fails with an error
message:
 karaf@root()> feature:repo-add mvn:no.priv.bang.neo4j.karaf/neo4j-karaf/LATEST/xml/features
 Adding feature url mvn:no.priv.bang.neo4j.karaf/neo4j-karaf/LATEST/xml/features
 karaf@root()> feature:install neo4j-server
 Error executing command: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=neo4j-server; type=karaf.feature; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; filter:="(&(osgi.identity=neo4j-server)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))" [caused by: Unable to resolve neo4j-server/1.0.0.SNAPSHOT: missing requirement [neo4j-server/1.0.0.SNAPSHOT] osgi.identity; osgi.identity=no.priv.bang.neo4j.karaf; type=osgi.bundle; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; resolution:=mandatory [caused by: Unable to resolve no.priv.bang.neo4j.karaf/1.0.0.SNAPSHOT: missing requirement [no.priv.bang.neo4j.karaf/1.0.0.SNAPSHOT] osgi.service; filter:="(objectClass=org.apache.karaf.system.management.SystemMBean)"; effective:=active]]
 karaf@root()>

The karaf.log has this:
 2018-09-09T14:22:47,172 | ERROR | Karaf local console user karaf | ShellUtil                        | 43 - org.apache.karaf.shell.core - 4.1.5 | Exception caught while executing command
org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=neo4j-server; type=karaf.feature; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; filter:="(&(osgi.identity=neo4j-server)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))" [caused by: Unable to resolve neo4j-server/1.0.0.SNAPSHOT: missing requirement [neo4j-server/1.0.0.SNAPSHOT] osgi.identity; osgi.identity=no.priv.bang.neo4j.karaf; type=osgi.bundle; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; resolution:=mandatory [caused by: Unable to resolve no.priv.bang.neo4j.karaf/1.0.0.SNAPSHOT: missing requirement [no.priv.bang.neo4j.karaf/1.0.0.SNAPSHOT] osgi.service; filter:="(objectClass=org.apache.karaf.system.management.SystemMBean)"; effective:=active]]
 	at org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42) ~[?:?]
 	at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:391) ~[?:?]
 	at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:377) ~[?:?]
 	at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:349) ~[?:?]
 	at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:218) ~[?:?]
 	at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291) ~[?:?]
 	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1248) ~[?:?]
 	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$1(FeaturesServiceImpl.java:1147) ~[?:?]
 	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
 	at java.lang.Thread.run(Thread.java:748) [?:?]


Does anyone know what I might be missing?

What I have done, is:
 1. Add org.apache.karaf.system.core as a provided dependency
        <dependency>
            <groupId>org.apache.karaf.system</groupId>
            <artifactId>org.apache.karaf.system.core</artifactId>
            <version>${karaf.version}</version>
            <scope>provided</scope>
        </dependency>
 2. Add a @Reference for the SystemMBean to the DS component

As a shot in the dark, I have also tried adding a
<feature>system</feature> dependency to the template feature.xml of my
feature (it shouldn't be necessary, but it was woth a try).

As far as I can tell, the "system" bundle is alive and loaded, and
exposes the service I'm trying to inject:
 karaf@root()> bundle:list -t 1 org.apache.karaf.system.core
 START LEVEL 100 , List Threshold: 1
 ID │ State  │ Lvl │ Version │ Name
 ───┼────────┼─────┼─────────┼────────────────────────────────
 46 │ Active │  30 │ 4.1.5   │ Apache Karaf :: System :: Core
 karaf@root()> bundle:capabilities org.apache.karaf.system.core
 org.apache.karaf.system.core [46] provides:
 -------------------------------------------
 osgi.wiring.bundle; org.apache.karaf.system.core 4.1.5 [UNUSED]
 osgi.wiring.host; org.apache.karaf.system.core 4.1.5 [UNUSED]
 osgi.identity; org.apache.karaf.system.core 4.1.5 [UNUSED]
 osgi.wiring.package; org.apache.karaf.system 4.1.5 [UNUSED]
 osgi.wiring.package; org.apache.karaf.system.management 4.1.5 [UNUSED]
 service; [org.apache.karaf.system.SystemService] with properties:
    service.bundleid = 46
    service.id = 72
    service.scope = singleton
    Used by:
       org.apache.karaf.system.core [46]
 service; [org.apache.karaf.system.management.SystemMBean, javax.management.DynamicMBean, javax.management.MBeanRegistration] with properties:
    jmx.objectname = org.apache.karaf:type=system,name=root
    service.bundleid = 46
    service.id = 73
    service.scope = singleton
    Used by:
       org.apache.aries.jmx.whiteboard [18]
 karaf@root()>

The org.apache.karaf.system.core bundle exports the
org.apache.karaf.system.management package:
 Export-Package: org.apache.karaf.system;version="4.1.5",org.apache.kar
  af.system.management;uses:="javax.management";version="4.1.5"

My bundle imports the org.apache.karaf.system.management package:
 Import-Package: org.apache.karaf.system.management;version="[4.1,5)",o
  rg.neo4j.graphdb,org.neo4j.graphdb.event,org.neo4j.graphdb.factory,or
  ...

Is there anything else I should check?

Thanks!

Re: Resolving a type from a wrapped jar file

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.

Hi,

Instead of importing packages, you can embed the packages in your bundle.

You have three ways to achieve this using the maven-bundle-plugin:

1. Using Bundle-Classpath instruction
2. Using Embed-Dependency instruction
3. Using Private-Package instruction

Regards
JB

On 09/09/2018 21:35, Steinar Bang wrote:
>>>>>> Jean-Baptiste Onofré <jb...@nanthrax.net>:
> 
>> why you don't just put this as private package. You will avoid class
>> loading issue this way.
> 
>> In OSGi, not all is necessary an import. It could be a private package
>> and/or embed dependency. It means the packages are embedded in the
>> bundle. The bundle is "fat" but you avoid classloading issue this way,
>> especially when the dependency is not designed for OSGi.
> 
> Um... not sure what you mean...?  Do you mean rebundling Neo4J before
> pulling it into karaf?  Either individually (*lots* of work, probably),
> or as a fat jar (less work if the maven dependencies of the top jar can
> be made to do the trick).
> 
>> Unfortunately, I wanted to create neo4j bundle at ServiceMix, but it's
>> not possible due to neo4j license.
> 
> Yeah, the licensing was why I didn't rebundle with maven in the first
> place.  I hoped the wrap protocol could do the trick...
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Resolving a type from a wrapped jar file

Posted by David Jencks <da...@gmail.com>.

Hi David,

Bundle-ClassPath is an osgi header that specifies the internal class path structure of a bundle. -conditionalpackage is a bnd instruction that pulls in specific packages that are actually used from dependencies.

I was suggesting including all of neo4j in the bundle using the -includeresource bnd instruction and setting the Bundle-ClassPath header by hand to include the normal bundle contents under . and also all the neo4j jars copied in using the -includeresource instruction.  If you wanted to use this idea in your bundle without distributing neo4j at all, you could include the Bundle-ClassPath header and ask users to run a zip command to add the neo4j jars themselves.

I don’t remember what you may have to do to get bnd to not generate Import-Package headers for the packages in the included jars.

My idea with this over -conditionalpackage is that you are using the neo4j jars completely unmodified, but contained in an appropriate osgi environment (completely hidden inside the bundle).  -conditionalpackage is a considerably more sophisticated approach, if you are comfortable with the licensing implications.

thanks
david jencks

> On Sep 9, 2018, at 4:35 PM, David Leangen <ap...@leangen.net> wrote:
> 
> 
> Thanks for this info.
> 
> Could you please explain more what you mean by:
> 
>> uses bundle-classpath
> 
> 
> Is this something different from Conditional-Package?
> 
> 
> Cheers,
> =David
> 
> 
>> On Sep 10, 2018, at 6:31, David Jencks <da...@gmail.com> wrote:
>> 
>> IANAL and I really can’t understand the GPLv3.
>> 
>> rebundling or wrapping neo4j jars definitely modifies them.  I’m not sure if having karaf or maven do this on the user’s system compared with distributing such already modified jars makes a difference to the license implications.
>> 
>> If you make a jar that embeds the neo4j jars (as jars) and uses bundle-classpath you are not modifying the neo4j jars at all.  Doing this, you can hide neo4j from the outside of your bundle and provide an API that does exactly what your program needs.  Peter Kriens highly recommends doing this with external  dependencies that are not designed from the start for OSGI.
>> 
>> To repeat, I don’t understand GPLv3.  If it prevents you from distributing a bundle with your code, also embedding the neo4j jars, I don’t see how it could prevent you from distributing your code plus a script that constructs such a bundle; such a script would just be something that puts neo4j jars in a particular place in a production system.
>> 
>> David Jencks
>> 
>>> On Sep 9, 2018, at 12:35 PM, Steinar Bang <sb...@dod.no> wrote:
>>> 
>>>>>>>> Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>> 
>>>> why you don't just put this as private package. You will avoid class
>>>> loading issue this way.
>>> 
>>>> In OSGi, not all is necessary an import. It could be a private package
>>>> and/or embed dependency. It means the packages are embedded in the
>>>> bundle. The bundle is "fat" but you avoid classloading issue this way,
>>>> especially when the dependency is not designed for OSGi.
>>> 
>>> Um... not sure what you mean...?  Do you mean rebundling Neo4J before
>>> pulling it into karaf?  Either individually (*lots* of work, probably),
>>> or as a fat jar (less work if the maven dependencies of the top jar can
>>> be made to do the trick).
>>> 
>>>> Unfortunately, I wanted to create neo4j bundle at ServiceMix, but it's
>>>> not possible due to neo4j license.
>>> 
>>> Yeah, the licensing was why I didn't rebundle with maven in the first
>>> place.  I hoped the wrap protocol could do the trick...
>>> 
>> 
>

Re: Resolving a type from a wrapped jar file

Posted by David Leangen <ap...@leangen.net>.

Thanks for this info.

Could you please explain more what you mean by:

> uses bundle-classpath


Is this something different from Conditional-Package?


Cheers,
=David


> On Sep 10, 2018, at 6:31, David Jencks <da...@gmail.com> wrote:
> 
> IANAL and I really can’t understand the GPLv3.
> 
> rebundling or wrapping neo4j jars definitely modifies them.  I’m not sure if having karaf or maven do this on the user’s system compared with distributing such already modified jars makes a difference to the license implications.
> 
> If you make a jar that embeds the neo4j jars (as jars) and uses bundle-classpath you are not modifying the neo4j jars at all.  Doing this, you can hide neo4j from the outside of your bundle and provide an API that does exactly what your program needs.  Peter Kriens highly recommends doing this with external  dependencies that are not designed from the start for OSGI.
> 
> To repeat, I don’t understand GPLv3.  If it prevents you from distributing a bundle with your code, also embedding the neo4j jars, I don’t see how it could prevent you from distributing your code plus a script that constructs such a bundle; such a script would just be something that puts neo4j jars in a particular place in a production system.
> 
> David Jencks
> 
>> On Sep 9, 2018, at 12:35 PM, Steinar Bang <sb...@dod.no> wrote:
>> 
>>>>>>> Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> 
>>> why you don't just put this as private package. You will avoid class
>>> loading issue this way.
>> 
>>> In OSGi, not all is necessary an import. It could be a private package
>>> and/or embed dependency. It means the packages are embedded in the
>>> bundle. The bundle is "fat" but you avoid classloading issue this way,
>>> especially when the dependency is not designed for OSGi.
>> 
>> Um... not sure what you mean...?  Do you mean rebundling Neo4J before
>> pulling it into karaf?  Either individually (*lots* of work, probably),
>> or as a fat jar (less work if the maven dependencies of the top jar can
>> be made to do the trick).
>> 
>>> Unfortunately, I wanted to create neo4j bundle at ServiceMix, but it's
>>> not possible due to neo4j license.
>> 
>> Yeah, the licensing was why I didn't rebundle with maven in the first
>> place.  I hoped the wrap protocol could do the trick...
>> 
>