[jboss-jira] [JBoss JIRA] Closed: (JBAS-4106) Allow use of classes from scoped loaders in ClusterPartition RPC calls

[Jerry Gauthier (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-4106?page=all ]

Jerry Gauthier closed JBAS-4106.
--------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta2
                       (was:  JBossAS-5.0.0.Beta3)
       Resolution: Done

Modified ClusterPartition implementation to support unmarshalling of custom classes in scoped classloader environments.

The HAPartition api has been modified by the addition of an overloaded registerRPCHandler( ) method with an additional ClassLoader parameter.

The ClusterPartition implementation has been modified to support this new method.

The RPCTestCase test class has been modified to include tests for RPC methods when classloaders are registered.

> Allow use of classes from scoped loaders in ClusterPartition RPC calls
> ----------------------------------------------------------------------
>
>                 Key: JBAS-4106
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4106
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Jerry Gauthier
>             Fix For: JBossAS-5.0.0.Beta2
>
>
> ClusterPartition RPC calls will currently fail if any classes in the RPC or in the return value are not visible to ClusterPartition's classloader.  This is because message unmarshalling will fail to resolve the scoped class.
> To fix this:
> 1) Add overloaded method registerRPCHandler(String key, Object handler, Classloader classloader) to ClusterPartition.
> 2) Add field ConcurrentHashMap<String, WeakReference<Classloader>> to ClusterPartition.
> 3) Refactor the way the service name is passed in the marshalled RPC.  Now it is dot appended to the RPC's method name.  Instead marshall it separately; e.g. the marshalled data structure could be new Object[] { serviceName, new MarshalledValue(methodCall) } or something like that.
> 4) Unmarshalling deserializes the above, reads the serviceName, looks up the classloader in the map; if found sets the TCCL, and then calls MarshalledValue.get() to get the MethodCall.
> Alternative is not to create a separate map for the classloaders, but change the current map that stores the handlers to instead store a simple data type that wraps the handler and the classloader.  Have to use a WeakReference for the classloader though.
> The existing usage where no classloader is registered still has to work; i.e. if no classloader is found don't touch the TCCL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira