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] Commented: (ARIES-339) Aries builds fail due to incorrectly working setUp() methods in JMX itests
Date Wed, 16 Jun 2010 14:31:23 GMT

    [ https://issues.apache.org/jira/browse/ARIES-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879350#action_12879350
] 

Bartosz Kowalewski commented on ARIES-339:
------------------------------------------

Hi Jarek,

It looks good. 

Sorry for not removing the nice example of copy/paste pattern :-).

Thanks,
  Bartek

> Aries builds fail due to incorrectly working setUp() methods in JMX itests
> --------------------------------------------------------------------------
>
>                 Key: ARIES-339
>                 URL: https://issues.apache.org/jira/browse/ARIES-339
>             Project: Aries
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 0.2
>            Reporter: Bartosz Kowalewski
>            Assignee: Jarek Gawor
>             Fix For: 0.2
>
>         Attachments: aries-339.patch
>
>
> 1. There's a method annotated with @Before in the abstract test class. Most concrete
test classes also have methods annotated with @Before which inside their body also call the
the setUp() method from the abstract class. During a build both methods (the one from the
abstract class and the one from the concrete one) are called and the one from the subclass
is called first :|. This method  setups mbean server and then checks if required mbeans have
been registered. After it completes, the the setUp() method from the super class is called
directly. It creates a new mbean server - overrides the previous one. The new one is not prepared
to be used inside the test method as mbeans haven't been registered yet and there's no code
that would wait for those mbeans to be registered. This causes an exception to be thrown in
various tests and build to fail. Example:
> java.lang.reflect.InvocationTargetException
> 	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)
> Caused by: java.lang.reflect.InvocationTargetException
> 	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)
> 	... 19 more
> Caused by: java.lang.reflect.UndeclaredThrowableException
> 	at $Proxy8.getExportedPackages(Unknown Source)
> 	at org.apache.aries.jmx.framework.BundleStateMBeanTest.testMBeanInterface(BundleStateMBeanTest.java:153)
> 	... 25 more
> Caused by: javax.management.InstanceNotFoundException: osgi.core:type=bundleState,version=1.5
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
> 	at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288)
> 	... 27 more
> 2. FrameworkMBeanTest does not wait for the FrameworkMBean at all.
> 3. Tests wait 5 seconds for mbeans to be registered. This is often not sufficient enough.
> 4. Some other minor changes are required.
> A patch coming soon. 
> Unfortunately, the list of JMX itests issues provided above is not complete. Additional
experiments need to be carried out and some other fixes will probably be required.

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