Separating properties on the tomcat deployer

[anil.saldhana]

I feel that the tomcat deployer is getting overloaded with properties that can be injected. Should we be separating these properties into beans (clustering, security, tomcat etc)?

[brian.stansberry]

We'd need to think about the mbean interface as well; i.e .if we still want to expose a property via JMX attributes on the deployer then aggregating properties into beans doesn't help much.

For the clustering properties I don't see any point in still exposing JMX setters for them; they shouldn't be changed after the deployer is started.

Several of the clustering properties I'm tempted to pull out of the deployer anyway; they just set global defaults that can be overridden in jboss-web.xml. I could just make the defaults hard coded for a few rarely used ones (e.g. snapshotMode/Interval). I'd have done that already but I found out a major customer is actually using snapshotMode a lot.

[anil.saldhana]

Do anything that will help us have one file (and not have -all-xxx versions)

[brian.stansberry]

AFAIK there's no reason from clustering you need a separate -all-beans.xml file. The reason it was needed in 4.x was to add a dependency on the clustering cache. That's not the right way to do it in AS 5 -- see http://jira.jboss.com/jira/browse/JBAS-4762

[brian.stansberry]

When Anil and I were discussing this a month ago, I was thinking in terms of separating out a separate deployer bean from TomcatDeployer, with that bean exposing properties for all the default clustering values. It's task is to inject the defaults in JBossWebMetaData.

Well, umm, that just seems silly. :-)

Shouldn't we have something like a jbossweb.deployer/conf/jboss-web.xml file where we declare all the defaults? WebAppParsingDeployer would handle that file in much the same way JBossEjb2ParsingDeployer handles standardjboss,xml.

[starksm64]

There already is the conf/web.xml for the standard web.xml elements, so I'd be inclined to just make it the combined jboss/web-app elements for the defaults. Note that the JBossWebMetaData binding supports all web.xml as well as jboss-web.xml elements. The jboss-web xsd/dtd have not been updated to reflect what can actually be specified.

Currently the code explicitly loads the web.xml default into the tomcat model, and then deployment JBossWebMetaData. This could also be a single step using the wrapped JBossWebMetaData that combines the deployment and default descriptors.