Redeployment on JBoss 5

[iradix]

I've recently started using the latest CR release of JBoss 5, and I've noticed that my WAR file is often being reloaded when the web.xml file has not changed. I'm assuming that this is a result of the deployment changes in 5.0, which I believe are represented in the microcontainer. If so, can someone clarify for me a) what files are checked to determine if a WAR needs to be redeployed by default and b) if there is a way to reconfigure this behaviour? My guess is that all the files in the META-INF folder are being watched, as the only file that gets updated regularly is Maven's /META-INF/pom.xml descriptor, and I'd really like to find a way to exclude it from consideration.

Thanks.

[iradix]

Just to clarify, after watching a bit more closely, it seems like it is a facelts template file (default.xhtml) located in WEB-INF/templates that changes and triggers a reload. There are non-configuration files that I tend to keep within WEB-INF just because they are not directly accessible pages and I'd rather not have an update of them cause a redeploy. Is there any way to restrict it to only web.xml?

[jaikiran]

As far as i know, its only the top level deployment descriptors that are watched for redeployment. So for a war file its just the WEB-INF/web.xml which is watched for changes.

[jaikiran]

"jaikiran" wrote:
As far as i know, its only the top level deployment descriptors that are watched for redeployment.

Just to be more clear - If you have nested deployments then the top level deployment descriptor of each deployment is watched. See this for details http://www.jboss.com/index.html?module=bb&op=viewtopic&t=138457

For example: Your application is an EAR file containing a WAR file, then the META-INF/application.xml of the EAR and the WEB-INF/web.xml of the war are both watched for changes.

[alesj]

We check every metadata file in deployment + all sub-deployments:
- http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/system/server/profile/basic/MetaDataAwareProfile.java
- https://jira.jboss.org/jira/browse/JBAS-4545

I guess I can add some filter to the check.

[iradix]

Ales,

So if I understand this correctly getMetaDataLocations for a WAR deployment returns the WEB-INF folder, and the isModified method will check every child within that folder? That does seem to be somewhat undesirable. I know that there are a fair number of web frameworks that suggest keeping page (JSP, etc) files within WEB-INF (Spring comes to mind). If any change to those files causes a redeployment it's going to be an issue for people during development.

[alesj]

"iradix" wrote:

So if I understand this correctly getMetaDataLocations for a WAR deployment returns the WEB-INF folder, and the isModified method will check every child within that folder?

Yes.

"iradix" wrote:

That does seem to be somewhat undesirable. I know that there are a fair number of web frameworks that suggest keeping page (JSP, etc) files within WEB-INF (Spring comes to mind). If any change to those files causes a redeployment it's going to be an issue for people during development.

I see.
This was an initial fix to the metadata update problem / legacy behavior.
So, filter definitely makes sense:
- https://jira.jboss.org/jira/browse/JBAS-5998

[iradix]

Cool. Off the top of my head, defaulting the filter to *.xml might be a good compromise. It seems to me like that would encompass the JBoss config files, standard JEE config files, and also web framework files that do necessitate a restart (Seam's components.xml for instance) while excluding *.jsp, *.xhtml and other non-config files deployed to the WEB-INF folder.

[alesj]

I've committed the change to the JBossAS trunk.
By default it now includes .xml files only.
But this can be changed in profile.xml configuration file.

[iradix]

Thank you Ales.