1 2 Previous Next 21 Replies Latest reply on Mar 27, 2008 12:29 PM by jhalliday

    Tomcat Deployer is wrong in JBoss Head

      The Tomcat Deployer in JBoss Head should not be starting Tomcat.

      The deployer should just be creating MBeans that have a dependency on Tomcat
      with Tomcat started from the deploy directory as a service.

      It needs splitting into two deployments, a WARDeployer and a Tomcat/JBossWEB service.

      This will also allow "on demand" where if there are no web deployments
      Tomcat doesn't need to start.

      I've just had to hack JCA to put the "Cached Connection Manager"
      in the jca deployers otherwise Tomcat (really the WARDeployer)
      won't start with the CachedConnectionManagerValve enabled.

      This is only a temporary solution!

        • 1. Re: Tomcat Deployer is wrong in JBoss Head
          brian.stansberry

          +1. The same problem you had re: the Cached Connection Manager exists for a JBoss Cache instance if the ClusteredSingleSignOn valve is used. There's a longstanding hack in the ClusteredSingleSignOn that gets around the problem, but it would be nice to get rid of it.

          • 2. Re: Tomcat Deployer is wrong in JBoss Head
            rmaucher

            Ok, how is that splitting supposed to be done ?

            • 3. Re: Tomcat Deployer is wrong in JBoss Head
              brian.stansberry

              This doesn't answer your question, but FYI here's an earlier related forum thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=93651.

              • 4. Re: Tomcat Deployer is wrong in JBoss Head

                 


                Remy Maucherat [04/Dec/07 06:07 PM] I propose postponing this until after AS 5 (since this tree is supposed to be more or less stable, and the current code works perfectly well). This would most likely include using a new infrastructure to process server.xml and META-INF/context.xml webapp configuration (maybe merged into jboss-web.xml).


                The purpose of the change is to split the Tomcat deployer into two parts.
                Whether this is done physically or logically is a different question.

                The first stage is just to get something in place that knows how to parse
                {jboss}-web.xml and create the MBeans.

                The second stage is getting the infrastructure to satisfy the dependencies
                of those MBeans.

                The main aim is that the MBeans that represent web deployments
                and connectors should not be started until their dependencies are satisified.
                Currently it is the Tomcat Deployer itself that has these dependencies.

                Without this change, we have to promote other services (clustering/jca/etc.)
                to earlier in the deployment process just so we can parse a web.xml
                This has knock on affects into other services and causes all sorts of problems.

                If there was a real physical split then we could start Tomcat "on-demand"
                when the first deployment with a web application appears, but that
                is additional functionality to the basic problem.

                We'll eventually need something like this anyway, because we want to
                run the deployers in "off-line mode". i.e. just do the parsing and dependency
                checking without creating any real services.
                This is so we can validate configuration in a management console
                without having to boot the whole server to check if it is reasonable.

                Postponing the resolution of the problem to after 5.0.0 is not acceptable.
                This issue has been open for 6 months with nothing being done about it.
                I'll do it myself if necessary. :-)

                • 5. Re: Tomcat Deployer is wrong in JBoss Head

                   

                  "adrian@jboss.org" wrote:

                  The first stage is just to get something in place that knows how to parse
                  {jboss}-web.xml and create the MBeans.


                  By MBeans I mean the ServiceMetaData not the physical objects.

                  • 6. Re: Tomcat Deployer is wrong in JBoss Head
                    dimitris

                    A JIRA to track progress on this:
                    http://jira.jboss.com/jira/browse/JBAS-5144

                    Tentatively scheduled for AS5 CR1, the primary goal is to get the ball rolling for this refactoring.

                    • 7. Re: Tomcat Deployer is wrong in JBoss Head
                      rmaucher

                      This is now tracked by:
                      http://jira.jboss.com/jira/browse/JBAS-5144

                      I will need a resource to put together the arhcitecture behind this refactoring.

                      • 8. Re: Tomcat Deployer is wrong in JBoss Head
                        alesj

                         

                        "remy.maucherat@jboss.com" wrote:

                        I will need a resource to put together the arhcitecture behind this refactoring.

                        I'll go over the past forum posts related to this.
                        But if someone can quickly explain me what exactly we need to do, I can help you with the impl.


                        • 9. Re: Tomcat Deployer is wrong in JBoss Head
                          rmaucher

                          Cool. Feel free to describe what you think are the steps [since I'm not sure I have a precise picture of what the end result should look like].

                          • 10. Re: Tomcat Deployer is wrong in JBoss Head
                            starksm64

                            I'll sketch out more on this, but its mostly just expanding the existing breakup of the TomcatDeployment to inject services it is now creating as part of its mbean lifecycle. In addition, there is the question of migrating these to mc beans, and creating more of the web app components as beans with dependencies on things like the web connectors rather than creating these by parsing the server.xml. There are class loader assumptions that need to be fixed as well as I mentioned in another thread.

                            • 11. Re: Tomcat Deployer is wrong in JBoss Head
                              rmaucher

                              It would be good if you did the packaging and the basics of that new web deployer, moslty with a minimal mostly hardcoded configuration for the servlet container, and I would then do the handling of the configuration that is in server.xml at the moment.

                              • 12. Re: Tomcat Deployer is wrong in JBoss Head

                                The first step doesn't need to be very complicated.
                                We just need to logically seperate the deployment chain
                                from the runtime.

                                Migrating to POJOs isn't a requirement.
                                You can leave all the classes in the jbossweb.deployer deployment
                                for now, there's no need to seperate immediately runtime classes from deployment
                                classes.

                                If you look at jbossweb.deployer/META-INF/war-deployer-beans.xml
                                it contains a number of deployers but these mix the deployment process
                                with the runtime.

                                What we want is a
                                1) deployers/jbossweb.deployer
                                that is just the deployers and handles the metadata (constructing ServiceMetaData
                                for the individual web apps)
                                2) deploy/jbossweb
                                this is the runtime that the mbeans above get deployed into

                                In more detail, the current deployers are

                                1) WebAppParsingDeployer
                                Ok, this parses the web.xml to create a WebMetaData

                                2) JBossWebAppParsingDeployer
                                Adds the jboss-web.xml to the WebMetaData (again ok, except the loader repository
                                stuff which shouldn't be in the parsing layer)

                                3) WebAppClusteringDefaultsDeployer
                                This is ok. It just modifies the WebMetaData to add defaults

                                4) WebAppClusteringDependencyDeployer
                                Again just modifies the metadata to add dependencies that will later be used
                                by the mbean deployment

                                5) WarDeployer
                                This is what is wrong. It does at least two things
                                5a) It configures Tomcat
                                5b) It creates the ServiceMetaData that represent web deployments

                                My guess is that it also handles some of the runtime process of that
                                ServiceMetaData as well?

                                Instead what should happen is that the runtime processing
                                (configuration of the connectors and the other bits associated
                                Tomcat's runtime in the server.xml) should be in deploy/jboss-web
                                as a seperate service.
                                The MBean that gets constructed from the ServiceMetaData
                                will interact with this seperate runtime.

                                In summary, the deployers should just be deailing with the metadata
                                {jboss-}web.xml -> WebMetaData -> ServiceMetaData
                                this ServiceMetaData will then desribe a WebDeployment MBean
                                that will interact with the runtime services to create the actual WAR.

                                Once that is done, we will no longer neded to pull lots of services
                                like the transaction manager or the CachedConnectionManager into
                                the bootstrap just to satisfy the Tomcat deployer's dependency on them.

                                The clustering part of the WAR deployment has it correct,
                                in that the dependencies are just names (not implementation)
                                that will be satiisfied when those services are deployed.

                                • 13. Re: Tomcat Deployer is wrong in JBoss Head

                                  Looking at the AbstractWarDeployer this looks ok to me.

                                  So the first step would be to seperate out the runtime part of TomcatDeployer
                                  into a TomcatService or something that is constructed in deploy.

                                  Other things that look wrong are things like:

                                   config.setSecurityManagerService(this.secMgrService);
                                  


                                  where secMgrService is a link to the object rather than the name.
                                  This kind of thing should be configured in the ServiceMetaData as an injection
                                  based on a name.

                                  • 14. Re: Tomcat Deployer is wrong in JBoss Head
                                    brian.stansberry

                                    I'd thought about this separation of the deployment chain and the runtime a while back. AFAICT it seemed quite simple; looked like the different functionality in TomcatDeployer was largely separated into different methods, with the stuff related to controlling the webserver lifecycle encapsulated into create/start/stop/destroy and the deployment stuff quite separate. The only common bit I saw was the fact that both sides were interested in conf/web.xml. As long as that resource was in a location visible to both deploy and deployers, it might just be a matter of splitting the class.

                                    1 2 Previous Next