Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Plan causes Uses violation, manual install works(Plan causes Uses violation, manual install works)
Plan causes Uses violation, manual install works [message #684355] Wed, 15 June 2011 13:19 Go to next message
Matt Fellows is currently offline Matt FellowsFriend
Messages: 28
Registered: February 2011
Junior Member
Hi all,

I am currently having an issue where a particular application is able to run fine in Virgo if I install the dependent bundles one-by-one into Virgo (i.e. cp foo.jar /pickup, cp bar.jar /pickup, cp web.war /pickup) but not if using a Plan.

I'd much prefer to have the reliability\simplicity of a plan given there will be a reasonable number of bundles required in the project. The issue is, when I use a plan to deploy those artifacts in the exact same order, I get the following uses violation:

Caused by: org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'com.melbourneit.web.pps-impl' at version '1.0.0': Cannot resolve: com.melbourneit.web.pps-impl
    Resolver report:
        An Import-Package could not be resolved. Caused by missing constraint in bundle <com.melbourneit.web.pps-impl_1.0.0>
             constraint: <Import-Package: org.apache.cxf.tools.java2js; version="0.0.0"> constrained to bundle <org.apache.cxf.bundle> constrained bundle version range "[2.4.0,2.4.0]"
        An Import-Package could not be resolved. Caused by missing constraint in bundle <com.melbourneit.web.pm-impl_1.0.0>
             constraint: <Import-Package: org.apache.cxf.tools.java2js; version="0.0.0"> constrained to bundle <org.apache.cxf.bundle> constrained bundle version range "[2.4.0,2.4.0]"
        An Import-Package could not be resolved. Caused by missing constraint in bundle <com.melbourneit.web.provisioning_0.0.2>
             constraint: <Import-Package: com.melbourneit.pps.service; version="0.0.0">
        An Import-Package could not be resolved. Caused by missing constraint in bundle <self-service-web_1.0.0>
             constraint: <Import-Package: com.melbourneit.web.provisioning; version="[0.0.0,2.0.0)">
        Uses violation: <Import-Package: javax.xml.ws.wsaddressing; version="[0.0.0,3.0.0)"> in bundle <org.apache.cxf.bundle_2.4.0[1308139651561]>
             Resolver reported uses conflict for import


The violation makes some sense: I have 2 bundles that require Apache CXF, which in turn requires javax.xml.*;version="2.2.0" which is provided by the geronimo bundle.

The Web Application (Spring MVC) requires both of these bundles as well as the Spring Web bundle which for some reason seems to be dependent on bundle 0 (org.eclipse.osgi_3.7.0.v20110224[0]), which also exports javax.xml.* as version="0" and version="2.1.1". I wasn't 100% sure that this was the source of the conflict, but it seemed a very likely candidate. 

osgi> packages javax.xml.ws             
javax.xml.ws; version="0.0.0"<org.eclipse.osgi_3.7.0.v20110224 [0]>
  org.springframework.context_3.0.5.RELEASE [24] imports
  org.springframework.context_3.0.5.RELEASE [75] imports
  org.springframework.web_3.0.5.RELEASE [82] imports
  com.springsource.org.apache.catalina.springsource_6.0.29.S2-r1559 [93] imports
javax.xml.ws; version="2.1.1"<org.eclipse.osgi_3.7.0.v20110224 [0]>
  org.springframework.context_3.0.5.RELEASE [24] imports
  org.springframework.context_3.0.5.RELEASE [75] imports
  org.springframework.web_3.0.5.RELEASE [82] imports
  com.springsource.org.apache.catalina.springsource_6.0.29.S2-r1559 [93] imports


Removing the CXF dependency removes this uses violation and helps my case for it being the cause of the violation, but of course renders the application useless.

I've tried explicitly modifying the spring libraries to use javax.xml.ws;version="[2.2.0,2.2.0]" to be sure that it doesn't try and load it's dependency from bundle 0, which gives me the following error:

Uses violation: <Import-Package: org.springframework.remoting.jaxws; version="0.0.0"> in bundle <self-service-web_1.0.0[1308140426366]>
Found conflicts:
package 'javax.xml.ws.soap_2.2.0' in bundle 'org.apache.geronimo.specs.geronimo-jaxws_2.2_spec_1.0.0[71]' used by 'org.springframework.remoting.jaxws_3.0.5.RELEASE' in bundle 'org.springframework.web_3.0.5.RELEASE[84]'
conflicts with 'javax.xml.ws.soap_0.0.0' in bundle 'org.eclipse.osgi_3.7.0.v20110224[0]' imported by bundle 'self-service-web_1.0.0[1308140426366]'
package 'javax.xml.ws.soap_2.2.0' in bundle 'org.apache.geronimo.specs.geronimo-jaxws_2.2_spec_1.0.0[71]' used by 'org.springframework.remoting.jaxws_3.0.5.RELEASE' in bundle 'org.springframework.web_3.0.5.RELEASE[84]'
conflicts with 'javax.xml.ws.soap_2.1.1' in bundle 'org.eclipse.osgi_3.7.0.v20110224[0]' imported by bundle 'self-service-web_1.0.0[1308140426366]'

So I believe there is a dependency on bundle 0, which I assume has to do with the fact that it needs some core osgi packages to be extended and exposed into the Registry etc.


I'm currently still using Virgo 3.0.0.M03 as I've not had time to port the application across to use M05, but I think that would still be an issue

My next steps are to create a small project to reproduce the issues but for now, and after all of that, I have 2 questions:

1) Why would this work with the manual bundle by bundle approach but not in a plan?
2) What is the best approach to preventing the import of the javax.xml.* packages from the core osgi bundle 0?

