Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: 3 Minor 3 Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.6-stable0
    • Component/s: DSO:L1, DSO:L2
    • Labels:
      None
    • Fix In Branch:
      trunk
    • Fixed In Revision:
      7175 and 7309 (code review fix)

      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.

        Issue Links

          Activity

          Hide
          Fiona OShea added a comment -

          Assigning to PM to review

          Show
          Fiona OShea added a comment - Assigning to PM to review
          Hide
          Abhishek Singh added a comment -

          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.

          Show
          Abhishek Singh added a comment - 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.
          Hide
          spindle spindle added a comment -

          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 <root-name>myClusteredService </root-name> 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)

          Show
          spindle spindle added a comment - 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 <root-name>myClusteredService </root-name> 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)
          Hide
          Taylor Gautier added a comment - - edited

          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)

          Show
          Taylor Gautier added a comment - - edited 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)

            People

            • Assignee:
              Hung Huynh
              Reporter:
              Eugene Kuleshov
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: