Strange loop when hot deploying an exploded ear

[wdrai]

I'm using JBoss Tools to deploy an exploded ear on a JBAS5 CR1 server in default configuration.
When JBT rebuilds the archive, there is a redeployment of the entire application every 5 seconds.

I've tracked the problem with a debugger, and it seems that a redeployment is triggered in MetaDataAwareProfile.java for each file present in any META-INF/WEB-INF directory of the ear. In my case, that makes almost 20*5 seconds for each redeployment...

[jaikiran]

"wdrai" wrote:
I'm using JBoss Tools to deploy an exploded ear on a JBAS5 CR1 server in default configuration.
When JBT rebuilds the archive, there is a redeployment of the entire application every 5 seconds.

Looks like the hot deployment scanner (which is configured to run every 5 seconds) is considering the application as "modified".


I don't exactly know how JBoss Tools works. Does it deploy the application to the "deploy" folder or does it use the MBean to deploy the application? If JBoss Tools copies to deploy folder, are you sure that when you deploy the application through the JBoss Tools, the copy operation (to the deploy folder) is complete, before the hot deployment scanner is triggered?

[alesj]

JBoss Tools should eventually use Managed API:
- https://jira.jboss.org/jira/browse/JBAS-5823

I'm just about to port deployers tests to use it.
Since it's the ProfileService/DeploymentManager that
knows how to suspend hot deploy, etc.

[wdrai]

It seems that JBoss Tools just does a simple file copy, so a deployment could eventually be triggered before it has finished to copy the whole ear, but this is not the case here.

In fact, it seems that when many files are changed at the same time, the deployment does not update correctly the timestamp cache for the other files in the deployment unit.
i.e. web.xml and ejb-jar.xml are touched at the same time
=> there is one redeploy for web.xml
=> there is a second redeploy for ejb-jar.xml because its timestamp has not been updated in the cache by the first redeploy

I'm not completely sure, but this looks like a bug in the deployer.