aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin Sun (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (ARIES-327) From time to time OBRResolverTest causes Aries build to fail
Date Mon, 07 Jun 2010 20:22:48 GMT

     [ 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.


Mime
View raw message