Tomcat Deployer is wrong in JBoss Head

[adrian.brock]

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!

[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.

[rmaucher]

Ok, how is that splitting supposed to be done ?

[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.

[adrian.brock]

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. :-)

[adrian.brock]

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.

[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.

[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.

[alesj]

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.

[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].

[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.

[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.

[adrian.brock]

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.

[adrian.brock]

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.

[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.