Eclipse Community Forums: Virgo » OSGi Package Hell

Home » Eclipse Projects » Virgo » OSGi Package Hell

Fri, 16 September 2011 12:33

Eclipse User

Hi all,

I feel like I'm going down a rat's nest of transitive dependencies -- it's a bit frustrating. I think I could some advice.

I'm trying to use DataNucleus 3.0.2-SNAPSHOT against the Oracle Thin JDBC Driver 11.2.0.1.0 using the JPA API 2.0. I've got all the DataNucleus bundles installed ok in Virgo using a plan (because some of the DataNucleus bundles use Requires-Bundle). The DataNucleus plan file is in my Virgo pickup directory.

The bundle that contains my one JPA entity is compiling & testing fine via Maven. It's also being packaged ok, AFAICT, by maven-bundle-plugin. I've decided to try to embed the Oracle JDBC Thin driver jar in my entity bundle. Each time I try to deploy the entity bundle in Virgo, though, I get a new resolver error. Here are the various resolver errors I got and fixed by adding appropriate bundles from either the SpringSource EBR or by declaring a direct dependency on them in my Maven pom, which gets included via maven-bundle-plugin's Embed-Dependency header/argument/property.

* javax.resource: copied com.springsource.javax.resource-1.5.0.jar to repository/usr
* org.apache.commons.pool.impl: copied com.springsource.org.apache.commons.dbcp-1.2.2.osgi.jar & com.springsource.org.apache.commons.pool-1.5.3.jar to repository/usr
* org.apache.tools.ant.taskdefs: added direct Maven dependency on groupId "org.apache.ant", artifactId "ant"

Now, I'm getting the resolver error 'constraint: <Import-Package: sun.rmi.rmic; version="0.0.0">'.

The RMI compiler? Really? I feel like I'm going down a rat hole whose bottom I'll never reach.

I don't really want to use maven-bundle-plugin's <Embed-Transitive>true</Embed-Transitive> -- that's like defeating the purpose of OSGi. This feels like OSGi package hell. Is there a way to figure this out more easily?

Thanks,
Matthew

