Hi. Thanks for you extended explanation. I did not had the chance to work with that till today. And another similar problem occurr, I think is simpler than the old one but I can't really understand what's going on. Status:
[ 33] [Active ] [ ] [ ] [ 60] Spring Core (3.0.5.RELEASE) [467] [Active ] [ ] [ ] [ 70] Pipelean Storage (1.0.0.SNAPSHOT) [468] [Installed ] [ ] [ ] [ 70] Lazin Authentication (1.0.0.SNAPSHOT) start 468 Error executing command: Constraint violation for package 'org.springframework.util' when resolving module 468.0 between existing import 33.0.org.springframework.util BLAMED ON [[468.0] package; (&(package=org.springframework.util)(version>=3.0.0)(!(version>=4.0.0)))] and uses constraint 33.2.org.springframework.util BLAMED ON [[468.0] package; (package=in.laz.storage.mongo), [467.0] package; (&(package=org.springframework.util)(version>=3.0.0)(!(version>=4.0.0)))] what I can't understand is the difference between 33.2.org.springframework.util and 33.0.org.springframework.util. 33 is the spring-core bundle that exports the relevan org.springframework.util package. But what's the difference between 33.0 and 33.2? Thanks. On Fri, Feb 11, 2011 at 10:47 PM, Richard S. Hall <[email protected]> wrote: > On 2/11/11 11:49, [email protected] wrote: >> >> On Fri, Feb 11, 2011 at 3:36 PM, Richard S. Hall<[email protected]> >> wrote: >>> >>> On 2/11/11 4:33, [email protected] wrote: >>>> >>>> On Thu, Feb 10, 2011 at 3:55 PM, Richard S. Hall<[email protected]> >>>> wrote: >>>>> >>>>> On 2/10/11 6:56, [email protected] wrote: >>>>>> >>>>>> Hi. >>>>>> I've deployed a couple of Restlet 2.x bundles, one being >>>>>> restlet.xstream extension. >>>>>> To activate restlet.xstream I've added xstream 1.3.1 via: >>>>>> >>>>>> obr:deploy com.springsource.com.thoughtworks.xstream >>>>>> >>>>>> That installed a lot of required and optional extensions. >>>>>> Now, the existing activemq-core bundels stop working due to: >>>>>> >>>>>> Error executing command: Constraint violation for package >>>>>> 'javax.xml.stream' when resolving module 154.0 between existing import >>>>>> 0.javax.xml.stream BLAMED ON [[154.0] package; >>>>>> (package=javax.xml.stream)] and uses constraint 200.0.javax.xml.stream >>>>>> BLAMED ON [[154.0] package; (package=com.thoughtworks.xstream.io.xml), >>>>>> [196.0] package; >>>>>> (&(package=javax.xml.stream)(version>=1.0.1)(!(version>=2.0.0)))] >>>>>> >>>>>> being >>>>>> 154 activemq-core >>>>>> 200 Java XML Stream API (StAX) (1.0.1) >>>>>> 196 Thoughtworks XStream (1.3.1) >>>>> >>>>> What this is telling you is that 154 imports javax.xml.stream and the >>>>> candidate chosen for that is the system bundle, but 154 is also exposed >>>>> to >>>>> javax.xml.stream from bundle 200 from 154's import of >>>>> com.thoughtworks.xstream.io.xml which it satisfied by 196 and uses its >>>>> import of javax.xml.stream which is satisfied by 200. >>>>> >>>>> The confusing part to me, though, is that this doesn't seem like it >>>>> should >>>>> be the final error, rather this seems like an intermediate error. >>>>> Because >>>>> 154's import of javax.xml.stream should also be satisfiable by 200 >>>>> since >>>>> 154's import doesn't include a version range. So, the resolver should >>>>> attempt this combination too, which given this limited information >>>>> should >>>>> succeed. >>>>> >>>>> If you can give me a simple way to reproduce this situation, I can >>>>> check >>>>> it >>>>> out; e.g., you could provide me a link to download your bundle cache >>>>> and >>>>> give me the steps to cause the error. >>>> >>>> on Karaf 2.1.2 >>>> >>>> features:install obr >>>> features:install activemq-spring >>> >>> A step must be missing, because the above command fails to execute, it >>> says >>> there is no such feature. >> >> here it is, sorry: >> >> features:addUrl mvn:org.apache.activemq/activemq-karaf/5.4.0/xml/features > > That did the trick. So, this is what I see with debug logging enabled for > the Felix framework (and ignoring some duplicate exception messages): > > DEBUG: Conflict between imports > (org.apache.felix.framework.resolver.ResolveException: Constraint violation > for package 'javax.xml.stream' when resolving module 57.0 between existing > import 78.0.javax.xml.stream BLAMED ON [[57.0] package; > (package=javax.xml.stream)] and uses constraint 0.javax.xml.stream BLAMED ON > [[57.0] package; (package=org.apache.xbean.spring.context.v2), [65.0] > package; (&(package=org.springframework.util.xml)(version>=2.5.0)), [36.0] > package; (&(package=javax.xml.stream)(version>=0.0.0))]) > > DEBUG: Conflict between imports > (org.apache.felix.framework.resolver.ResolveException: Constraint violation > for package 'javax.xml.stream' when resolving module 57.0 between existing > import 0.javax.xml.stream BLAMED ON [[57.0] package; > (package=javax.xml.stream)] and uses constraint 78.0.javax.xml.stream BLAMED > ON [[57.0] package; (package=com.thoughtworks.xstream.io.xml), [73.0] > package; (&(package=javax.xml.stream)(version>=1.0.1)(!(version>=2.0.0)))]) > > Error executing command: Constraint violation for package 'javax.xml.stream' > when resolving module 57.0 between existing import 0.javax.xml.stream BLAMED > ON [[57.0] package; (package=javax.xml.stream)] and uses constraint > 78.0.javax.xml.stream BLAMED ON [[57.0] package; > (package=com.thoughtworks.xstream.io.xml), [73.0] package; > (&(package=javax.xml.stream)(version>=1.0.1)(!(version>=2.0.0)))] > > As you can see, the final ERROR is just the exception from the last resolve > attempt, but there are other resolve attempts that failed too. By setting > the framework log level to DEBUG, you can see these other failures. > > So, module 57 is: > > 000057 INS org.apache.activemq.activemq-core-5.4.0 > > You can see in the above output that 57 has an import for javax.xml.stream > and has two candidates to resolve it: module 78 and module 0. In the first > DEBUG above it tries to use 78 to satisfy the requirement, but this fails > because module 36 is already resolved and wired to javax.xml.stream from > bundle 0: > > 000036 ACT org.springframework.core-3.0.4.RELEASE > > Thus it tries again to resolve 57, but using module 0 as the provider of > javax.xml.stream. This case fails because module 73 exposes javax.xml.stream > and 73 can only be satisfied by provider 78. > > Module 36 requires this: (&(package=javax.xml.stream)(version>=0.0.0)) <== > This matches 0 and 78. > Module 73 requires this: > (&(package=javax.xml.stream)(version>=1.0.1)(!(version>=2.0.0))) <== This > matches only 78. > > This is the root of the issue and the fact that the bundles are > incrementally resolved makes it so the early decision of 0 for 36 makes it > impossible to resolve 73. > > The reason 0 is chosen for 36 is because when Karaf starts up, 36 ends up > being resolved before 78, which means that 36 takes the highest priority > matching provider at that point in time, which will be 0 since the system > bundle is already resolved giving it higher priority. > > Once Karaf is done starting up, 78 ends also being resolved which raises its > priority. So after this, I am able to refresh 36 and have the framework > re-wire it to the highest version of javax.xml.stream from 78, then I was > able to start 57 without issue. Unforunately, I don't have a general > solution to this issue. Since the Felix framework resolver is incremental, > it is not possible to prevent this sort of situation completely. > > If bundle 36's version range requirement is correct (version>=0.0.0) then > there is no easy fix, but if it should actually be like 78's > (1.0.1<=version<2.0.0), then if it is edited it will work because it will > not select 0. The other approach is to configure the framework to not export > javax.xml.stream from the system bundle. > > -> richard > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
