[
https://issues.apache.org/jira/browse/ARIES-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bartosz Kowalewski updated ARIES-327:
-------------------------------------
Attachment: ARIES-327-31May2010.diff
Attaching a new and better patch - ARIES-327-31May2010.diff
Initialization of the application.runtime bundle is postponed until the
obr-resolver service is registered. This patch should cause application itests
not to fail. Previously, there was a slight probability that failures would
still be observed when Blueprint definitions from the 'application runtime'
bundle are processed a bit faster than definitions from the 'application
resolver obr' bundle.
While the issue with application itests should be resolved now, there's a more
serious problem. This issue might also affect Aries Application bundles that
are deployed into standalone OSGi containers. The service ranking value that is
set on the no-op resolver does not guarantee that obr-resolver will be used if
present. In order to eliminate this issue one needs to play with some settings
- i.e. use different start levels for Aries Application bundles. One needs to
make sure that if 'application resolver obr' bundle is to be used, it needs to
be processed by Blueprint extender before the 'application runtime' or the
'application management' bundle.
> 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
> Attachments: ARIES-327-31May2010.diff, ARIES-327.diff
>
>
> 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.
