[
https://issues.apache.org/jira/browse/ARIES-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lin Sun resolved ARIES-327.
---------------------------
Resolution: Fixed
patch committed (the 4th one). Think the 4th one did resolve end line prob
between windows and unix, and after Jarek's reset svn properties (in rev
952398) able to commit the patch.
> 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
> Assignee: Lin Sun
> Attachments: ARIES-327-31May2010.diff, ARIES-327-dos2unix.patch,
> ARIES-327-new.patch, 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.
