Re: webapp spring roots

I wish we had a better answer here. I completely agree that reshuffling
classes out of a WAR, and adding constraints around environment homogeny
(common app server, context paths, etc) are annoying at best and can
easily be too severe.

This mail might get a little long, but I'm going to spend a little time
discussing the problem of classloading as it applies to Terracotta. Mostly
I want to get a place where perhaps we can explore differing approaches
that might better work in your context. After that I'll offer up two more
workarounds, though I won't try to claim that they are pretty or even
palatable, but they could work.

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.

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

The two options are pretty similar (ie. take control of the loader name in
your code), they just differ on which class loader is operated on.

The APIs to rename and register loaders are pretty simple. The code
snippet in the middle of this forum post is an example:

http://forums.terracotta.org/forums/posts/list/505.page

Essentially the calls are:
((NamedClassLoader)loader).__tc_setClassLoaderName("name");
ClassProcessorHelper.registerGlobalLoader((NamedClassLoader)loader);

These calls can be made with reflection, or you can compile against our
API jar (available on our public maven repo).

Hope this helps. If you want more information about how to go about these
particular options, please let me know off list. For discussions about how
classloading and terracotta mix, please let's continue on the list.

-tim









 

 

servers if
> > more then one web application on the same server is using those
> > classes). Those classloaders will have the same names across
Terracotta
> > clister, when all clustered web apps are running on Tomcat. See [1]
for
_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users