Red Hat Bugzilla – Bug 708005
When deploying a war with Farmed = yes, date is set to Dec 31 1969 on the filesystem
Last modified: 2014-10-03 16:29:15 EDT
Description of problem:
When deploying a war file via JON and choosing Deploy Farmed= yes, the file is written to the filesystem with the date of Dec 31 1969
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create two profiles from all (no1 and no2)
2. Start no1
3. In JON, deploy HelloWorld.war and chose the 'Deploy Farmed - Yes' in 'Deployment Options'.
4. After deployment look at the filesystem, #JBOSS_HOME/server/no1/farm and the date on the deployed war:
-rw-rw-r--. 1 jboss jboss 3249 Dec 31 1969 HelloWorld.war
Date on the war is Dec 31 1969
Expect the Date/Time to be the Date/Time of deployment.
In JON 3.0 Beta1 here is how you reproduce...
Start up EAP 5.1
Start up RHQ and the local agent
Import the EAP instance
Go to the Inventory tree for the EAP instance.
Below the JBossAS Servers folder click on the instance (it should be something like "localhost:1099 n01"
At the bottom of the Windows notice the "Create Child" button.
Select Create Child, Web Application
Set Package Version to 1.0, or some such.
Browse to and Upload WAR
Set Deploy Farmed
Set Timeout to 30 Seconds
You will see something like this on the file system:
-rw-r--r-- 1 rbuck rbuck 1189 1969-12-31 19:00 helloworld.war
This only occurs in Java in one case, `new Date(0)`; in JON there is only one place where this happens, and that in a test. Therefore, this must be a bug in JBoss itself, which makes sense.
I looked on Google, and there are lots of hits on JBoss regarding this, but no open bug that I can find.
When I stepped through the code, I did see the WAR file dropped into the tmp directory by the agent and the timestamp was right:
-rw-r--r-- 1 auser auser 1189 2011-11-08 15:14 /home/auser/dev/servers/jboss-eap/5.1.0/jboss-as/server/n01/tmp/jopr-jbossas5-deploy-content7876833990792830526.tmp/helloworld.war
Then JBoss got a hold of it and messed up somehow. The place where things go terribly wrong:
Summary: Push this over to the JBoss folks; this doesn't look good.
Could you please provide if this is not a bug, is there any work around for it.