glassfish
  1. glassfish
  2. GLASSFISH-5474

Allow for webapp deployment/initialization priority

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: V3
    • Fix Version/s: not determined
    • Component/s: deployment
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      5,474

      Description

      Sometimes webapps expose services that are consumed by other webapps running on
      the same webcontainer. In such a situation, the developer needs the webcontainer
      to deploy/initialize applications in a particular order.

      At the minimum users should be able to define a top level application like in
      Tomcat's ROOT webapp.
      Adding this feature will bring feature parity with Tomcat for Glassfish V3

      The user should be able to set the initialization priority at deployment time
      either using asadmin or using an entry in the sun-web.xml

        Activity

        Hide
        uppalapati added a comment -

        Increasing the priority since it is needed for Liferay community builds on
        Glassfish V3

        Show
        uppalapati added a comment - Increasing the priority since it is needed for Liferay community builds on Glassfish V3
        Hide
        jluehe added a comment -

        Can you explain a little more?

        Prior to a server restart, webapps are initialized in the order in which they
        are deployed. The web container is not involved in the decision about which
        webapps are deployed when. That is the administrator's decision.

        Are you talking about the order in which webapps are loaded/initialized
        following a server restart? Could that not be the same order in which they were
        deployed originally?

        Show
        jluehe added a comment - Can you explain a little more? Prior to a server restart, webapps are initialized in the order in which they are deployed. The web container is not involved in the decision about which webapps are deployed when. That is the administrator's decision. Are you talking about the order in which webapps are loaded/initialized following a server restart? Could that not be the same order in which they were deployed originally?
        Hide
        uppalapati added a comment -

        We place the portal war file and all the portlet war files in the GF domain auto
        deploy dir. The portlet war files need to be deployed and initialized after the
        portal war is done.

        Right now auto deploy is using its own sort mechanism to decide the order in
        which the webapps are deployed.

        Tomcat has the concept of ROOT context webapp and it initializes this app before
        any of the other webapps. So services defined in this app are available to other
        webapps when they are initializing.

        Show
        uppalapati added a comment - We place the portal war file and all the portlet war files in the GF domain auto deploy dir. The portlet war files need to be deployed and initialized after the portal war is done. Right now auto deploy is using its own sort mechanism to decide the order in which the webapps are deployed. Tomcat has the concept of ROOT context webapp and it initializes this app before any of the other webapps. So services defined in this app are available to other webapps when they are initializing.
        Hide
        jluehe added a comment -

        Thanks for clarifying! So that would make it a deployment issue, since the web
        container is not involved in the decision in which order autodeployment occurs.

        Show
        jluehe added a comment - Thanks for clarifying! So that would make it a deployment issue, since the web container is not involved in the decision in which order autodeployment occurs.
        Hide
        Hong Zhang added a comment -

        Can you point us to the relevant Tomcat doc for this feature?

        I guess there are two parts to this:
        1. The web applications need to be deployed in a certain order.
        2. The web applications need to be loaded in a certain order (after server is
        restarted).

        Show
        Hong Zhang added a comment - Can you point us to the relevant Tomcat doc for this feature? I guess there are two parts to this: 1. The web applications need to be deployed in a certain order. 2. The web applications need to be loaded in a certain order (after server is restarted).
        Hide
        km added a comment -

        I don't think we should redefine how auto-deployment works. The algorithm of
        auto-deployment is simple and effective. You place an archive in that folder and
        it gets deployed when the auto-deployment thread "sees" it. Applying some kind
        of dependency logic there is going to make it complex.

        Why can't you deploy two applications in the sequence you desire by using
        asadmin deploy command?

        Also, is this a deploy-time dependency or runtime dependency? i.e. do you want
        deployment of these applications to occur in a sequence you want or their
        loading in the container? If it is latter, auto-deployment alone is not going to
        help for after deployment, if you restart the server, the loading of
        applications is (generally speaking) going to happen in the order of their
        appearance in the domain.xml.

        Show
        km added a comment - I don't think we should redefine how auto-deployment works. The algorithm of auto-deployment is simple and effective. You place an archive in that folder and it gets deployed when the auto-deployment thread "sees" it. Applying some kind of dependency logic there is going to make it complex. Why can't you deploy two applications in the sequence you desire by using asadmin deploy command? Also, is this a deploy-time dependency or runtime dependency? i.e. do you want deployment of these applications to occur in a sequence you want or their loading in the container? If it is latter, auto-deployment alone is not going to help for after deployment, if you restart the server, the loading of applications is (generally speaking) going to happen in the order of their appearance in the domain.xml.
        Hide
        uppalapati added a comment -

        Any application that is deployed in the ROOT context "/" on Tomcat is
        initialized before any other application deployed before or after the
        application in the ROOT context was deployed.

        I understand the need to keep the design and impl simple. However the usecase
        above needs to be solved by Glassfish. With that in mind can we just do the
        following:

        Modify Glassfish to deploy and initialize any webap that is targeted for the "/"
        context ahead of the rest of the apps?

        Show
        uppalapati added a comment - Any application that is deployed in the ROOT context "/" on Tomcat is initialized before any other application deployed before or after the application in the ROOT context was deployed. I understand the need to keep the design and impl simple. However the usecase above needs to be solved by Glassfish. With that in mind can we just do the following: Modify Glassfish to deploy and initialize any webap that is targeted for the "/" context ahead of the rest of the apps?
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

          People

          • Assignee:
            Hong Zhang
            Reporter:
            uppalapati
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: