• Bug
  • Status: Resolved
  • 2 Major
  • Resolution: Won't Fix
  • interfaces
  • Reporter: teck
  • February 12, 2009
  • 0
  • Watchers: 1
  • February 12, 2014
  • February 12, 2014


source: http://forums.terracotta.org/forums/posts/list/1794.page

If tc.jar (and/or other terracotta jars) are added in inappropriate places, strange/bad things can happen. For instance. this code in PortabilityImpl.isClassPhysicallyInstrumented() can return confusing resuts:

Class interfaces[] = clazz.getInterfaces();
if (interfaces == null || interfaces.length == 0) return false;
for (int i = 0; i < interfaces.length; i++) {
  if (interfaces[i] == TransparentAccess.class) {
    rv = true;

What can go wrong is the line “ if (interfaces[i] == TransparentAccess.class) {”. PortabilityImpl runs in the context of the terracotta loader (whose parent is the bootstrap loader). The terracotta loader always delegates first (like most class loaders), so it’s impression of TransaprentAccess will always be the version in the boot jar.

If tc.jar is also out in regular land, and there is a classloader that doesn’t do parent first delegation (which is not unusual for web apps), then a class that is actually instrumented might fail this check becuase the version of TransparentAccess on it will be loaded from the web app (as opposed to the boot jar).

Even if the check in isClassPhysicallyInstrumented() was based on string names, it would just lead to ClassCastException later when the L1 client tried to cast a shared object to TransaprentAccess.

Anyway, I’m not convinced this is a good idea, but we could try to detect this type of misconfiguration and provide messaging on how to fix things. Another idea would be to try to compensate for such a setup and have it just work automagically (though that really doesn’t sound like a good idea).


Chris Dennis 2009-02-24

Could we perhaps do this by sealing the relevant packages in tc.jar? (Not sure how this would interact with the boot-jar though)

Hung Huynh 2014-02-12

DSO is discontinued