glassfish
  1. glassfish
  2. GLASSFISH-5380

Make standalone RA available only to those apps that explicitly use it

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: V3
    • Fix Version/s: V3
    • Component/s: jca
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      5,380

      Description

      As per the new proposal made in JCA 1.6 and Java EE 6 platform spec, Java EE
      implementations are allowed to limit visibility of a standalone RAR to only
      those applications that depend on that RAR. See section 19.2.0.4 and 19.3 of JCA
      1.6 EDR. The feature implementation involves the following:

      1. an API from deployment module that can be used to find standalone RARs used
      by an application.

      2. Create ConnectorClassLoader per application with appropriate list of connectors.

      3. Change RAR undeployment code to throw exception when a RAR is undeployed
      while it is still being referred by some application. Decide whether --force is
      needed for undeploy command. Same is true for redeployment.

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        Forgot to mention one more item. We need to come up with an entry in sun-*.xml
        to indicate that a particular applications needs access to all deployed
        standalone RARs, as the specification requires us to support this mode as well.

        Show
        Sanjeeb Sahoo added a comment - Forgot to mention one more item. We need to come up with an entry in sun-*.xml to indicate that a particular applications needs access to all deployed standalone RARs, as the specification requires us to support this mode as well.
        Hide
        Sanjeeb Sahoo added a comment -

        If we have to address this RFE, we need to make another change in the server,
        which is like this:
        today classloader for each application library delegates to the singleton
        connector classloader. Since we will have multiple connector class loaders (zero
        or one per app) and the list varies as applications get deployed/undeployed and
        application library class loader can only have one parent, application library
        class loader can't delegate to any connector class loader. Instead, it will
        delegate to common class loader. I don't see this causing any incompatibility
        because libraries should not depend on some standalone RARs.

        Show
        Sanjeeb Sahoo added a comment - If we have to address this RFE, we need to make another change in the server, which is like this: today classloader for each application library delegates to the singleton connector classloader. Since we will have multiple connector class loaders (zero or one per app) and the list varies as applications get deployed/undeployed and application library class loader can only have one parent, application library class loader can't delegate to any connector class loader. Instead, it will delegate to common class loader. I don't see this causing any incompatibility because libraries should not depend on some standalone RARs.
        Hide
        Hong Zhang added a comment -

        I think we have already addressed this spec requirement in v3, I will reassign to Jagadish for him to confirm and follow up.

        Show
        Hong Zhang added a comment - I think we have already addressed this spec requirement in v3, I will reassign to Jagadish for him to confirm and follow up.
        Hide
        Jagadish added a comment -

        Items (1) and (2) stated in the initial bug description are implemented in connector container during v3.

        Item (3) is not done ie., failing undeployment of a RAR if its referred by an application.
        This has been the case since 8.x ie., even when an application is referring the RAR and the RAR is undeployed, undeployment will succeed and an INFO message stating that applications need to be re-deployed/re-enabled for changes to take effect.

        Show
        Jagadish added a comment - Items (1) and (2) stated in the initial bug description are implemented in connector container during v3. Item (3) is not done ie., failing undeployment of a RAR if its referred by an application. This has been the case since 8.x ie., even when an application is referring the RAR and the RAR is undeployed, undeployment will succeed and an INFO message stating that applications need to be re-deployed/re-enabled for changes to take effect.

          People

          • Assignee:
            Jagadish
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: