• New Feature
  • Status: Closed
  • 3 Minor
  • Resolution: Fixed
  • DSO:L1,DSO:L2
  • hhuynh
  • Reporter: ekulesho
  • February 06, 2007
  • 0
  • Watchers: 2
  • April 07, 2008
  • March 19, 2008

Description

While working on CDV-81, I caught a DSO limitation that does not allow to use the same root between different web applications (or between web app and a standalone app). ClientObjectManager can’t find classes for in that case. It is deleagating to the StandardClassProvider and mapping to differently named classloaders does not work for this.

See exception stack traces in CDV-81.

Comments

Fiona OShea 2007-02-06

Assigning to PM to review

Fiona OShea 2007-09-26

If this is covered by the RMP work great. If not then it does not need to be done in Pacheco.

Fiona OShea 2007-12-04

Pacheco PRD Priority 96

Fiona OShea 2008-03-14

Is this done? If so please resolve and add the svn revision number

Abhishek Singh 2008-03-19

Fixed in 7175 and addressed code review in revision 7309

This fix addresses sharing roots with a standalone java app and a (single) webapp. Users can use “-Dcom.tc.loader.system.name=Any.class.loader.name” while starting their standalone java app to give a name to the standard class loader so that shared roots can have the same loader name between the java app and the webapp.

This removes the need of workaround to use a separate launcher for java apps where class loader names are changed.

Eugene Kuleshov 2008-04-03

Guys, I don’t think this such fix is really sufficient. Sharing between standalone app and web app is not a big issue and we did have workaround. However, sharing classes between two web apps (even on the same server) is not possible at all and it is much more critical and it been requested several times on the forums.

spindle spindle 2008-04-04

as explanined in the post (http://forums.terracotta.org/forums/posts/list/907.page),

how can two different web applications(deployed to tomcat in example application in the post) share the same application context and same bean from same loaded library(jar file).

Attached from the post ,

with terracotta-2.6-nightly-rev7889 and spring 2.0.6) the parameter Dcom.tc.loader.system.name=myClusteredService and also the configuration parameter myClusteredService is used :

  1. if both applications are run from eclipse as a standalone application appName(com.tcspring.ApplicationContextEventProtocol.appName) becomes myClusteredService and everything goes fine,and common bean(beanTobeShared in example) is shared btw two applications

  2. if both applications are run from tomcat,there is no error(before nightly-rev7889 revison i could not execute if I gave common root-name for the two applications),but (com.tcspring.ApplicationContextEventProtocol.appName) becomes application names(not myClusteredService),because of this there are two different bean instead of one common shared bean((beanTobeShared in example)

How can both applications use the parameter com.tc.loader.system.name=myClusteredService and get the same appName for both of the applications? (so common bean can be shared by this way)

Taylor Gautier 2008-04-07

This issue only resolves sharing between a web app and a standalone app. Other kinds of classloader problems (including web app A sharing with web app B) are still outstanding.

See CDV-272 for remaining classloader issues (linked)