All I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) All of which are related to serialization of proxies. David is going to take a look on Sunday at these. If you see other failures locally, please investigate or discuss :-) Pete _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

I see 0 failing core tests and the 3 TCK tests Pete mentioned (incontainer on a M3) On Sun, May 23, 2010 at 12:41 PM, David Allen <drallendc(a)gmail.com&gt; wrote: I have had the following failures on the TCK running out of container for almost the last two months now: Failed tests: testDecoratorInvokesDelegateMethodOutsideOfBusinessMethodInterception(org.jboss.jsr299.tck.tests.decorators.invocation.DecoratorInvocationTest) testAmbiguousELNamesResolved(org.jboss.jsr299.tck.tests.lookup.byname.ResolutionByNameTest) testFieldNameUsedAsBeanName(org.jboss.jsr299.tck.tests.lookup.byname.ResolutionByNameTest) testNewBean(org.jboss.jsr299.tck.tests.lookup.dynamic.DynamicLookupTest) I have not investigated any of these as of yet. They were already there before I started changing anything in Weld, so I believe they are independent of proxies or other memory saving techniques. - David Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir: > All > > I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: > > testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) > testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) > testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) > > All of which are related to serialization of proxies. David is going to take a look on Sunday at these. > > If you see other failures locally, please investigate or discuss :-) > > Pete > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev -- --- Nik

I see 0 failing core tests and the 3 TCK tests Pete mentioned (incontainer on a M3) On Sun, May 23, 2010 at 12:41 PM, David Allen <drallendc(a)gmail.com&gt; wrote: I have had the following failures on the TCK running out of container for almost the last two months now: Failed tests: testDecoratorInvokesDelegateMethodOutsideOfBusinessMethodInterception(org.jboss.jsr299.tck.tests.decorators.invocation.DecoratorInvocationTest) testAmbiguousELNamesResolved(org.jboss.jsr299.tck.tests.lookup.byname.ResolutionByNameTest) testFieldNameUsedAsBeanName(org.jboss.jsr299.tck.tests.lookup.byname.ResolutionByNameTest) testNewBean(org.jboss.jsr299.tck.tests.lookup.dynamic.DynamicLookupTest) I have not investigated any of these as of yet. They were already there before I started changing anything in Weld, so I believe they are independent of proxies or other memory saving techniques. - David Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir: > All > > I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: > > testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) > testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) > testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) > > All of which are related to serialization of proxies. David is going to take a look on Sunday at these. > > If you see other failures locally, please investigate or discuss :-) > > Pete > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev -- --- Nik

The last two tests now pass. The first one still fails and will need further investigation. There also appears to be yet another failure regarding the remove method test for EJBs. I'll take a look at that one too. Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir: > All > > I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: > > testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) > testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) > testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) > > All of which are related to serialization of proxies. David is going to take a look on Sunday at these. > > If you see other failures locally, please investigate or discuss :-) > > Pete > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

On 25 May 2010, at 15:25, Pete Muir wrote: > David, can you concentrate on the testSerializeSFSB. > > I am getting to testRemoveEjbIgnored right now. Ok, I found that the problem is the same as we discussed before - that the current proxying is too super-class centric. Because non no-interface-view ejbs don't really have a super class, the ContextBeanInstance is picking one of the two business interfaces (essentially at random hence why the test sometimes works) as the super class, not considering both. I could hack this so that we make sure all interfaces are added, but I think it is better to redo the proxies to support using multiple interfaces with Object.class as the superclass. David, WDYT? > > On 24 May 2010, at 19:38, David Allen wrote: > >> The last two tests now pass. The first one still fails and will need >> further investigation. There also appears to be yet another failure >> regarding the remove method test for EJBs. I'll take a look at that one >> too. >> >> Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir: >>> All >>> >>> I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: >>> >>> testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) >>> testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >>> testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >>> >>> All of which are related to serialization of proxies. David is going to take a look on Sunday at these. >>> >>> If you see other failures locally, please investigate or discuss :-) >>> >>> Pete >>> >>> >>> _______________________________________________ >>> weld-dev mailing list >>> weld-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev

