Indeed. It turns out the JMX itests reuse the blueprint.sample project and make their assertions about what it contains :(
I have checked in a fix for it in the 0.3 stream under 990185. Apologies. Valentin On 27 Aug 2010, at 16:19, Joe Bohn wrote: > Unfortunately, I'm now hitting a build failure for one of the tests in jmx - > I suspect due to the changes in blueprint: > > ------------------------------------------------------------------------------- > Test set: org.apache.aries.jmx.test.blueprint.BlueprintMBeanTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.891 sec <<< > FAILURE! > BlueprintSample > [equinox](org.apache.aries.jmx.test.blueprint.BlueprintMBeanTest) Time > elapsed: 4.84 sec <<< FAILURE! > java.lang.AssertionError: There should be only one service component in this > sample expected:<1> but was:<2> > 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.jmx.test.blueprint.BlueprintMBeanTest.BlueprintSample(BlueprintMBeanTest.java:181) > 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:637) > > > > On 8/27/10 9:35 AM, zoe slattery wrote: >> Starting discussion thread for RC04. >> >> The only difference between this candidate and the last (RC03) is a >> change to fix a deadlock >> (https://issues.apache.org/jira/browse/ARIES-390) and another small >> change to fix a CT failure >> (https://issues.apache.org/jira/browse/ARIES-387). >> >> Zoë >> >> >> > > > -- > Joe
