Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: 1 Critical 1 Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0.0
    • Component/s: DSO:L1
    • Labels:
      None
    • Fix In Branch:
      trunk
    • Fixed In Revision:
      11883

      Issue Links

        Activity

        Hide
        Walter Harley added a comment - - edited

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

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

        <application>
        <dso>
        <app-groups>
        <app-group name="ab">
        <web-application>contexta</web-application>
        <web-application>contextb</web-application>
        </app-group>
        </app-groups>
        </dso>
        </application>

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

        <application>
        <dso>
        <app-groups>
        <app-group name="webAndPojo">
        <web-application>contexta</web-application>
        <named-classloader>Standard.system</named-classloader>
        </app-group>
        </app-groups>
        </dso>
        </application>

        To find classloader names, enable named-classloader debugging:

        <clients><dso><debugging><runtime-logging>
        <named-loader-debug>true</named-loader-debug>
        </runtime-logging></debugging></dso></clients>

        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.

        Show
        Walter Harley added a comment - - edited Fixed in trunk, mostly with change 11812, some additional support in 11883. To share classes between web apps, use config similar to the following: <application> <dso> <app-groups> <app-group name="ab"> <web-application>contexta</web-application> <web-application>contextb</web-application> </app-group> </app-groups> </dso> </application> In addition to web apps, any registered loader can be shared by naming it explicitly; for instance, the standard system loader can be shared: <application> <dso> <app-groups> <app-group name="webAndPojo"> <web-application>contexta</web-application> <named-classloader>Standard.system</named-classloader> </app-group> </app-groups> </dso> </application> To find classloader names, enable named-classloader debugging: <clients><dso><debugging><runtime-logging> <named-loader-debug>true</named-loader-debug> </runtime-logging></debugging></dso></clients> 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.
        Hide
        Walter Harley added a comment -

        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.

        Show
        Walter Harley added a comment - 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.
        Hide
        Tim Eck added a comment -

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

        Show
        Tim Eck added a comment - This is done with the exception of Webshere--CE. I opened another item (DEV-2485) to cover that remaining work
        Hide
        nadeem ghani added a comment -

        verified with trunk versions of exam and examonitor and TC

        Show
        nadeem ghani added a comment - verified with trunk versions of exam and examonitor and TC
        Hide
        Walter Harley added a comment -

        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.

        Show
        Walter Harley added a comment - 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.

          People

          • Assignee:
            Tim Eck
            Reporter:
            Steve Harris
          • Votes:
            9 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: