Home » Eclipse Projects » Virgo » OSGi Package Hell
| OSGi Package Hell [message #726143] |
Fri, 16 September 2011 16:33  |
|
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 18:55  |
 Dmitry Sklyut
Messages: 279
Registered: January 2010 |
Senior Member |
|
|
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 20:28 |
|
Dmitry Sklyut wrote on Fri, 16 September 2011 14:55Oracle 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:55I 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:55Now 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 #726226 is a reply to message #726195] |
Fri, 16 September 2011 20:28 |
|
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 20:28 |
|
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
|
|
| |
| Re: OSGi Package Hell [message #726850 is a reply to message #726675] |
Mon, 19 September 2011 17:30 |
|
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.
|
|
| | |
Goto Forum:
Current Time: Wed Apr 08 09:54:53 GMT 2020
Powered by FUDForum. Page generated in 0.02211 seconds |
Search
Help
Register
Login
Home
