5 Replies Latest reply on Nov 6, 2007 8:52 PM by Scott Stark

    Separating properties on the tomcat deployer

    Anil Saldanha Master

      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)?

        • 1. Re: Separating properties on the tomcat deployer
          Brian Stansberry Master

          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.

          • 2. Re: Separating properties on the tomcat deployer
            Anil Saldanha Master

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

            • 3. Re: Separating properties on the tomcat deployer
              Brian Stansberry Master

              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

              • 4. Re: Separating properties on the tomcat deployer
                Brian Stansberry Master

                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.

                • 5. Re: Separating properties on the tomcat deployer
                  Scott Stark Master

                  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.