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

[Ron Sigal (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBREM-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1042:
-----------------------------

                 Fix Version/s: 2.2.2.SP11
                                    (was: 2.4.0.SP1 (Pinto))
         JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=143067&start=0
             Affects Version/s: 2.2.2.SP10
                                    (was: 2.4.0.GA (Pinto))
                   Description: 
>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.

  was:
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.




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

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