[jboss-remoting-issues] [JBoss JIRA] Commented: (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:comment-tabpanel&focusedCommentId=12438197#action_12438197 ] 

Ron Sigal commented on JBREM-1042:
----------------------------------

Changes similar to those made for JBREM-1019 have been applied to org.jboss.remoting.MicroRemoteClientInvoker, org.jboss.remoting.Remoting, and org.jboss.remoting.loading.RemotingClassLoader.

In particular, MicroRemoteClientInvoker will, during initialization, check the configuration map for Remoting.CLASSLOADING_PARENT_FIRST_DELEGATION (actual value "classloadingParentFirstDelegation") and the check the system property Remoting.CLASSLOADING_PARENT_FIRST_DELEGATION_PROP (actual value "org.jboss.remoting.classloadingParentFirstDelegation").  If it gets a value of "true", which is also the default value, then the unmarshaller used to unmarshal the result of an invocation will first try the org.jboss.remoting.loading.ClassByteClassLoader created at initialization and then try the thread context classloader.  If it gets a value of "false", then the thread context classloader is tried first.



> 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