[ https://jira.jboss.org/jira/browse/JBAS-7588?page=com.atlassian.jira.plug... ] jaikiran pai commented on JBAS-7588: ------------------------------------ Yes, fix to JBAS-7493 did also fix the org.jboss.test.ejb.lifecycle.test.StatefulSessionUnitTestCase failures. There are 2 more remaining failures: org.jboss.test.ejb.lifecycle.test.IndependentJarLifeCycleUnitTestCase.testRestartContainer org.jboss.test.ejb.lifecycle.test.IndependentJarLifeCycleUnitTestCase.testRestartPool I'll see what's causing these failures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7588?page=com.atlassian.jira.plug... ] jaikiran pai commented on JBAS-7588: ------------------------------------ This one is taking more time than i initially though it would :( The real issue isn't with this testcase org.jboss.test.ejb.lifecycle.test.IndependentJarLifeCycleUnitTestCase itself. This test (and the other similar testcase org.jboss.test.cts.test.IndependentJarsUnitTestCase) run fine for the first time. For example, consider the following scenario: 1) Start the server 2) Run IndependentJarLifeCycleUnitTestCase (or IndependentJarsUnitTestCase) [jpai@localhost testsuite]$ ./build.sh one-test -Dtest=org.jboss.test.ejb.lifecycle.test.IndependentJarLifeCycleUnitTestCase Searching for build.xml ... Buildfile: /NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/testsuite/build.xml ... one-test: [junit] Running org.jboss.test.ejb.lifecycle.test.IndependentJarLifeCycleUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 20.26 sec Runs successfully. Now run the same test (or the other one) again (without restarting the server). They fail with a CCE on the server side: 18:06:05,854 ERROR [org.jboss.test.cts.ejb.CallerSessionBean] Unexpected error: java.lang.ClassCastException: $Proxy256 cannot be cast to org.jboss.test.cts.interfaces.CallerSessionHome at org.jboss.test.cts.ejb.CallerSessionBean.lookupHome(CallerSessionBean.java:284) at org.jboss.test.cts.ejb.CallerSessionBean.simpleCall(CallerSessionBean.java:122) 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.jboss.invocation.Invocation.performCall(Invocation.java:386) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:233) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:228) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211) at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:97) at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:654) at org.jboss.ejb.Container.invoke(Container.java:1072) at sun.reflect.GeneratedMethodAccessor332.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897) at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:768) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:721) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:575) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) The QA Hudson environment too is experiencing the same thing as above. It first runs the org.jboss.test.cts.test.IndependentJarsUnitTestCase testcase, which passes and then it runs the org.jboss.test.ejb.lifecycle.test.IndependentJarLifeCycleUnitTestCase which fails: [junit] Running org.jboss.test.cts.test.IndependentJarsUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.393 sec [junit] Running org.jboss.test.cts.test.LongWaitStatefulSessionUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.942 sec ... (some more tests removed from the log) [junit] Running org.jboss.test.ejb.lifecycle.test.IndependentJarLifeCycleUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 8, Time elapsed: 4.002 sec [junit] Test org.jboss.test.ejb.lifecycle.test.IndependentJarLifeCycleUnitTestCase FAILED While looking into this, i notice that for some reason, the second run uses the proxy which was loaded by the previous run's classloader, and tries to cast it to the CallerSessionHome which was loaded by this test run's classloader. The logs further indicate that after the first test completes (successfully), the classloader is unregistered/shutdown. So ideally, it shouldn't come into play during the next run of a testcase. But the logs of the second test run do show that the JNDI proxy was indeed loaded through the first run's classloader. I don't yet have a complete grasp of what's going on. Have been digging through the classloading logs and the testcase to understand the flow. I'll continue looking into the logs to see what the root cause is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7588?page=com.atlassian.jira.plug... ] Adrian Brock commented on JBAS-7588: ------------------------------------ NOTE: There's probably a similar problem with java.rmi.server.codebase which is setup in org.jboss.web.Webservice (also now in deploy/legacy-jboss-service.xml) and has the same semantics. i.e. you have to set the property before anything uses RMI. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7588?page=com.atlassian.jira.plug... ] jaikiran pai commented on JBAS-7588: ------------------------------------ For this one, i'll check with Brian, because this uses the ServiceBindingManager (SBM) to get hold of the port. Right now, the SBM is deployed before anything else, but i remember Brian had plans to move this to the deploy folder. So to set the java.rmi.server.codebase early enough, the SBM needs to be available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7588?page=com.atlassian.jira.plug... ] Brian Stansberry commented on JBAS-7588: ---------------------------------------- Ok, so this ties in to the general problem of moving jboss:service=WebServer out of conf/jboss-service.xml and into deploy/. See http://community.jboss.org/thread/146133 for a partial discussion. The trick to the whole thing is java.rmi.server.RMIClassLoaderSpi and java.rmi.server.codebase have to be set before anything binds anything into JNDI, because the bind operation creates a javax.rmi.MarshalledObject, which triggers the one-time-only read of these properties that Adrian alludes to. A semi-elegant fix is to move LocalNamingBean to deploy and establish correct dependencies. This causes difficulties for any deployer that directly binds stuff in JNDI. Surmountable difficulties, but difficulties. The question is whether to do that, or just hack something for M2 pending ProfileService work in M3 that AIUI is going to make the whole conf/jboss-service.xml, deployers/, deploy/ distinction obsolete. My plan was to decide on that next week, once all the component upgrades for M2 are done. I've got a bunch of M2 JIRAs assigned to me related to this. A month ago I worked through and tested how to move everything into deploy, it's mostly a matter of checking whether M2 actually *has* deployers that directly bind stuff in JNDI and then making a go/no-go decision. There were some in the plans a month ago, but last I checked they weren't actually implemented. Moving jboss:service=WebServer back into conf/jboss-service.xml won't work without ugly hacking. It depends on David Lloyd's threads stuff, which in turn depends on deployers/jboss-threads.deployer. Jaikiran, feel free to assign this JIRA to me, unless your r100158 is sufficient to fix the test; otherwise it's just part of the overall work. Thanks for your help on this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7588?page=com.atlassian.jira.plug... ] jaikiran pai resolved JBAS-7588. -------------------------------- Fix Version/s: JBossAS-6.0.0.M2 Resolution: Done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira