Tim Eck wrote: Tim, I'd like to discuss possible alternatives to the custom classloader renaming you have suggested in your email to [EMAIL PROTECTED] > The terracotta client that resides in each VM in your cluster applies to > the entire VM. The point here is the relationship is 1:1 between the VM > and the terracotta client. Another way to make that point is that the > terracotta client is not bound to a single web application (or that each > web application gets its own terracotta client instance). Given this > relationship, and that we want to accept objects for clustering no matter > which loader defined has led to the current implementation of assigning > identity/names to loaders. Each terracotta client has a local registry > where loaders can be found by name. I guess at the most basic level, the > issue is that when previously clustered objects are accessed in another > node, there must be some way to resolve a classloader to use to > manufacture the object (other ideas about how to do loader resolving > welcome). > > So the other workarounds that can operate in scheme of loader naming are > (and can stay within the WAR): > 1) Override the terracotta names assigned to tomcat/jetty/etc loaders to > manually force the desired equivalence. This implies calling > __tc_setClassLoaderName(String) on the loaders you want to rename and then > re-registering them with Terracotta. > One idea to make this more declarative is to allow to specify the classloader name for the web application we cluster with DSO, e.g. add new attribute to <web-application> element that would allow to specify such name. Then if this attribute is there DSO could use it to name the class loader accordingly.
> 2) Create and use your own classloader for accessing your shared cache. > Again, the classloader name would be in your control so that it can be > made common across differing app servers and/or context paths, virtual > hosts, etc For this option we could do something similar, e.g. allow user to name classloaders based on some rules. Possible options are: -- matching by classloader class, -- matching on resources/jars used to initialize the URL class loader, -- using AspectWerkz expressions to assign name upon clasloader creation or access based on the specified joinpoint expression (within(), execute(), call(), etc). Those, of course, won't solve the roots of class loader naming issues, but at least users could configure naming declaratively. without changing their apps. regards, Eugene _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