On 25 May 2010, at 16:44, David Allen wrote: > Yes, I already found that out regarding that test and already made the > changes necessary for the EJB proxy. Now it is also needed for the > client proxy. Exactly, the change I did to the EnterpriseProxyFactory to add all types which are interfaces (which is what fixed the EJB proxy) is really a hack, I think we have to redesign proxies to not be so superclass orientated. We should only add the bean types to the proxy for any proxy. At the moment we take the instance type, and work out what it's types are - IMO this is wrong, we know exactly what types the bean has (bean.getTypes()) and so we should use that. There is some trickery (but also existing code in TypeInfo) to establish from that set what the superclass is, if there is one. If there isn't, Object.class should be the superclass. Agreed?

> The testSerializeSFSB test is broken due to perhaps changes in the > design of JBoss EJB. It is now trying to serialize MC classes which > then cannot be deserialized because they are not available through the > classloader used by the app. This still requires some investigation to > see if some part of the handler should actually not be serialized, or if > so, how the correct CL is going to be obtained for MC beans. > > - David > > Am Dienstag, den 25.05.2010, 15:47 +0100 schrieb Pete Muir: >> On 25 May 2010, at 15:25, Pete Muir wrote: >> >>> David, can you concentrate on the testSerializeSFSB. >>> >>> I am getting to testRemoveEjbIgnored right now. >> >> Ok, I found that the problem is the same as we discussed before - that the current proxying is too super-class centric. Because non no-interface-view ejbs don't really have a super class, the ContextBeanInstance is picking one of the two business interfaces (essentially at random hence why the test sometimes works) as the super class, not considering both. >> >> I could hack this so that we make sure all interfaces are added, but I think it is better to redo the proxies to support using multiple interfaces with Object.class as the superclass. David, WDYT? >> >>> >>> On 24 May 2010, at 19:38, David Allen wrote: >>> >>>> The last two tests now pass. The first one still fails and will need >>>> further investigation. There also appears to be yet another failure >>>> regarding the remove method test for EJBs. I'll take a look at that one >>>> too. >>>> >>>> Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir: >>>>> All >>>>> >>>>> I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: >>>>> >>>>> testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) >>>>> testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >>>>> testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >>>>> >>>>> All of which are related to serialization of proxies. David is going to take a look on Sunday at these. >>>>> >>>>> If you see other failures locally, please investigate or discuss :-) >>>>> >>>>> Pete >>>>> >>>>> >>>>> _______________________________________________ >>>>> weld-dev mailing list >>>>> weld-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>>> >>>> >>>> _______________________________________________ >>>> weld-dev mailing list >>>> weld-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>> >>> >>> _______________________________________________ >>> weld-dev mailing list >>> weld-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/weld-dev >> > >

All the tests are now passing except for the following: testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) This requires more investigation since the test involves serializing EJB container objects not normally accessible from the app. - David Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir: > All > > I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: > > testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) > testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) > testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) > > All of which are related to serialization of proxies. David is going to take a look on Sunday at these. > > If you see other failures locally, please investigate or discuss :-) > > Pete > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev

Have you worked out what the call stack to the serialization is? On 26 May 2010, at 12:09, David Allen wrote: > The stack trace for the test that is failing is below. If anyone has any ideas on why this happens, it would be greatly appreciated. My guess is that during deserialization of the EnterpriseBeanProxyMethodHandler, the SessionObjectReference from the SPI cannot be deserialized. I am not even sure how valid it is in the first place for an app to serialize that and later deserialize it. > > Is it designed for this purpose? Is it going to work across servers in a cluster environment? > > Caused by: java.lang.ClassNotFoundException: org.jboss.reloaded.naming.deployers.mc.MCJavaEEModule > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:247) > at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604) > at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) > at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at org.jboss.util.collection.ConcurrentSkipListMap.readObject(ConcurrentSkipListMap.java:1771) > at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at java.util.concurrent.CopyOnWriteArrayList.readObject(CopyOnWriteArrayList.java:845) > at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1157) > at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) > at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at java.util.TreeMap.buildFromSorted(TreeMap.java:2380) > at java.util.TreeMap.buildFromSorted(TreeMap.java:2396) > at java.util.TreeMap.buildFromSorted(TreeMap.java:2322) > at java.util.TreeMap.readTreeSet(TreeMap.java:2274) > at java.util.TreeSet.readObject(TreeSet.java:518) > at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1156) > at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) > at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1154) > at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) > at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.readExternal(AbstractDeploymentUnit.java:514) > at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at org.jboss.weld.lang.Object_$$_WeldProxy.deserializeProxy(Object_$$_WeldProxy.java) > ... 67 more > ... Removed 47 stack frames > > Am Mittwoch, den 26.05.2010, 12:05 +0200 schrieb David Allen: >> All the tests are now passing except for the following: >> >> testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) >> >> This requires more investigation since the test involves serializing EJB >> container objects not normally accessible from the app. >> >> - David >> >> Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir: >> > All >> > >> > I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: >> > >> > testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) >> > testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >> > testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >> > >> > All of which are related to serialization of proxies. David is going to take a look on Sunday at these. >> > >> > If you see other failures locally, please investigate or discuss :-) >> > >> > Pete >> > >> > >> > _______________________________________________ >> > weld-dev mailing list >> > >> weld-dev(a)lists.jboss.org >> >> > >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev

Sorry, call stack was the wrong word - I mean the stack of objects that are being serialized - i.e. what is the path through the object graph to deserialization failure. On 26 May 2010, at 12:24, David Allen wrote: > Do you mean where in the test we deserialize the EJB? I didn't think it was very interesting since it is rather clear from the test where the serialization and deserialization occur. Below is the stack trace for the actual deserialization which occurs immediately after the serialization with the same initial call stack: > > FAILED: testSerializeSFSB > org.jboss.weld.exceptions.WeldException: WELD-001500 Failed to deserialize proxy object > at org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:124) > at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at org.jboss.jsr299.tck.AbstractJSR299Test.deserialize(AbstractJSR299Test.java:63) > at org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest.testSerializeSFSB(EnterpriseBeanLifecycleTest.java:102) > at org.jboss.testharness.AbstractTest.run(AbstractTest.java:244) > at org.jboss.testharness.impl.runner.TestRunner.run(TestRunner.java:61) > at org.jboss.testharness.impl.runner.servlet.ServletTestRunner.doGet(ServletTestRunner.java:120) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) > at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:68) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:293) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183) > at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95) > at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) > at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:872) > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) > at java.lang.Thread.run(Thread.java:619) > at org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:120) > ... 62 more > > Am Mittwoch, den 26.05.2010, 12:14 +0100 schrieb Pete Muir: >> Have you worked out what the call stack to the serialization is? >> On 26 May 2010, at 12:09, David Allen wrote: >> >> > The stack trace for the test that is failing is below. If anyone has any ideas on why this happens, it would be greatly appreciated. My guess is that during deserialization of the EnterpriseBeanProxyMethodHandler, the SessionObjectReference from the SPI cannot be deserialized. I am not even sure how valid it is in the first place for an app to serialize that and later deserialize it. >> > >> > Is it designed for this purpose? Is it going to work across servers in a cluster environment? >> > >> > Caused by: java.lang.ClassNotFoundException: org.jboss.reloaded.naming.deployers.mc.MCJavaEEModule >> > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) >> > at java.security.AccessController.doPrivileged(Native Method) >> > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) >> > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) >> > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) >> > at java.lang.Class.forName0(Native Method) >> > at java.lang.Class.forName(Class.java:247) >> > at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604) >> > at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575) >> > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) >> > at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312) >> > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >> > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >> > at org.jboss.util.collection.ConcurrentSkipListMap.readObject(ConcurrentSkipListMap.java:1771) >> > at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >> > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >> > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >> > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >> > at java.util.concurrent.CopyOnWriteArrayList.readObject(CopyOnWriteArrayList.java:845) >> > at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >> > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >> > at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1157) >> > at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) >> > at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >> > at java.util.TreeMap.buildFromSorted(TreeMap.java:2380) >> > at java.util.TreeMap.buildFromSorted(TreeMap.java:2396) >> > at java.util.TreeMap.buildFromSorted(TreeMap.java:2322) >> > at java.util.TreeMap.readTreeSet(TreeMap.java:2274) >> > at java.util.TreeSet.readObject(TreeSet.java:518) >> > at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >> > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >> > at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1156) >> > at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) >> > at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >> > at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1154) >> > at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) >> > at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >> > at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.readExternal(AbstractDeploymentUnit.java:514) >> > at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >> > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >> > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >> > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >> > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >> > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >> > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >> > at org.jboss.weld.lang.Object_$$_WeldProxy.deserializeProxy(Object_$$_WeldProxy.java) >> > ... 67 more >> > ... Removed 47 stack frames >> > >> > Am Mittwoch, den 26.05.2010, 12:05 +0200 schrieb David Allen: >> >> All the tests are now passing except for the following: >> >> >> >> testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) >> >> >> >> This requires more investigation since the test involves serializing EJB >> >> container objects not normally accessible from the app. >> >> >> >> - David >> >> >> >> Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir: >> >> > All >> >> > >> >> > I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: >> >> > >> >> > testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) >> >> > testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >> >> > testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >> >> > >> >> > All of which are related to serialization of proxies. David is going to take a look on Sunday at these. >> >> > >> >> > If you see other failures locally, please investigate or discuss :-) >> >> > >> >> > Pete >> >> > >> >> > >> >> > _______________________________________________ >> >> > weld-dev mailing list >> >> > >> >> >> weld-dev(a)lists.jboss.org >> >> >> >> >> > >> >> >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> >> >> >> >> >> > >> > _______________________________________________ >> > weld-dev mailing list >> > >> weld-dev(a)lists.jboss.org >> >> > >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev

The only way I know to do it is to do it manually by breaking on the exception and working back up through the serialization calls and construct it on a piece of paper. I guess the Mac has debug symbols inside the JDK as I can break / debug them fine.

On 26 May 2010, at 15:21, David Allen wrote: > At the moment, I am not sure how to go about tracing through the call > graph. I think it would require a JDK with a debug version of the rt in > oder to evaluate the symbols. > > I also have very limited time this week, so I cannot do this very fast. > > Am Mittwoch, den 26.05.2010, 12:27 +0100 schrieb Pete Muir: >> Sorry, call stack was the wrong word - I mean the stack of objects that are being serialized - i.e. what is the path through the object graph to deserialization failure. >> >> On 26 May 2010, at 12:24, David Allen wrote: >> >>> Do you mean where in the test we deserialize the EJB? I didn't think it was very interesting since it is rather clear from the test where the serialization and deserialization occur. Below is the stack trace for the actual deserialization which occurs immediately after the serialization with the same initial call stack: >>> >>> FAILED: testSerializeSFSB >>> org.jboss.weld.exceptions.WeldException: WELD-001500 Failed to deserialize proxy object >>> at org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:124) >>> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>> at org.jboss.jsr299.tck.AbstractJSR299Test.deserialize(AbstractJSR299Test.java:63) >>> at org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest.testSerializeSFSB(EnterpriseBeanLifecycleTest.java:102) >>> at org.jboss.testharness.AbstractTest.run(AbstractTest.java:244) >>> at org.jboss.testharness.impl.runner.TestRunner.run(TestRunner.java:61) >>> at org.jboss.testharness.impl.runner.servlet.ServletTestRunner.doGet(ServletTestRunner.java:120) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) >>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336) >>> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) >>> at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:68) >>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) >>> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) >>> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:293) >>> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) >>> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183) >>> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95) >>> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) >>> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) >>> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) >>> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) >>> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) >>> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) >>> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) >>> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:872) >>> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) >>> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) >>> at java.lang.Thread.run(Thread.java:619) >>> at org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:120) >>> ... 62 more >>> >>> Am Mittwoch, den 26.05.2010, 12:14 +0100 schrieb Pete Muir: >>>> Have you worked out what the call stack to the serialization is? >>>> On 26 May 2010, at 12:09, David Allen wrote: >>>> >>>>> The stack trace for the test that is failing is below. If anyone has any ideas on why this happens, it would be greatly appreciated. My guess is that during deserialization of the EnterpriseBeanProxyMethodHandler, the SessionObjectReference from the SPI cannot be deserialized. I am not even sure how valid it is in the first place for an app to serialize that and later deserialize it. >>>>> >>>>> Is it designed for this purpose? Is it going to work across servers in a cluster environment? >>>>> >>>>> Caused by: java.lang.ClassNotFoundException: org.jboss.reloaded.naming.deployers.mc.MCJavaEEModule >>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:202) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:190) >>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:307) >>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:248) >>>>> at java.lang.Class.forName0(Native Method) >>>>> at java.lang.Class.forName(Class.java:247) >>>>> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604) >>>>> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575) >>>>> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) >>>>> at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312) >>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>> at org.jboss.util.collection.ConcurrentSkipListMap.readObject(ConcurrentSkipListMap.java:1771) >>>>> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>> at java.util.concurrent.CopyOnWriteArrayList.readObject(CopyOnWriteArrayList.java:845) >>>>> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>> at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1157) >>>>> at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) >>>>> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>> at java.util.TreeMap.buildFromSorted(TreeMap.java:2380) >>>>> at java.util.TreeMap.buildFromSorted(TreeMap.java:2396) >>>>> at java.util.TreeMap.buildFromSorted(TreeMap.java:2322) >>>>> at java.util.TreeMap.readTreeSet(TreeMap.java:2274) >>>>> at java.util.TreeSet.readObject(TreeSet.java:518) >>>>> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>> at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1156) >>>>> at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) >>>>> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>> at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1154) >>>>> at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) >>>>> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>> at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.readExternal(AbstractDeploymentUnit.java:514) >>>>> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>> at org.jboss.weld.lang.Object_$$_WeldProxy.deserializeProxy(Object_$$_WeldProxy.java) >>>>> ... 67 more >>>>> ... Removed 47 stack frames >>>>> >>>>> Am Mittwoch, den 26.05.2010, 12:05 +0200 schrieb David Allen: >>>>>> All the tests are now passing except for the following: >>>>>> >>>>>> testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) >>>>>> >>>>>> This requires more investigation since the test involves serializing EJB >>>>>> container objects not normally accessible from the app. >>>>>> >>>>>> - David >>>>>> >>>>>> Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir: >>>>>>> All >>>>>>> >>>>>>> I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: >>>>>>> >>>>>>> testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) >>>>>>> testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >>>>>>> testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >>>>>>> >>>>>>> All of which are related to serialization of proxies. David is going to take a look on Sunday at these. >>>>>>> >>>>>>> If you see other failures locally, please investigate or discuss :-) >>>>>>> >>>>>>> Pete >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> weld-dev mailing list >>>>>>> >>>>>> >>>> weld-dev(a)lists.jboss.org >>>> >>>>>> >>>>>>> >>>>>> >>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> weld-dev mailing list >>>>> >>>> weld-dev(a)lists.jboss.org >>>> >>>>> >>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>>> >>>> >>>> >>> >>> _______________________________________________ >>> weld-dev mailing list >>> weld-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/weld-dev >> > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev

I really see no way at the moment to do this with Sun JDK. It is a long standing issue that there is no variable debug symbol info in the JRE, and debugging object streams is very difficult. Pete - if you really have the debug symbols, you may need to take a look at this. Am Mittwoch, den 26.05.2010, 15:37 +0100 schrieb Pete Muir: > The only way I know to do it is to do it manually by breaking on the exception and working back up through the serialization calls and construct it on a piece of paper. > > I guess the Mac has debug symbols inside the JDK as I can break / debug them fine. > > On 26 May 2010, at 15:21, David Allen wrote: > >> At the moment, I am not sure how to go about tracing through the call >> graph. I think it would require a JDK with a debug version of the rt in >> oder to evaluate the symbols. >> >> I also have very limited time this week, so I cannot do this very fast. >> >> Am Mittwoch, den 26.05.2010, 12:27 +0100 schrieb Pete Muir: >>> Sorry, call stack was the wrong word - I mean the stack of objects that are being serialized - i.e. what is the path through the object graph to deserialization failure. >>> >>> On 26 May 2010, at 12:24, David Allen wrote: >>> >>>> Do you mean where in the test we deserialize the EJB? I didn't think it was very interesting since it is rather clear from the test where the serialization and deserialization occur. Below is the stack trace for the actual deserialization which occurs immediately after the serialization with the same initial call stack: >>>> >>>> FAILED: testSerializeSFSB >>>> org.jboss.weld.exceptions.WeldException: WELD-001500 Failed to deserialize proxy object >>>> at org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:124) >>>> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>> at org.jboss.jsr299.tck.AbstractJSR299Test.deserialize(AbstractJSR299Test.java:63) >>>> at org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest.testSerializeSFSB(EnterpriseBeanLifecycleTest.java:102) >>>> at org.jboss.testharness.AbstractTest.run(AbstractTest.java:244) >>>> at org.jboss.testharness.impl.runner.TestRunner.run(TestRunner.java:61) >>>> at org.jboss.testharness.impl.runner.servlet.ServletTestRunner.doGet(ServletTestRunner.java:120) >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) >>>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336) >>>> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) >>>> at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:68) >>>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) >>>> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) >>>> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:293) >>>> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) >>>> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183) >>>> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95) >>>> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) >>>> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) >>>> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) >>>> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) >>>> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) >>>> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) >>>> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) >>>> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:872) >>>> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) >>>> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) >>>> at java.lang.Thread.run(Thread.java:619) >>>> at org.jboss.weld.bean.proxy.util.SerializableProxy.readObject(SerializableProxy.java:120) >>>> ... 62 more >>>> >>>> Am Mittwoch, den 26.05.2010, 12:14 +0100 schrieb Pete Muir: >>>>> Have you worked out what the call stack to the serialization is? >>>>> On 26 May 2010, at 12:09, David Allen wrote: >>>>> >>>>>> The stack trace for the test that is failing is below. If anyone has any ideas on why this happens, it would be greatly appreciated. My guess is that during deserialization of the EnterpriseBeanProxyMethodHandler, the SessionObjectReference from the SPI cannot be deserialized. I am not even sure how valid it is in the first place for an app to serialize that and later deserialize it. >>>>>> >>>>>> Is it designed for this purpose? Is it going to work across servers in a cluster environment? >>>>>> >>>>>> Caused by: java.lang.ClassNotFoundException: org.jboss.reloaded.naming.deployers.mc.MCJavaEEModule >>>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:202) >>>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:190) >>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:307) >>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:248) >>>>>> at java.lang.Class.forName0(Native Method) >>>>>> at java.lang.Class.forName(Class.java:247) >>>>>> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604) >>>>>> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575) >>>>>> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) >>>>>> at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1462) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312) >>>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>>> at org.jboss.util.collection.ConcurrentSkipListMap.readObject(ConcurrentSkipListMap.java:1771) >>>>>> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >>>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>>> at java.util.concurrent.CopyOnWriteArrayList.readObject(CopyOnWriteArrayList.java:845) >>>>>> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >>>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>>> at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1157) >>>>>> at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) >>>>>> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>>> at java.util.TreeMap.buildFromSorted(TreeMap.java:2380) >>>>>> at java.util.TreeMap.buildFromSorted(TreeMap.java:2396) >>>>>> at java.util.TreeMap.buildFromSorted(TreeMap.java:2322) >>>>>> at java.util.TreeMap.readTreeSet(TreeMap.java:2274) >>>>>> at java.util.TreeSet.readObject(TreeSet.java:518) >>>>>> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) >>>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>>> at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1156) >>>>>> at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) >>>>>> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>>> at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.readExternal(AbstractDeploymentContext.java:1154) >>>>>> at org.jboss.deployers.vfs.plugins.structure.AbstractVFSDeploymentContext.readExternal(AbstractVFSDeploymentContext.java:558) >>>>>> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>>> at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.readExternal(AbstractDeploymentUnit.java:514) >>>>>> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) >>>>>> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) >>>>>> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) >>>>>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) >>>>>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) >>>>>> at org.jboss.weld.lang.Object_$$_WeldProxy.deserializeProxy(Object_$$_WeldProxy.java) >>>>>> ... 67 more >>>>>> ... Removed 47 stack frames >>>>>> >>>>>> Am Mittwoch, den 26.05.2010, 12:05 +0200 schrieb David Allen: >>>>>>> All the tests are now passing except for the following: >>>>>>> >>>>>>> testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) >>>>>>> >>>>>>> This requires more investigation since the test involves serializing EJB >>>>>>> container objects not normally accessible from the app. >>>>>>> >>>>>>> - David >>>>>>> >>>>>>> Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir: >>>>>>>> All >>>>>>>> >>>>>>>> I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally: >>>>>>>> >>>>>>>> testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) >>>>>>>> testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >>>>>>>> testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest) >>>>>>>> >>>>>>>> All of which are related to serialization of proxies. David is going to take a look on Sunday at these. >>>>>>>> >>>>>>>> If you see other failures locally, please investigate or discuss :-) >>>>>>>> >>>>>>>> Pete >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> weld-dev mailing list >>>>>>>> >>>>>>> >>>>> weld-dev(a)lists.jboss.org >>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> weld-dev mailing list >>>>>> >>>>> weld-dev(a)lists.jboss.org >>>>> >>>>>> >>>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> weld-dev mailing list >>>> weld-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/weld-dev >>> >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >