Should Touching / changing timestamp of exploded folder rede

[rob.stryker]

Currently touching descriptor files is the best way to redeploy an exploded deployment. Some deployment types do not require any descriptors, so there's no clear way to redeploy that deployment without removing it and adding it again. The workaround of course is to add a stub descriptor and touch that.

Which brings to mind the following question: Does anyone think the deployment scanner should not only check for descriptor timestamp changes, but also check the module's folder's timestamp as well? For example, if the folder Blah.ear has a changed timestamp, is allowing the module to redeploy a good idea?

I vote yes but I'm curious if there's some big reason why this isn't done already or if it's been tried before.

[alesj]

This can easily be done:
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-vfs-spi/src/main/java/org/jboss/deployers/vfs/spi/structure/modified/AbstractStructureModificationChecker.java
See the usage of hasRootBeenModified(VirtualFile root).

Although I wrote this stuff I don't know why we didn't include this in the first place.
I guess there was a reason, which looks like it slipped my mind. :-(

But instead of this touch hack, we could provide a different StructureModificationChecker,
for those who rely on .class changes.
It would check classes as well as metadata locations.

[dimitris]

I guess you didn't do it because we didn't support this before.

Conceptually, it makes sense and I think Max asked for this before.

How do you 'touch' a directory on windows? :-)

[jaikiran]

The earlier versions indirectly supported this kind of the redeployments where you could rename the directory to something like .bak and name it back to the original name. This would trigger a undeployment and then a deployment.

[rob.stryker]

For the record, the reason this issue even came up was because some of our tools were able to delete and re-deploy a new version of the app but do so so quickly that the scanner didn't notice the change.

Since there were no descriptors in the deployment the scanner had no way to tell this was a "new" deployment and not the same old one it was used to.

As an example of this, start up a JBoss 5.1 server and execute the following:

mkdir test.war
21:41:08,316 INFO [TomcatDeployment] deploy, ctxPath=/test
21:41:08,343 WARNING [config] Unable to process deployment descriptor for context '/test'
21:41:08,344 INFO [config] Initializing Mojarra (1.2_12-b01-FCS) for context '/test'

rm -rf test.war && mkdir test.war
(NOTHING HAPPENS)

rm -rf test.war
21:42:05,379 INFO [TomcatDeployment] undeploy, ctxPath=/test

So clearly we can see the issue I believe ;) Question is, is there a JIRA for this yet? Should I make one? When will this be supported?

Thanks ;)

[rob.stryker]

added a jira link but not sure if it's filed in the right place.

https://jira.jboss.org/jira/browse/JBMICROCONT-447

[alesj]

added a jira link but not sure if it's filed in the right place.

https://jira.jboss.org/jira/browse/JBMICROCONT-447

It is not; read our MC home page on how MC JIRAs are used. ;-)
I'll move the item this time, but for the next please ask me before issuing one.

[maxandersen]

"alesj" wrote:

But instead of this touch hack, we could provide a different StructureModificationChecker,
for those who rely on .class changes.
It would check classes as well as metadata locations.

I don't see any usecase for automatic restarting deployment on class changes. That would trigger it too often.

Of course unless ejb3 and others have implemented incrememently deployment updates recently ;)

[jaikiran]

In this specific usecase (which i think is probably a rare one), i guess all we should do is just check the last modified timestamp of the root of the deployment. Changes to .class files (or any other files) within the deployment will not change the timestamp of the root folder, so we will be safe.

As for how the last modified timestamp of the root directory is changed - it would probably be irrelevant. It would be upto the user to do whatever is necessary to change that timestamp. We just provide a feature which picks up that change.