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

        Show
        Jochen Kraushaar added a comment - See also the discussion in http://www.java.net/forum/topic/glassfish/glassfish/osgi-static-resources-not-found-after-some-days
        Hide
        TangYong added a comment -

        I can understand the feature's importance(jkraushaar's company is using wab feature), so I wish that the feature can be implemented as soon as possible.

        Firstly, one thing must be done: for an user, which configure way is best?

        My current idea is using deploy command property. for example,

        asadmin deploy --type=osgi --properties wabPath=/home/jkraushaar/glassfish/wab/ sample.uas.simplewab.war

        if wabPath property is not set, defaultly, we use java.io.tmpdir.

        Please jkraushaar and sahoo discuss whether ok.

        --Tang

        Show
        TangYong added a comment - I can understand the feature's importance(jkraushaar's company is using wab feature), so I wish that the feature can be implemented as soon as possible. Firstly, one thing must be done: for an user, which configure way is best? My current idea is using deploy command property. for example, asadmin deploy --type=osgi --properties wabPath=/home/jkraushaar/glassfish/wab/ sample.uas.simplewab.war if wabPath property is not set, defaultly, we use java.io.tmpdir. Please jkraushaar and sahoo discuss whether ok. --Tang
        Hide
        Jochen Kraushaar added a comment -

        Thank you for giving this feature such a high priority.

        We are using the Felix console or the Felix file install feature to deploy bundles. We are also using the asadmin deploy command for deploying bundles on our test integration system. It would be nice if the path can be specified in all of these usage scenarios. Perhaps a configuration key in osgi.properties?

        Show
        Jochen Kraushaar added a comment - Thank you for giving this feature such a high priority. We are using the Felix console or the Felix file install feature to deploy bundles. We are also using the asadmin deploy command for deploying bundles on our test integration system. It would be nice if the path can be specified in all of these usage scenarios. Perhaps a configuration key in osgi.properties?
        Hide
        TangYong added a comment -

        OK, thanks your feedback, and if using Felix file install feature, deploy command property is not enough or not meet the scene.

        >Perhaps a configuration key in osgi.properties?
        I also think so, however, I need sahoo's final voting. Please wait his reply.

        Thanks
        --Tang

        Show
        TangYong added a comment - OK, thanks your feedback, and if using Felix file install feature, deploy command property is not enough or not meet the scene. >Perhaps a configuration key in osgi.properties? I also think so, however, I need sahoo's final voting. Please wait his reply. Thanks --Tang
        Hide
        TangYong added a comment -

        Another config way is that while wrapping wab bundle, in manifest.mf, we add a entry or key to config wab exploded path.

        Show
        TangYong added a comment - Another config way is that while wrapping wab bundle, in manifest.mf, we add a entry or key to config wab exploded path.
        Hide
        Jochen Kraushaar added a comment -

        An entry in MANIFEST.MF would also be fine for us. However I prefer the osgi.properties entry, because a developer who reads through the file will find the configuration item (even if it is just documented as comment). If it is configured using the manifest, it is not obvious for developers that there is such an configuration item.

        Show
        Jochen Kraushaar added a comment - An entry in MANIFEST.MF would also be fine for us. However I prefer the osgi.properties entry, because a developer who reads through the file will find the configuration item (even if it is just documented as comment). If it is configured using the manifest, it is not obvious for developers that there is such an configuration item.
        Hide
        TangYong added a comment -

        OK, if sahoo agrees with you and me, I will start to do it.

        Thanks
        --Tang

        Show
        TangYong added a comment - OK, if sahoo agrees with you and me, I will start to do it. Thanks --Tang
        Hide
        Sanjeeb Sahoo added a comment -

        Can't we explode in bundle storage area of the bundle that's expanding instead of introducing a new property? e.g., if osgi-javaee-base is exploding, then it can store the content in its bundle storage area. That way we don't need any property. This is what the TODO in OSGiDeploymentRequest.java says:

        // TODO(Sahoo): Do it in Bundle private storage of the container
        File tmpFile = File.createTempFile("osgiapp", "");

        Sahoo

        Show
        Sanjeeb Sahoo added a comment - Can't we explode in bundle storage area of the bundle that's expanding instead of introducing a new property? e.g., if osgi-javaee-base is exploding, then it can store the content in its bundle storage area. That way we don't need any property. This is what the TODO in OSGiDeploymentRequest.java says: // TODO(Sahoo): Do it in Bundle private storage of the container File tmpFile = File.createTempFile("osgiapp", ""); Sahoo
        Hide
        TangYong added a comment -

        >Can't we explode in bundle storage area of the bundle that's expanding instead of introducing a new property?
        Good suggestion!

        Many OSGi framework impl all uses this way to save private data, and initially I forgot the way .

        Thanks Sahoo.

        Show
        TangYong added a comment - >Can't we explode in bundle storage area of the bundle that's expanding instead of introducing a new property? Good suggestion! Many OSGi framework impl all uses this way to save private data, and initially I forgot the way . Thanks Sahoo.
        Hide
        TangYong added a comment -

        jkraushaar

        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.

        Thanks
        --Tang

        Show
        TangYong added a comment - jkraushaar 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. Thanks --Tang
        Hide
        TangYong added a comment -

        Currently, this feature has been done and am reviewing by sahoo, please wait.

        Show
        TangYong added a comment - Currently, this feature has been done and am reviewing by sahoo, please wait.
        Hide
        TangYong added a comment -

        Currently, the issue is blocked by two issues:

        1 GLASSFISH-19697
        2 GLASSFISH-19696

        Show
        TangYong added a comment - Currently, the issue is blocked by two issues: 1 GLASSFISH-19697 2 GLASSFISH-19696
        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: