Background: http://lists.jboss.org/pipermail/jboss-development/2009-June/014478.html and other threads where AS-5 re-deployments have been discussed As discussed in the mailing list, unlike AS-4.x, in AS-5, *by default* we watch for all xml files in a metadata location, to decide whether a application redeployment(hotdpeloyment) is necessary. In AS-4.x, we used to watch only for known files application.xml, web.xml (and other known top level descriptor). The nice thing about that feature was we let the end users decide when they want to trigger a redeployment instead of guessing it ourselves. So in AS-4.x, an end user could do 'n' number of changes to various xml files (or other files) in the metadata locations of the application (or any other location) and then at some point "decide" to trigger the redeployment by touching the application.xml or the appropriate top level descriptor. There were no surprises here. However in AS-5, this has changed. It's now the application server which does redeployments more aggressive by guessing that the application needs redeployment. So if the user has to do 'n' number of changes to various xml files in the metadata locations, then the AS could end up triggering those many redeployments, effectively taking away the control that end users had over redeployments in AS-4.x. Users are finding this default behaviour difficult to manage. In AS-5, the configuration/filter which decides which files to consider for redeployments is managed by this (in profile.xml): | <bean name="MetaDataStructureModificationChecker" class="org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker"> | <constructor> | <parameter><inject bean="MainDeployer" /></parameter> | </constructor> | <property name="cache"><inject bean="StructureModCache" /></property> | <property name="filter"><bean class="org.jboss.system.server.profile.basic.XmlIncludeVirtualFileFilter" /></property> | </bean> | So *by default* in AS-5, the filter is meant to check for all xml files. It can be argued that the end user can configure/tweak this filter as per his wish to take care of his re-deployment needs. But do we really want the normal end users (most of them) to be changing this? Or should be *by default* manage it such that we have a similar behaviour as AS-4.x may be by using the PatternIncludeVirtualFileFilter | <bean name="MetaDataStructureModificationChecker" class="org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker"> | <constructor> | <parameter><inject bean="MainDeployer" /></parameter> | </constructor> | <property name="cache"><inject bean="StructureModCache" /></property> | | <property name="filter"> | <!-- A pattern matching filter. We can configure this to our custom pattern. | Here we configure it to include only application.xml and web.xml | for modification check (and any subsequent redeployments) --> | <bean class="org.jboss.system.server.profile.basic.PatternIncludeVirtualFileFilter"> | <constructor> | <!-- Remember, the parameter is a regex so use the correct syntax | as below --> | <parameter class="java.lang.String">application.xml|web.xml</parameter> | </constructor> | </bean> | </property> | | </bean> | The PatternIncludeVirtualFileFilter approach is just an example. The real question is, *by default* should we be really doing the guess work for redeployments or like AS-4.x only watch for known top level files and give the end users more freedom to trigger an redeployment? Furthermore, if some advanced user wants to customize the way redeployments are done then he can always change the default settings, but for most of the users should we switch to AS-4.x behaviour? Thoughts? [OT] - The PatternIncludeVirtualFileFilter (and other similar filters) in Branch_5_x needs to be changed to extend the new class that was introduced in JBDEPLOYERS for 2.0.8 version. Or else these filters won't be usable as a cacheFilter. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249565#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...