glassfish
  1. glassfish
  2. GLASSFISH-19688

[osgi/javaee-base] Don't explode OSGi applications in tmpdir

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.2
    • Fix Version/s: 4.0_b82_EE7MS7
    • Component/s: OSGi-JavaEE
    • Labels:
      None

      Description

      Currently OSGi web application bundles are exploded to /tmp/osgiapp* by default. On some Linux distributions files in the /tmp directory are cleared after x days. This includes the files exploded by GlassFish. As a consequence the web application will no longer work after x days.

      The only solution to this problem is (except excluding the explode directories from automatic clean up) to specify another temporary directory by setting java.io.tmpdir.

      It would be nice to configure just the explode directories of the OSGi bundles.

        Activity

        Hide
        Jochen Kraushaar added a comment -

        > I need to say that wab expanded path is used by framework internally, so for an user, it should not be configurable by the user, this is why Sahoo suggested using bundle private storage way.

        This solution is ok for us.

        Show
        Jochen Kraushaar added a comment - > I need to say that wab expanded path is used by framework internally, so for an user, it should not be configurable by the user, this is why Sahoo suggested using bundle private storage way. This solution is ok for us.
        Hide
        Sanjeeb Sahoo added a comment -

        I have updated the synopsys and type of the issue to reflect how we are going to address this issue. We acknowledge exploding in tmpdir can lead to other issues, so we will explode them in bundle private storage area. We will not provide any option to make it configurable as exposing more options mean more documentation and less user friendliness.

        Show
        Sanjeeb Sahoo added a comment - I have updated the synopsys and type of the issue to reflect how we are going to address this issue. We acknowledge exploding in tmpdir can lead to other issues, so we will explode them in bundle private storage area. We will not provide any option to make it configurable as exposing more options mean more documentation and less user friendliness.
        Hide
        TangYong added a comment -

        Fixed.
        Revision: 60755

        Show
        TangYong added a comment - Fixed. Revision: 60755
        Hide
        Sanjeeb Sahoo added a comment -

        The previous checkin had a minor issue as described below. So, I committed revision #60803 of src/main/java/org/glassfish/osgijavaeebase/OSGiDeploymentRequest.java. After the initial fix, we started getting NullPointerException during server restart:

        [2013-03-25T22:22:20.980+0530] [glassfish 4.0] [WARNING] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-15-thread-1] [timeMillis: 1364230340980] [levelValue: 900] [[
        Failed to deploy bundle org.glassfish.fighterfish.sample.uas.simplewab [293]
        org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.fighterfish.sample.uas.simplewab [293] failed because of following reason: Failed while deploying bundle org.glassfish.fighterfish.sample.uas.simplewab [293] : java.lang.NullPointerException
        at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:127)
        at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
        at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
        at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
        at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
        at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)
        Caused by: java.lang.NullPointerException
        at java.io.File.<init>(File.java:389)
        at org.glassfish.deployment.common.DeploymentContextImpl.getSourceDir(DeploymentContextImpl.java:305)
        at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.<init>(OSGiWebDeploymentContext.java:213)
        at org.glassfish.osgiweb.OSGiWebDeploymentContext.setupClassLoader(OSGiWebDeploymentContext.java:124)
        at org.glassfish.osgijavaeebase.OSGiDeploymentContext.<init>(OSGiDeploymentContext.java:77)
        at org.glassfish.osgiweb.OSGiWebDeploymentContext.<init>(OSGiWebDeploymentContext.java:91)
        at org.glassfish.osgiweb.OSGiWebDeploymentRequest.getDeploymentContextImpl(OSGiWebDeploymentRequest.java:96)
        at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.prepare(OSGiDeploymentRequest.java:158)
        at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:119)
        at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
        ... 10 more
        ]]

        This NPE happens when there is an exploded directory already present when server is started.
        An exploded directory can exist for various reasons including the scenario described in GLASSFISH-19697.
        In such a case, our new code was not setting archive object to represent the exploded directory.
        Since archive is by default set to WAB whose getSource() returns null, we get NPE.

        The fix made here is to ensure that we clean up existing directory. For various reasons mentioned in code,
        we can't safely reuse an existing directory, so we delete it and go through the same code as if it's first time
        deployment.

        Show
        Sanjeeb Sahoo added a comment - The previous checkin had a minor issue as described below. So, I committed revision #60803 of src/main/java/org/glassfish/osgijavaeebase/OSGiDeploymentRequest.java. After the initial fix, we started getting NullPointerException during server restart: [2013-03-25T22:22:20.980+0530] [glassfish 4.0] [WARNING] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-15-thread-1] [timeMillis: 1364230340980] [levelValue: 900] [[ Failed to deploy bundle org.glassfish.fighterfish.sample.uas.simplewab [293] org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.fighterfish.sample.uas.simplewab [293] failed because of following reason: Failed while deploying bundle org.glassfish.fighterfish.sample.uas.simplewab [293] : java.lang.NullPointerException at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:127) at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154) at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109) at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61) at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153) at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.NullPointerException at java.io.File.<init>(File.java:389) at org.glassfish.deployment.common.DeploymentContextImpl.getSourceDir(DeploymentContextImpl.java:305) at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.<init>(OSGiWebDeploymentContext.java:213) at org.glassfish.osgiweb.OSGiWebDeploymentContext.setupClassLoader(OSGiWebDeploymentContext.java:124) at org.glassfish.osgijavaeebase.OSGiDeploymentContext.<init>(OSGiDeploymentContext.java:77) at org.glassfish.osgiweb.OSGiWebDeploymentContext.<init>(OSGiWebDeploymentContext.java:91) at org.glassfish.osgiweb.OSGiWebDeploymentRequest.getDeploymentContextImpl(OSGiWebDeploymentRequest.java:96) at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.prepare(OSGiDeploymentRequest.java:158) at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:119) at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123) ... 10 more ]] This NPE happens when there is an exploded directory already present when server is started. An exploded directory can exist for various reasons including the scenario described in GLASSFISH-19697 . In such a case, our new code was not setting archive object to represent the exploded directory. Since archive is by default set to WAB whose getSource() returns null, we get NPE. The fix made here is to ensure that we clean up existing directory. For various reasons mentioned in code, we can't safely reuse an existing directory, so we delete it and go through the same code as if it's first time deployment.
        Hide
        Sanjeeb Sahoo added a comment -

        Integrated osgi-javaee-base:1.0.6 with glassfish trunk in svn #60905, so marking the bug as resolved.

        Show
        Sanjeeb Sahoo added a comment - Integrated osgi-javaee-base:1.0.6 with glassfish trunk in svn #60905, so marking the bug as resolved.

          People

          • Assignee:
            TangYong
            Reporter:
            Jochen Kraushaar
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: