• New Feature
  • Status: Closed
  • 1 Critical
  • Resolution: Fixed
  • DSO:L1
  • teck
  • Reporter: steve
  • May 22, 2007
  • 9
  • Watchers: 7
  • April 10, 2009
  • March 02, 2009



Walter Harley 2009-02-25

Fixed in trunk, mostly with change 11812, some additional support in 11883.

To share classes between web apps, use config similar to the following:

contexta contextb

In addition to web apps, any registered loader can be shared by naming it explicitly; for instance, the standard system loader can be shared:

contexta Standard.system

To find classloader names, enable named-classloader debugging:


Tests are in tim-session-system-tests: AppGroupTest, AppGroupNSTest, AppGroupWebAndPojoTest, AppGroupWebAndPojoNSTest. The reason the tests are there is because container TIMs are needed to test the web-application support.

Note that DSO client tests that use IsolationClassLoader are able to share classes with DSO apps spawned out of process without any custom app-groups config, because IsolationClassLoader is special-cased and treated as if it was in the same app-group as the standard system loader by default.

Walter Harley 2009-02-25

Eh, I probably resolved this too soon. The core code changes have been made and support has been implemented in tomcat and (thus) glassfish, but other containers haven’t yet been completed; Tim is working on this. Assigning to him.

Tim Eck 2009-03-02

This is done with the exception of Webshere–CE. I opened another item (DEV-2485) to cover that remaining work

nadeem ghani 2009-03-10

verified with trunk versions of exam and examonitor and TC

Walter Harley 2009-03-16

The spec for this feature is attached to http://jira.terracotta.org/jira/browse/RMP-278, and the feature is fully detailed in the product docs (which may not yet be publicly available). There are a number of restrictions that should be noted; this bug report is NOT the full spec of the feature.

The most important restriction is that it is NOT possible to share data between two applications deployed to the same physical VM (ie the same TC node). The tc-config files for all nodes can be identical (thus it is still possible to get the configuration from the L2) but the applications themselves cannot be in the same VM.

The reason for this restriction is that we currently have no way to duplicate objects on a single VM; thus, a single object ID can only refer to a single POJO instance, whose classloader will therefore be wrong for one or the other of the sharing applications.