>From time to time OBRResolverTest causes Aries build to fail
------------------------------------------------------------
Key: ARIES-327
URL: https://issues.apache.org/jira/browse/ARIES-327
Project: Aries
Issue Type: Bug
Components: Application
Affects Versions: 0.1
Reporter: Bartosz Kowalewski
A good example of a build that failed because of this issue is build #497 on
Hudson.
The error log looks like this:
[transitive.bundle.by.reference;{deployed-version->1.0.0}] expected:<2> but
was:<1>
java.lang.AssertionError:
[transitive.bundle.by.reference;{deployed-version->1.0.0}] expected:<2> but
was:<1>
at org.junit.Assert.fail(Assert.java:74)
at org.junit.Assert.failNotEquals(Assert.java:448)
at org.junit.Assert.assertEquals(Assert.java:102)
at org.junit.Assert.assertEquals(Assert.java:323)
at
org.apache.aries.application.runtime.itests.OBRResolverTest.testBlogApp(OBRResolverTest.java:187)
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.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:134)
at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101)
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.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
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)
The second test method defined in this test class also fails from time to time.
This issue is caused by the fact that AriesApplicationManagerImpl is sometimes
provided with a wrong service instance for the AriesApplicationResolver
interface. Instead of obr-resolver, we get no-op-resolver.
When the test fails, in the logs we can see:
[RMI TCP Connection(1)-192.168.33.2] DEBUG
org.apache.aries.blueprint.container.ServiceRecipe - Retrieving service for
bundle org.apache.aries.application.management_0.2.0.incubating-SNAPSHOT [10]
and service registration
{org.apache.aries.application.management.AriesApplicationResolver}={osgi.service.blueprint.compname=no-op-resolver,
service.ranking=-1, service.id=35}
When it succeeds:
[RMI TCP Connection(1)-192.168.33.2] DEBUG
org.apache.aries.blueprint.container.ServiceRecipe - Retrieving service for
bundle org.apache.aries.application.management_0.2.0.incubating-SNAPSHOT [10]
and service registration
{org.apache.aries.application.management.AriesApplicationResolver}={osgi.service.blueprint.compname=obr-resolver,
service.id=40}
It is somewhat weird that we observe this behavior as no-op-resolver has
service ranking -1 and obr-resolver has ranking 0. Logs suggest that from time
to time, AriesApplicationManagerImpl is provided with a service reference
before initialization of the bundle that provides the obr-resolver
(org.apache.aries.application.resolver.obr) completes :(. This seems to exlain
the weird behavior. Changing the order of bundles passed to Pax Exam seems to
fix this issue.
Note: Other testcases (i.e. OBRAppManagerTest) might also be affected by this
issue.
Side note:
Constants defined in the OBRResolverTest class make it hard to understand
what's going on inside this test - they are mixed :) :
public static final String TRANSITIVE_BUNDLE_BY_VALUE =
"transitive.bundle.by.reference";
public static final String TRANSITIVE_BUNDLE_BY_REFERENCE =
"transitive.bundle.by.value";
A patch fixing both the initial problem and the issue with constants coming
soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
