-
15. Re: Default classloader for deserialization
Brian actually speaks about (correct me if I am wrong) a custom usage where each app starts it's own cache.
For 'shared' caches, such as http session repl and the like, a single cache is shared across webapps and using regions is the default here.
But using regions has it's own overhead and in the case where there is only one app using the cache, the default TCCL used should be the one that started the cache. -
16. Re: Default classloader for deserialization
yes, if the JBC instance is solely owned by one application then it would work as such.
But is that actually what happens today ? -
17. Re: Default classloader for deserialization
Not in the AS if a scoped classloader is used, i.e.:
1) Cache is deployed from an ear/sar with a loader-repository configured
2) (I'm pretty sure) if cache is deployed from a webapp (e.g. a ServletContextListener does it at startup.)
If region-based marshalling isn't used, the classloader JBC uses to deserialize messages is the one that loaded JBC itself. In the above cases, this classloader is a parent to the application's classloader, and thus can't see classes loaded by the parent classloader.
I mistakenly believed this would also cause problems with things deployed directly in /deploy (e.g. an ear without its own loader-repository) but experiments today show this is not the case. I assume this means the default UCL for the deploy dir also loads the jars in /server/all/lib (where jboss-cache.jar and jgroups.jar are located.) -
18. Re: Default classloader for deserialization
"bstansberry@jboss.com" wrote:
I assume this means the default UCL for the deploy dir also loads the jars in /server/all/lib (where jboss-cache.jar and jgroups.jar are located.)
I came to the same conclusion a few weeks ago.
jboss/lib - seems to be the bootstrap
jboss/server/xxx/lib - a UCL -
19. Re: Default classloader for deserialization
Guys, there's a good wiki (probably the clearest CL
explanation around) on CL and how they're structured
here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases
See Case2 where a class is defined in both, an
application's archive and in the server/all/lib.
"A singleton NoAnnotationClassLoader instance is created during the server's boot process and its job is to define classes available in the $JBOSS_HOME/lib libraries"
And that's parent to all UCLs. -
20. Re: Default classloader for deserialization
"bstansberry@jboss.com" wrote:
If region-based marshalling isn't used, the
classloader JBC uses to deserialize messages is the one that loaded JBC itself.
In the above cases, this classloader is a parent to the application's
classloader, and thus can't see classes loaded by the parent
classloader.
I guess you really mean that the parent classloader can't see classes loader
by the child classloader? i.e. when classes deployed on war or configured with
loader repository. -
-
22. Re: Default classloader for deserialization
"bstansberry@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 :)