Help with "BLAMED ON"

[Bengt Rodehav <be...@rodehav.com>]

*
Since moving to Felix 3 I've noticed a lot of BLAMED ON logging I haven't
seen before. I now use Felix 3.0.2. Can someone help me interpret the
following exception?

org.ops4j.pax.exam.spi.container.TestContainerException: Bundle cannot be
> started
>
at
> org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.startBundle(RemoteBundleContextClient.java:192)
>
at
> org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.startBundle(PaxRunnerTestContainer.java:226)
>
at
> org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:149)
>
at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
>
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
>
at
> org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
>
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
>
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
>
at
> org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246)
>
at
> org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196)
>
at
> org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186)
>
at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
>
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
>
at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182)
>
at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
>
at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
>
at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
>
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
>
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
at java.lang.reflect.Method.invoke(Method.java:597)
>
at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
>
at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
>
Caused by: org.osgi.framework.BundleException: Constraint violation for
> package 'se.digia.sts.persistence' when resolving module 32.0 between
> existing import 28.0.se.digia.sts.persistence BLAMED ON [[32.0] package;
> (&(package=se.digia.sts.persistence)(version>=1.0.0))] and uses constraint
> 29.0.se.digia.sts.persistence BLAMED ON [[32.0] package;
> (package=se.digia.sts.refdata.domain)]
>
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3428)
>
at org.apache.felix.framework.Felix.startBundle(Felix.java:1754)
>
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)
>
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)
>
at
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.startBundle(RemoteBundleContextImpl.java:255)
>
at
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.startBundle(RemoteBundleContextImpl.java:128)
>
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
at java.lang.reflect.Method.invoke(Method.java:597)
>
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
>
at sun.rmi.transport.Transport$1.run(Transport.java:159)
>
at java.security.AccessController.doPrivileged(Native Method)
>
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
>
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
>
at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
>
at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
>
at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>
at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>
at java.lang.Thread.run(Thread.java:619)
>
at
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
>
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
>
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
>
at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:178)
>
at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:132)
>
at $Proxy9.startBundle(Unknown Source)
>
at
> org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.startBundle(RemoteBundleContextClient.java:184)
>
... 23 more
>

In this case the bundle could not be started. Sometimes I get similar
logging messages but the bundle is still started. I haven't fully understood
what this means.

/Bengt
*

Re: Help with "BLAMED ON"

[Bengt Rodehav <be...@rodehav.com>]

Thanks Richard,

I think in this case I probably export th se.digia.sts.persistence from more
than one bundle which I guess could cause this problem. I had a general
setting (in my maven parent) for the maven-bundle-plugin that defaulted to
exporting se.digia.sts*. This is probably not a good idea...

Thanks for your help,

/Bengt

2010/9/20 Richard S. Hall <he...@ungoverned.org>

>  On 9/20/10 16:23, Bengt Rodehav wrote:
>
>> *
>>
>> Since moving to Felix 3 I've noticed a lot of BLAMED ON logging I haven't
>> seen before. I now use Felix 3.0.2. Can someone help me interpret the
>> following exception?
>>
>
> Yes, those are coming from the new resolver implementation.
>
>
>
>> Caused by: org.osgi.framework.BundleException: Constraint violation for
>>
>>> package 'se.digia.sts.persistence' when resolving module 32.0 between
>>> existing import 28.0.se.digia.sts.persistence BLAMED ON [[32.0] package;
>>> (&(package=se.digia.sts.persistence)(version>=1.0.0))] and uses
>>> constraint
>>> 29.0.se.digia.sts.persistence BLAMED ON [[32.0] package;
>>> (package=se.digia.sts.refdata.domain)]
>>>
>>>
> This is saying that while trying to resolve 32, we selected 28 as the
> provider of se.degia.sts.persistence since 32 imported this package (this is
> the first BLAMED ON, which is basically saying this choice was blamed on the
> fact that bundle 32 imports the package). However, this choice was
> problematic since we can see the same package from bundle 29 due to the fact
> that 32 imports se.degia.sts.refdata.domain from it (this is the second
> BLAMED ON).
>
> So, I would guess that this means that bundle 29 exports both the
> persistence and domain packages and that its domain package uses its
> persistence package. This would then expose 32 to two providers of the
> persistence package which cannot be allowed.
>
> In theory, it seems like the original import for the persistence package
> should be satisfiable by 29. If this is not happening, then maybe 29 isn't
> exporting the package with version 1.0.0 or higher. Just a guess.
>
>
>
>  In this case the bundle could not be started. Sometimes I get similar
>> logging messages but the bundle is still started. I haven't fully
>> understood
>> what this means.
>>
>>
> Some of these messages are just logged when the error happens, but an
> alternative solution is found so the message is only informational at that
> point.
>
> -> richard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Re: Help with "BLAMED ON"

["Richard S. Hall" <he...@ungoverned.org>]

  On 9/20/10 16:23, Bengt Rodehav wrote:
> *
> Since moving to Felix 3 I've noticed a lot of BLAMED ON logging I haven't
> seen before. I now use Felix 3.0.2. Can someone help me interpret the
> following exception?

Yes, those are coming from the new resolver implementation.

>
> Caused by: org.osgi.framework.BundleException: Constraint violation for
>> package 'se.digia.sts.persistence' when resolving module 32.0 between
>> existing import 28.0.se.digia.sts.persistence BLAMED ON [[32.0] package;
>> (&(package=se.digia.sts.persistence)(version>=1.0.0))] and uses constraint
>> 29.0.se.digia.sts.persistence BLAMED ON [[32.0] package;
>> (package=se.digia.sts.refdata.domain)]
>>

This is saying that while trying to resolve 32, we selected 28 as the 
provider of se.degia.sts.persistence since 32 imported this package 
(this is the first BLAMED ON, which is basically saying this choice was 
blamed on the fact that bundle 32 imports the package). However, this 
choice was problematic since we can see the same package from bundle 29 
due to the fact that 32 imports se.degia.sts.refdata.domain from it 
(this is the second BLAMED ON).

So, I would guess that this means that bundle 29 exports both the 
persistence and domain packages and that its domain package uses its 
persistence package. This would then expose 32 to two providers of the 
persistence package which cannot be allowed.

In theory, it seems like the original import for the persistence package 
should be satisfiable by 29. If this is not happening, then maybe 29 
isn't exporting the package with version 1.0.0 or higher. Just a guess.


> In this case the bundle could not be started. Sometimes I get similar
> logging messages but the bundle is still started. I haven't fully understood
> what this means.
>

Some of these messages are just logged when the error happens, but an 
alternative solution is found so the message is only informational at 
that point.

-> richard


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org