Re: OSGi Package Hell [message #726195 is a reply to message #726143]

Fri, 16 September 2011 14:55

Eclipse User

Oracle Thin driver is a tricky animal. Once upon a time EBR had a bundelized copy - but no more.

I don't know why and who is using ant in there, but you can do away with the resolver errors by adding resolution:=optional attribute to package import.

Now on to the sun.* packages. Those should be covered by

org.osgi.framework.bootdelegation = \
 org.eclipse.virgo.osgi.extensions.*,\
 org.eclipse.virgo.osgi.launcher.*,\
 org.eclipse.virgo.kernel.authentication,\
 com.sun.*,\
 javax.xml.*,\
 org.apache.xerces.jaxp.*,\
 org.w3c.*,\
 org.xml.*,\
 sun.*

sun.* above should have covered all of the sun packages.

Some more info on "org.osgi.framework.bootdelegation" and classloading in osgi see here: http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/

Re: OSGi Package Hell [message #726221 is a reply to message #726195]

Fri, 16 September 2011 16:28

Eclipse User

Dmitry Sklyut wrote on Fri, 16 September 2011 14:55

Oracle Thin driver is a tricky animal. Once upon a time EBR had a bundelized copy - but no more.

I figured as much.
Dmitry Sklyut wrote on Fri, 16 September 2011 14:55

I don't know why and who is using ant in there, but you can do away with the resolver errors by adding resolution:=optional attribute to package import.

One thing that would help me out is having Virgo tell me, much like "mvn dependency:tree" who is calling for what. Is there a way to get resolver messages like that? I'll check serviceability/logs/log.log more carefully to see if I can find that.

Dmitry Sklyut wrote on Fri, 16 September 2011 14:55

Now on to the sun.* packages. Those should be covered by
org.osgi.framework.bootdelegation = \
 org.eclipse.virgo.osgi.extensions.*,\
 org.eclipse.virgo.osgi.launcher.*,\
 org.eclipse.virgo.kernel.authentication,\
 com.sun.*,\
 javax.xml.*,\
 org.apache.xerces.jaxp.*,\
 org.w3c.*,\
 org.xml.*,\
 sun.*
sun.* above should have covered all of the sun packages.

Some more info on "org.osgi.framework.bootdelegation" and classloading in osgi see here: http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/

Great, I should've known that. Smile

Thanks,
Matthew

(no subject) [message #726226 is a reply to message #726195]

Fri, 16 September 2011 16:28

Eclipse User

Dmitry Sklyut wrote on Fri, 16 September 2011 14:55
> Oracle Thin driver is a tricky animal. Once upon a time EBR had a bundelized copy - but no more.

I figured as much.
Dmitry Sklyut wrote on Fri, 16 September 2011 14:55
> I don't know why and who is using ant in there, but you can do away with the resolver errors by adding resolution:=optional attribute to package import.

One thing that would help me out is having Virgo tell me, much like "mvn dependency:tree" who is calling for what. Is there a way to get resolver messages like that? I'll check serviceability/logs/log.log more carefully to see if I can find that.

Dmitry Sklyut wrote on Fri, 16 September 2011 14:55
> Now on to the sun.* packages. Those should be covered by
>
>
> org.osgi.framework.bootdelegation = \
> org.eclipse.virgo.osgi.extensions.*,\
> org.eclipse.virgo.osgi.launcher.*,\
> org.eclipse.virgo.kernel.authentication,\
> com.sun.*,\
> javax.xml.*,\
> org.apache.xerces.jaxp.*,\
> org.w3c.*,\
> org.xml.*,\
> sun.*
>
>
> sun.* above should have covered all of the sun packages.
>
>
> Some more info on "org.osgi.framework.bootdelegation" and classloading in osgi see here: http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/

Great, I should've known that. :)

Thanks,
Matthew

(no subject) [message #726233 is a reply to message #726195]

Fri, 16 September 2011 16:28

Eclipse User

Re: OSGi Package Hell [message #726675 is a reply to message #726221]

Mon, 19 September 2011 04:49

Eclipse User

Matthew T. Adams wrote on Fri, 16 September 2011 21:28

One thing that would help me out is having Virgo tell me, much like "mvn dependency:tree" who is calling for what. Is there a way to get resolver messages like that? I'll check serviceability/logs/log.log more carefully to see if I can find that.

Although Virgo doesn't support that exact function, you can use the admin console to browse the state dump which is taken when a resolution failure occurs. All the wirings which were in place when the error occurred are browseable.

Re: OSGi Package Hell [message #726850 is a reply to message #726675]

Mon, 19 September 2011 13:30

Eclipse User

Glyn Normington wrote on Mon, 19 September 2011 04:49

...you can use the admin console to browse the state dump which is taken when a resolution failure occurs. All the wirings which were in place when the error occurred are browseable.

Yes, that's a nice feature, but it requires navigation that is sometimes slow. I just thought a single textual dump would be quick to navigate.

Re: OSGi Package Hell [message #727018 is a reply to message #726850]

Tue, 20 September 2011 04:12

Eclipse User

I see. Please feel free to raise an enhancement bugzilla. Note that a textual dump would need to be defined a little carefully as a straightforward dump in the presence of circular dependencies would be infinite.

Re: OSGi Package Hell [message #728066 is a reply to message #727018]

Thu, 22 September 2011 09:29

Eclipse User

Glyn Normington wrote on Tue, 20 September 2011 04:12

I see. Please feel free to raise an enhancement bugzilla. Note that a textual dump would need to be defined a little carefully as a straightforward dump in the presence of circular dependencies would be infinite.

Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=358587

Thanks!

Previous Topic:	Why is my plan being stopped?
Next Topic:	spring osgi web bundle deployment exception

Goto Forum:

-=] Back to Top [=-

Current Time: Mon Jul 14 23:39:40 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter