The second bug related to class loading problems(#521058) is another problem that occurs when a MarshalledObject value is gotten and Class.forName(String, boolean, ClassLoader) is used. This time, the call occurs when a non-proxy class is being resolved and the code does not try to use the thread context class loader. Rather, it walks the call stack to find the first non-system ClassLoader on the stack. The stack that is in effect is:
java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:993) at java.lang.Class.forName(Class.java:205) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:121) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.inputArray(ObjectInputStream.java:1142) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:374) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.rmi.MarshalledObject.get(MarshalledObject.java:138) at org.jboss.invocation.MarshalledInvocation.getValue(MarshalledInvocation.java :281) at org.jboss.invocation.Invocation.getArguments(Invocation.java:167) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Stateles sSessionContainer.java:649) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSe ssionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor .java:96) ... The first class loader from a non-system ClassLoader is org.jboss.invocation.MarshalledInvocation which is loaded by the jboss.jar class loader. Since this class loader does not change when an ejb is redeployed, any ejb calls that pass in types that are loaded from the ejb jar are seen to be in conflict with the reployed values because Class.forName is returning the previously loaded byte code due to the jboss.jar ClassLoader to VM cache match. We need more control over which class loader is being used when accessing MarshalledObject value contents. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
