You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "ildella@gmail.com" <il...@gmail.com> on 2011/02/10 12:56:10 UTC
conflict: Blamed On
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)
I've read this:
http://www.osgi.org/blog/2011/01/error-messages.html
but yet I can't figure out how to solve my specific issue.
xstream has this dep
Required resource(s):
---------------------
Java XML Stream API (StAX) (1.0.1)
XMLPULL V1 API (1.1.4.c)
Optional resource(s):
---------------------
Joda-Time - Java date and time API (1.6.0)
dom4j DOM Processor (1.6.1)
Apache ANT (1.8.1)
CGLIB Code Generation Library (2.2.0)
Apache ANT Launcher (1.8.1)
Apache XML Commons XML-APIs (1.3.4)
XML Object Model (1.1.0)
Apache XML Commons Resolver (1.2.0)
XML Schema Datatypes Library (0.0.0.20060615)
JUnit (4.8.1)
A JSON StAX Implementation (1.0.1)
Jaxen XPath Engine (1.1.1)
RelaxNG Datatypes (1.0.0)
Apache Xerces XML Support (2.9.1)
Java XML Binding API (2.2.0)
JDOM DOM Processor (1.1.0)
--
Daniele Dellafiore
http://danieledellafiore.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: conflict: Blamed On
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/16/11 6:01, Daniele Dellafiore wrote:
> 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?
I don't understand that either. It looks as if it was a fragment
attached to the different bundles that was updated somehow. Seems odd.
What are the steps to reproduce?
-> richard
> Thanks.
>
> On Fri, Feb 11, 2011 at 10:47 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>> On 2/11/11 11:49, ildella@gmail.com wrote:
>>> On Fri, Feb 11, 2011 at 3:36 PM, Richard S. Hall<he...@ungoverned.org>
>>> wrote:
>>>> On 2/11/11 4:33, ildella@gmail.com wrote:
>>>>> On Thu, Feb 10, 2011 at 3:55 PM, Richard S. Hall<he...@ungoverned.org>
>>>>> wrote:
>>>>>> On 2/10/11 6:56, ildella@gmail.com 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: conflict: Blamed On
Posted by Daniele Dellafiore <da...@dellafiore.net>.
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 <he...@ungoverned.org> wrote:
> On 2/11/11 11:49, ildella@gmail.com wrote:
>>
>> On Fri, Feb 11, 2011 at 3:36 PM, Richard S. Hall<he...@ungoverned.org>
>> wrote:
>>>
>>> On 2/11/11 4:33, ildella@gmail.com wrote:
>>>>
>>>> On Thu, Feb 10, 2011 at 3:55 PM, Richard S. Hall<he...@ungoverned.org>
>>>> wrote:
>>>>>
>>>>> On 2/10/11 6:56, ildella@gmail.com 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: conflict: Blamed On
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/11/11 11:49, ildella@gmail.com wrote:
> On Fri, Feb 11, 2011 at 3:36 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>> On 2/11/11 4:33, ildella@gmail.com wrote:
>>> On Thu, Feb 10, 2011 at 3:55 PM, Richard S. Hall<he...@ungoverned.org>
>>> wrote:
>>>> On 2/10/11 6:56, ildella@gmail.com 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: conflict: Blamed On
Posted by "ildella@gmail.com" <il...@gmail.com>.
On Fri, Feb 11, 2011 at 3:36 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 2/11/11 4:33, ildella@gmail.com wrote:
>>
>> On Thu, Feb 10, 2011 at 3:55 PM, Richard S. Hall<he...@ungoverned.org>
>> wrote:
>>>
>>> On 2/10/11 6:56, ildella@gmail.com 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
--
Daniele Dellafiore
http://danieledellafiore.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: conflict: Blamed On
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/11/11 4:33, ildella@gmail.com wrote:
> On Thu, Feb 10, 2011 at 3:55 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>> On 2/10/11 6:56, ildella@gmail.com 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.
-> richard
> obr:addurl http://sigil.codecauldron.org/spring-external.obr
> obr:deploy com.springsource.com.thoughtworks.xstream
>
> then stop and restart karaf.
> during startup you should see some errors and activemq bundles does
> not becomes Active. If you try to start activemq-core, you get the
> error.
>
> Thanks for helping.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: conflict: Blamed On
Posted by "ildella@gmail.com" <il...@gmail.com>.
On Thu, Feb 10, 2011 at 3:55 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 2/10/11 6:56, ildella@gmail.com 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
obr:addurl http://sigil.codecauldron.org/spring-external.obr
obr:deploy com.springsource.com.thoughtworks.xstream
then stop and restart karaf.
during startup you should see some errors and activemq bundles does
not becomes Active. If you try to start activemq-core, you get the
error.
Thanks for helping.
--
Daniele Dellafiore
http://danieledellafiore.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: conflict: Blamed On
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/10/11 6:56, ildella@gmail.com 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.
> I've read this:
> http://www.osgi.org/blog/2011/01/error-messages.html
> but yet I can't figure out how to solve my specific issue.
Neil also posted this recently, which may be useful reading:
http://njbartlett.name/2011/02/09/uses-constraints.html
> xstream has this dep
>
> Required resource(s):
> ---------------------
> Java XML Stream API (StAX) (1.0.1)
> XMLPULL V1 API (1.1.4.c)
>
> Optional resource(s):
> ---------------------
> Joda-Time - Java date and time API (1.6.0)
> dom4j DOM Processor (1.6.1)
> Apache ANT (1.8.1)
> CGLIB Code Generation Library (2.2.0)
> Apache ANT Launcher (1.8.1)
> Apache XML Commons XML-APIs (1.3.4)
> XML Object Model (1.1.0)
> Apache XML Commons Resolver (1.2.0)
> XML Schema Datatypes Library (0.0.0.20060615)
> JUnit (4.8.1)
> A JSON StAX Implementation (1.0.1)
> Jaxen XPath Engine (1.1.1)
> RelaxNG Datatypes (1.0.0)
> Apache Xerces XML Support (2.9.1)
> Java XML Binding API (2.2.0)
> JDOM DOM Processor (1.1.0)
Just so you know, this bundle-level is not really helpful in this
situation, since uses constraints occur at the package level.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org