Cheers,
Matt

Report message to a moderator

Re: Plan causes Uses violation, manual install works [message #684474 is a reply to message #684355] Wed, 15 June 2011 16:14 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn NormingtonFriend
Messages: 1222
Registered: July 2009
Senior Member
The only reason I can think of that the bundle by bundle approach would resolve differently to a plan is if there are optional imports in the early bundles that would be satisfied by the later bundles. In the bundle by bundle approach, these optional imports would be discarded. In the plan approach, the optional imports would be included and could then contribute to uses constraint violations.

I agree with your approach to preventing the import from the system bundle.

Have you tried using the admin console to analyse the state dump produced by the resolution failure? See the Virgo FAQ for details.

Report message to a moderator

Re: Plan causes Uses violation, manual install works [message #684687 is a reply to message #684474] Thu, 16 June 2011 03:58 Go to previous messageGo to next message
Matt Fellows is currently offline Matt FellowsFriend
Messages: 28
Registered: February 2011
Junior Member
Thanks Glyn.

I will take a look at the dump inspector just so I can get a better picture, but the uses constraint is there so it needs to be fixed - right?

As expected, removing the following lines from lib/java6-server.profile fixes the uses constraint, and everything *seems* to be working. 

 javax.xml.bind,\
 javax.xml.bind;version="2.0",\
 javax.xml.bind.annotation,\
 javax.xml.bind.annotation;version="2.0",\
 javax.xml.bind.annotation.adapters,\
 javax.xml.bind.annotation.adapters;version="2.0",\
 javax.xml.bind.attachment,\
 javax.xml.bind.attachment;version="2.0",\
 javax.xml.bind.helpers,\
 javax.xml.bind.helpers;version="2.0",\
 javax.xml.bind.util,\
 javax.xml.bind.util;version="2.0",\
 javax.xml.ws,\
 javax.xml.ws;version="2.1.1",\
 javax.xml.ws.handler,\
 javax.xml.ws.handler;version="2.1.1",\
 javax.xml.ws.handler.soap,\
 javax.xml.ws.handler.soap;version="2.1.1",\
 javax.xml.ws.http,\
 javax.xml.ws.http;version="2.1.1",\
 javax.xml.ws.soap,\
 javax.xml.ws.soap;version="2.1.1",\
 javax.xml.ws.spi,\
 javax.xml.ws.spi;version="2.1.1",\


My assumption would be that any framework bundles that require those packages would have whinged during startup about missing dependencies so they must be OK. Given that these packages are now made available by another bundle (geronimo), any bundle in the user region requiring those packages would now get it from geronimo instead.

Do you see any issue with this approach? I'd prefer to prevent the import from the system bundle over preventing the export from the system bundle, but I don't see how that is possible. Would a bundle fragment on bundle 0 exporting a later version of javax.xml.* solve this problem?

I noticed on Neil's excellent article that he had a similar issue with javax.annotations and 3 suggestions were made (modified to suit my issue):

1. Removing javax.xml.* from the exports of the system bundle altogether; this will make both the Web and CXF bundles resolve javax.xml.* from geronimo
2. Exporting the javax.xml.* packages from the system bundle as version 2.2.0; then we don't need the geronimo bundle.
3. Using a special bundle that pulls the javax.xml.* packages from the JRE (using Require-Bundle!) and reexports it as version 2.2.0 rendering geronimo redundant

Options 2 and 3 don't seem viable to me unless the system bundle actually exports version 2.2.0 instead of the currently exported 2.1.1.

What are the implications of removing these packages?

Cheers,
Matt

Report message to a moderator

(no subject) [message #684688 is a reply to message #684474] Thu, 16 June 2011 03:58 Go to previous messageGo to next message
Matt Fellows is currently offline Matt FellowsFriend
Messages: 28
Registered: February 2011
Junior Member
Thanks Glyn.

I will take a look at the dump inspector just so I can get a better picture, but the uses constraint is there so it needs to be fixed - right?

As expected, removing the following lines from lib/java6-server.profile fixes the uses constraint, and everything *seems* to be working.

javax.xml.bind,\
javax.xml.bind;version="2.0",\
javax.xml.bind.annotation,\
javax.xml.bind.annotation;version="2.0",\
javax.xml.bind.annotation.adapters,\
javax.xml.bind.annotation.adapters;version="2.0",\
javax.xml.bind.attachment,\
javax.xml.bind.attachment;version="2.0",\
javax.xml.bind.helpers,\
javax.xml.bind.helpers;version="2.0",\
javax.xml.bind.util,\
javax.xml.bind.util;version="2.0",\
javax.xml.ws,\
javax.xml.ws;version="2.1.1",\
javax.xml.ws.handler,\
javax.xml.ws.handler;version="2.1.1",\
javax.xml.ws.handler.soap,\
javax.xml.ws.handler.soap;version="2.1.1",\
javax.xml.ws.http,\
javax.xml.ws.http;version="2.1.1",\
javax.xml.ws.soap,\
javax.xml.ws.soap;version="2.1.1",\
javax.xml.ws.spi,\
javax.xml.ws.spi;version="2.1.1",\


My assumption would be that any framework bundles that require those packages would have whinged during startup about missing dependencies so they must be OK. Given that these packages are now made available by another bundle (geronimo), any bundle in the user region requiring those packages would now get it from geronimo instead.

Do you see any issue with this approach? I'd prefer to prevent the import from the system bundle over preventing the export from the system bundle, but I don't see how that is possible. Would a bundle fragment on bundle 0 exporting a later version of javax.xml.* solve this problem?

I noticed on Neil's http://njbartlett.name/2011/02/09/uses-constraints.html that he had a similar issue with javax.annotations and 3 suggestions were made (modified to suit my issue):

1. Removing javax.xml.* from the exports of the system bundle altogether; this will make both the Web and CXF bundles resolve javax.xml.* from geronimo
2. Exporting the javax.xml.* packages from the system bundle as version 2.2.0; then we don't need the geronimo bundle.
3. Using a special bundle that pulls the javax.xml.* packages from the JRE (using Require-Bundle!) and reexports it as version 2.2.0 rendering geronimo redundant

Options 2 and 3 don't seem viable to me unless the system bundle actually exports version 2.2.0 instead of the currently exported 2.1.1.

What are the implications of removing these packages?

Cheers,
Matt

Report message to a moderator

Re: (no subject) [message #684692 is a reply to message #684687] Thu, 16 June 2011 04:05 Go to previous message
Matt Fellows is currently offline Matt FellowsFriend
Messages: 28
Registered: February 2011
Junior Member
Apologies, I'm not sure why my posts are being duplicated (it's happened here too), I have a suspicion it's a Firefox plugin or something. Glyn\Forum moderator - are you able to remove both this comment and my duplicate posts?

Report message to a moderator

Previous Topic:Web Service creation error with apche cxf
Next Topic:OSGi Dev Tooling Panel - Thurs 23rd June - Free to attend
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Tue Apr 23 15:50:52 GMT 2024

Powered by FUDForum. Page generated in 0.03264 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly