Hotdeployment is still broken

[adrian.brock]

If I change a jsp page it shouldn't be redeploying the war file!

[alesj]

I think this is the cause:
- https://jira.jboss.org/jira/browse/JBAS-6148

[adrian.brock]

Ok, Sacha/Scott asked me to look at this
(well actually he asked me to look at something else but this is close enough ;-)

This hasn't moved on much since I first raised this issue:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064180#4064180
and as Charles points out on the JIRA, the touch of deployment descriptors is broken
again
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=145508

The basic issue here is that we now have three scanning mechanisms
(one of which isn't currently getting used).

There is

1) the HDScanner which has some sane rules and a decent abstraction
but it is only used during the initial scan at bootstrap time
2) a MetaDataAwareProfile that knows where deployment descriptors live
3) a SerializableDeploymentRepository that assumes incorrectly that a profile
is made of local directories

Neither (2) or (3) are aware of the "sane" rules that the initial HDScanner
used when determining what is a deployment.

The SerializableDeploymentRepository also doesn't seem to understand
that there should be any number of (sub-)profiles and that they could be activated
"on the fly":
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136492
It doesn't seem to understand (sub-)profiles at all?

There is an APPLICATION_TRANSIENT phase in there but it doesn't look
to be complete or have a notion of whether a (sub-)profile is currently active
when looking for modifications.

[adrian.brock]

There are actually two quick fixes which solve the
initial problems described above.

1) Copy some of the "sanity" rules into the SerializableDeploymentRepository
such as not recursing into directories that have a dot in the name (although even
for that rule there is a FIXME in the HDScanner :-).

This doesn't solve the fundamental issue which is that profile implementations
should be definable per sub-profile. The repository should not be
interfering with the initial definition or assuming anything about it, let alone being that definition.

2) Include the MetaDataAware handling in the SerializableDeploymentRepository
so we know when deployment descriptors (anything in the metadata-locations)
get modified.

The other problems are much too fundamental for quick fixes. ;-)

[adrian.brock]

1) the HDScanner which has some sane rules and a decent abstraction
but it is only used during the initial scan at bootstrap time

When you are not using the repository.

[starksm64]

2) Include the MetaDataAware handling in the SerializableDeploymentRepository
so we know when deployment descriptors (anything in the metadata-locations)
get modified.

We need this to know when admin edits are out of date anyway, so let's focus on that fix.

[emuckenhuber]

2) Include the MetaDataAware handling in the SerializableDeploymentRepository
so we know when deployment descriptors (anything in the metadata-locations) get modified.

Yes - i was creating JBAS-6148 because of that :)

Furthermore:

 <!-- A filter for excluding files from the scanner -->
 <bean name="DeploymentFilter" class="org.jboss.virtual.plugins.vfs.helpers.ExtensibleFilter">
 <!-- Files starting with theses strings are ignored -->
 <property name="prefixes">#,%,\,,.,_$</property>
 <!-- Files ending with theses strings are ignored -->
 <property name="suffixes">#,$,%,~,\,v,.BAK,.bak,.old,.orig,.tmp,.rej,.sh</property>
 <!-- Files matching with theses strings are ignored -->
 <property name="matches">.make.state,.nse_depinfo,CVS,CVS.admin,RCS,RCSLOG,SCCS,TAGS,core,tags</property>
 </bean>

Is not taken into account at all in the repository profile and the basic profile it's also not considered for ModifiedDeployments (JBAS-6147)