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): 2.4.1 How reproducible: 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 Actual results: Date on the war is Dec 31 1969 Expected results: Expect the Date/Time to be the Date/Time of deployment. Additional info:
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. Next Browse to and Upload WAR Set Deploy Farmed Set Timeout to 30 Seconds Finish 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: org.jboss.deployers.spi.management.deploy.DeploymentManager.distribute 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.