[jboss-dev-forums] [Design of JBossCache] - Re: Default classloader for deserialization

[galder.zamarreno@jboss.com]

"bstansberry at jboss.com" wrote : Right now the default classloader JBC uses for deserializing RPC calls is the CL that loads RpcDispatcher. This thread is to discuss if that's the correct choice.
  | 
  | Would the TCCL in effect when the cache was deployed be a better option?  In the AS, this would likely be the default UCL for the deploy dir.  If the cache was specifically deployed as part of an scoped ear or sar or even a webapp, it would be the deployment's CL.
  | 
  | The same effect can be achieved by using the region API and registering the deployment CL for region "/", but:
  | 
  | 1) That requires programmatic intervention; a simple -service.xml deployment is insufficient.
  | 2) If forces use of VersionAwareMarshaller, i.e. serializing a region Fqn at the head of each RPC call.  Extra overhead.

Going back to Brian's original question, I guess TCCL would be a better option because in the worst case scenario, the CL repository will be a child of the repository where the RPCDispatcher was loaded, so if any class in the cache is not in the child repository, it'll look for it in the parent.

This seems to me much better option than loading with RPCDispatcher's CL cos you can't navigate downwards to find the class.

And obviously, it wouldn't make any sense to deploy a cache in an isolated EAR and expect to be able find a class that is loader by yet another isolated EAR.

So, it's +1 from me :)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989876#3989876

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989876