[rmaucher]

Ok, so my current tactic is to create a TomcatService class which would take over the code from TomcatDeployer which starts and stops Tomcat, to be placed in deploy. That's relatively easy.

What's much harder to me is how to handle TomcatDeployment, which has lots of dependencies and extends AbstractWarDeployment. The class takes care of the actual deployment, and would thus need to be split in two. The "active" parts which depend on Tomcat (the preform(Un)Deploy methods) would be moved to the TomcatService class, and called using JMX. I suppose this would work, but involves passing around a lot of objects.

I would still appreciate some concrete help with this stuff :)

[adrian.brock]

I would still appreciate some concrete help with this stuff :)

If you have specific questions/problems then I can try to help.
It might be a good time to clarify (and document?) why things are done
the way they are done?

I'm not a big expert of the web integration framework in the server module
(even less so the Tomcat module :-)
Scott is probably the best person to ask on why it is the way it is?

[adrian.brock]

What's much harder to me is how to handle TomcatDeployment, which has lots of dependencies and extends AbstractWarDeployment.

My understanding is that AbstractWar/TomcatDeployment are encapuslated
by the WebModule MBean that is used to "populate" the runtime.

It is the WebModule that is created as the ServiceMetaData
description by the deployers and it delegates to the Deployment which in
turn "talks to" the runtime in the start/stop
once dependencies are resolved (e.g. the clustering implementation or ejb-links resolved)

This could probably be simplified (a lot :-) At least since WebModule
seems to be doing little except possibly avoiding a change in api
at some previous point in history?

The link to AbstractWarDeployer (described as "container")
in the WebModule should probably be changed to be the runtime service?

[rmaucher]

Brian committed the first steps of a separation, close to my plan. I'll work on top of that.

[starksm64]

What's much harder to me is how to handle TomcatDeployment, which has lots of dependencies and extends AbstractWarDeployment.

My understanding is that AbstractWar/TomcatDeployment are encapuslated
by the WebModule MBean that is used to "populate" the runtime.

It is the WebModule that is created as the ServiceMetaData
description by the deployers and it delegates to the Deployment which in
turn "talks to" the runtime in the start/stop
once dependencies are resolved (e.g. the clustering implementation or ejb-links resolved)

This could probably be simplified (a lot :-) At least since WebModule
seems to be doing little except possibly avoiding a change in api
at some previous point in history?

Yes, the refactoring should completely redo the server/*/war deployer classes as these have not been supported as a generic spi since jboss 3x days. All we have done at this point is minimal changes to emit service metadata for things that used to be directly started by the tomcat mbean (WebModule).

[rmaucher]

Edit: Ok, never mind, I had made a really dumb mistake.

[jhalliday]

Remy

What's the status on JBAS-4511? jca-hack-for-tomcat-service.xml is causing me problems with moving the TransactionManager. I could really do with is cleaning up please.