[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-1042) CLONE [JBREM-1019] - RemotingClassLoader needs option to delegate to user class loader before parent

CLONE [JBREM-1019] - RemotingClassLoader needs option to delegate to user class loader before parent ---------------------------------------------------------------------------------------------------- Key: JBREM-1042 URL: https://jira.jboss.org/jira/browse/JBREM-1042 Project: JBoss Remoting Issue Type: Bug Security Level: Public(Everyone can see) Affects Versions: 2.2.2.SP10 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP11 From JBREM-1019: For the jbossas5 app client container, a class loader policy that loads from the child first is used to pickup the client jar manifest references. If such a class loader is registered as the user class loader with the RemotingClassLoader, its not going be delegated to first. This results in duplicate and conflicting classes being loaded. The same need arises in AS 4.2/4.3. In particular, org.jboss.remoting.MicroRemoteClientInvoker sets the parent of org.jboss.remoting.loading.RemotingClassLoader to org.jboss.remoting.loading.ClassByteClassLoader, which, if remote classloading is enabled, will try to load over the network first. If a class is available both remotely and locally, ClassCastExceptions can occur. If MicroRemoteClientInvoker can be configured to set RemotingClassLoader's parent to the current context classloader, and to set RemotingClassLoader's secondary classloader to the ClassByteClassLoader, then remote classloading will be attempted only if a class cannot be found locally.