[GLASSFISH-19688] [osgi/javaee-base] Don't explode OSGi applications in tmpdir Created: 18/Feb/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Resolved
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b82_EE7MS7

Type: Bug Priority: Major
Reporter: Jochen Kraushaar Assignee: TangYong
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


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.

Comment by Jochen Kraushaar [ 18/Feb/13 ]

See also the discussion in http://www.java.net/forum/topic/glassfish/glassfish/osgi-static-resources-not-found-after-some-days

Comment by TangYong [ 18/Feb/13 ]

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.


Comment by Jochen Kraushaar [ 18/Feb/13 ]

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?

Comment by TangYong [ 18/Feb/13 ]

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.


Comment by TangYong [ 18/Feb/13 ]

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

Comment by Jochen Kraushaar [ 18/Feb/13 ]

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.

Comment by TangYong [ 19/Feb/13 ]

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


Comment by Sanjeeb Sahoo [ 20/Feb/13 ]

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", "");


Comment by TangYong [ 20/Feb/13 ]

>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.

Comment by TangYong [ 20/Feb/13 ]


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.


Comment by TangYong [ 20/Feb/13 ]

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

Comment by TangYong [ 20/Feb/13 ]

Currently, the issue is blocked by two issues:


Comment by Jochen Kraushaar [ 25/Feb/13 ]

> 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.

Comment by Sanjeeb Sahoo [ 25/Mar/13 ]

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.

Comment by TangYong [ 25/Mar/13 ]

Revision: 60755

Comment by Sanjeeb Sahoo [ 26/Mar/13 ]

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

Comment by Sanjeeb Sahoo [ 27/Mar/13 ]

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

Generated at Fri Oct 21 15:38:05 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.