glassfish
  1. glassfish
  2. GLASSFISH-17319

touch .reload undeploy an application when exist a lifecycle module

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.1, 3.1.2, 4.0
    • Fix Version/s: 3.1.2_b05, 4.0
    • Component/s: lifecycle_modules
    • Labels:
      None
    • Environment:

      Solaris 10

      Description

      I've installed glassfish 3.1.1

      I've one application and one lifecycle module. When I touch .reload on my application's directory the application doesn't reload and instead this it's undeployed. The log in the server.log is:

      [#|2011-09-19T17:06:09.826+0200|SEVERE|oracle-glassfish3.1.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=19;_ThreadName=Thread-2;|The log message is null.|#]

      If I undeploy the lifecycle module and touch .reload on the applitcation's directory all runs ok. The application is reloaded.

      I've thougth that I've something wrong with my lifecycle module, so I wrote a new module with only write messages to the log but the error continues.

      Does anybody have this issue?

        Activity

        theEdgeU2 created issue -
        Hide
        Hong Zhang added a comment -

        assign to tim to take a look as he is more familiar with the dynamic reload manager

        Show
        Hong Zhang added a comment - assign to tim to take a look as he is more familiar with the dynamic reload manager
        Hong Zhang made changes -
        Field Original Value New Value
        Assignee Hong Zhang [ hzhang_jn ] Tim Quinn [ tjquinn ]
        Hide
        Tim Quinn added a comment -

        Can you share your lifecycle module and your application so we can try to reproduce the problem?

        You can attach them to this issue or, if you prefer, you can e-mail them to me directly at tjquinn
        at java.net

        Did this work for you with earlier releases of GlassFish?

        Thanks.

        Show
        Tim Quinn added a comment - Can you share your lifecycle module and your application so we can try to reproduce the problem? You can attach them to this issue or, if you prefer, you can e-mail them to me directly at tjquinn at java.net Did this work for you with earlier releases of GlassFish? Thanks.
        Hide
        theEdgeU2 added a comment - - edited

        Thanks for your quickly reply.

        I've attached a zip file (test.zip) with:

        • com/test/GlassFishEvents.class and .java -> LifeCycle Module (only write messages to server.log)
        • test.war -> web application. Only one html page (test.html) to check if it's working

        Steps to reproduce the problem:
        1.- asadmin create-domain test; asadmin start-domain test
        2.- Copy GlassFishEvents.class to /var/opt/glassfish/test/classes/com/test directory
        3.- asadmin create-lifecycle-module --classname com.test.GlassFishEvents --loadorder 100 --enabled=true --classpath /var/opt/glassfish/test/classes Test
        4.- asadmin deploy test.war

        5.- http://127.0.0.1:55322/test/test.html -> OK
        6.- touch /var/opt/glassfish/domains/test/applications/test/.reload
        7.- http://127.0.0.1:55322/test/test.html -> Error 404

        8.- asadmin deploy test.war
        9.- asadmin delete-lifecycle-module Test
        10.- http://127.0.0.1:55322/test/test.html -> OK
        11.- touch /var/opt/glassfish/domains/test/applications/test/.reload
        12.- http://127.0.0.1:55322/test/test.html -> OK

        If exist one lifecycle module when I touch .reload of one application the application is undeployed (step 5-7), but if doesn't exists a lifecycle module all runs ok (steps 8-12)

        This works in glassfish 2.1.1 but fails in glassfish 3.1 and 3.1.1.

        Show
        theEdgeU2 added a comment - - edited Thanks for your quickly reply. I've attached a zip file (test.zip) with: com/test/GlassFishEvents.class and .java -> LifeCycle Module (only write messages to server.log) test.war -> web application. Only one html page (test.html) to check if it's working Steps to reproduce the problem: 1.- asadmin create-domain test; asadmin start-domain test 2.- Copy GlassFishEvents.class to /var/opt/glassfish/test/classes/com/test directory 3.- asadmin create-lifecycle-module --classname com.test.GlassFishEvents --loadorder 100 --enabled=true --classpath /var/opt/glassfish/test/classes Test 4.- asadmin deploy test.war 5.- http://127.0.0.1:55322/test/test.html -> OK 6.- touch /var/opt/glassfish/domains/test/applications/test/.reload 7.- http://127.0.0.1:55322/test/test.html -> Error 404 8.- asadmin deploy test.war 9.- asadmin delete-lifecycle-module Test 10.- http://127.0.0.1:55322/test/test.html -> OK 11.- touch /var/opt/glassfish/domains/test/applications/test/.reload 12.- http://127.0.0.1:55322/test/test.html -> OK If exist one lifecycle module when I touch .reload of one application the application is undeployed (step 5-7), but if doesn't exists a lifecycle module all runs ok (steps 8-12) This works in glassfish 2.1.1 but fails in glassfish 3.1 and 3.1.1.
        theEdgeU2 made changes -
        Attachment test.zip [ 47357 ]
        Hide
        Tim Quinn added a comment - - edited

        Thanks very much for the sample and the very complete instructions. I have reproduced the problem.

        As you might imagine, the "reload" feature ultimately invokes the normal deployment logic, since the reload feature essentially redeploys the application. The immediate problem is that we're getting a NullPointerException thrown during the deployment processing. The deployment code is written so that in case of such a failure, it undoes the deployment – it undeploys the app it was in the process of deploying.

        In this case, the test.war app that was deployed before the reload processing started gets undeployed.

        The underlying problem is that, as you might know, GlassFish supports versioned applications. Some of that version-handling logic runs as part of any deployment, even if you are not deploying a versioned app. There's part of the version logic that scans through all applications checking the application's directory. It turns out that life cycle modules are treated (in this respect) as an application, and are therefore included in this scan. Even though life cycle modules do not have "directories" in the sense that "regular" applications do, the version logic is not checking to see if the location information is null before using it...and that triggers the NPE.

        Unfortunately I don't see a good workaround other than waiting for the code fix.

        Show
        Tim Quinn added a comment - - edited Thanks very much for the sample and the very complete instructions. I have reproduced the problem. As you might imagine, the "reload" feature ultimately invokes the normal deployment logic, since the reload feature essentially redeploys the application. The immediate problem is that we're getting a NullPointerException thrown during the deployment processing. The deployment code is written so that in case of such a failure, it undoes the deployment – it undeploys the app it was in the process of deploying. In this case, the test.war app that was deployed before the reload processing started gets undeployed. The underlying problem is that, as you might know, GlassFish supports versioned applications. Some of that version-handling logic runs as part of any deployment, even if you are not deploying a versioned app. There's part of the version logic that scans through all applications checking the application's directory. It turns out that life cycle modules are treated (in this respect) as an application, and are therefore included in this scan. Even though life cycle modules do not have "directories" in the sense that "regular" applications do, the version logic is not checking to see if the location information is null before using it...and that triggers the NPE. Unfortunately I don't see a good workaround other than waiting for the code fix.
        Hide
        theEdgeU2 added a comment -

        Thanks Tim.

        OK. We'll be waiting for the code fix. Until that we'll stay in glassfish 2.1.1.

        Show
        theEdgeU2 added a comment - Thanks Tim. OK. We'll be waiting for the code fix. Until that we'll stay in glassfish 2.1.1.
        Hide
        Tim Quinn added a comment -

        Fix checked in for 3.1.2. Same to follow shortly for the trunk.

        Project: glassfish
        Repository: svn
        Revision: 49945
        Author: tjquinn
        Date: 2011-09-26 20:12:36 UTC
        Link:

        Log Message:
        ------------
        Fix for 17319

        Life cycle modules appear in the configuration as applications (as do more usual apps) but they do not have locations - directories - associated with them. Some of the versioning code assumed that all apps have a location.

        This change fixes such a problem exposed when an app and a life cycle module were both present and the user dynamically reloaded the app (using "touch .reload").

        Revisions:
        ----------
        49945

        Modified Paths:
        ---------------
        branches/3.1.2/deployment/common/src/main/java/org/glassfish/deployment/versioning/VersioningService.java

        Show
        Tim Quinn added a comment - Fix checked in for 3.1.2. Same to follow shortly for the trunk. Project: glassfish Repository: svn Revision: 49945 Author: tjquinn Date: 2011-09-26 20:12:36 UTC Link: Log Message: ------------ Fix for 17319 Life cycle modules appear in the configuration as applications (as do more usual apps) but they do not have locations - directories - associated with them. Some of the versioning code assumed that all apps have a location. This change fixes such a problem exposed when an app and a life cycle module were both present and the user dynamically reloaded the app (using "touch .reload"). Revisions: ---------- 49945 Modified Paths: --------------- branches/3.1.2/deployment/common/src/main/java/org/glassfish/deployment/versioning/VersioningService.java
        Tim Quinn made changes -
        Fix Version/s 3.1.2_b05 [ 15105 ]
        Affects Version/s 3.1.2 [ 15100 ]
        Affects Version/s 4.0 [ 10970 ]
        Hide
        Tim Quinn added a comment -

        Fix for the trunk was checked in long ago (Oct. 4 2011) - I'm finally getting around to updating this issue.

        Project: glassfish
        Repository: svn
        Revision: 50094
        Author: tjquinn
        Date: 2011-10-04 14:06:31 UTC
        Link:

        Log Message:
        ------------
        Fix for 17319

        Life cycle modules appear in the configuration as applications (as do more usual apps) but they do not have locations - directories - associated with them. Some of the versioning code assumed that all apps have a location.

        This change fixes such a problem exposed when an app and a life cycle module were both present and the user dynamically reloaded the app (using "touch .reload").

        Revisions:
        ----------
        50094

        Modified Paths:
        ---------------
        trunk/main/nucleus/deployment/common/src/main/java/org/glassfish/deployment/versioning/VersioningService.java

        Show
        Tim Quinn added a comment - Fix for the trunk was checked in long ago (Oct. 4 2011) - I'm finally getting around to updating this issue. Project: glassfish Repository: svn Revision: 50094 Author: tjquinn Date: 2011-10-04 14:06:31 UTC Link: Log Message: ------------ Fix for 17319 Life cycle modules appear in the configuration as applications (as do more usual apps) but they do not have locations - directories - associated with them. Some of the versioning code assumed that all apps have a location. This change fixes such a problem exposed when an app and a life cycle module were both present and the user dynamically reloaded the app (using "touch .reload"). Revisions: ---------- 50094 Modified Paths: --------------- trunk/main/nucleus/deployment/common/src/main/java/org/glassfish/deployment/versioning/VersioningService.java
        Tim Quinn made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 4.0 [ 10970 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Tim Quinn
            Reporter:
            theEdgeU2
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: