aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bartosz Kowalewski (JIRA)" <j...@apache.org>
Subject [jira] Updated: (ARIES-327) From time to time OBRResolverTest causes Aries build to fail
Date Mon, 07 Jun 2010 17:35:45 GMT

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

Hi Lin,

I tried several other approaches, including:
svn diff -x --ignore-eol-style ...
The effect was always the same - files were binary identical. 

I passed the latest patch through dos2unix which substituted all CR LF with LF. The file is
named ARIES-327-dos2unix.patch. 

Oh, I found this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=2351

I hope this time it works.

Thanks,
  Bartek

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