Aaron Mulder wrote:
Jan (and Greg),
This looks cool.
It's all Jan at the moment - I'm stuck into Jetty5 and making it a bit more flexible to suit. But happy to take credit for any of the cool bits :-) (NB. but I will soon to the clean up of Component and ManagedObject stuff that I spoke about some time ago).
That said, I'd like to work on centralizing some of the deployment logic. All the work of dealing with deployment plans and tasks is going to be fairly common across application module types, and we'll need to bring a lot of it together when we deploy an EAR anyway (arranging ClassLoaders and identifying context roots and so on). Also, the JSR-88 model lets you distribute an application to one or more servers without starting it, and the MBeans need to created at distribute time so they can be invoked to start it.
I think centralizing logic is a good thing to do, but I am very cautious about moving webapp specific knowledge out of the webcontainer itself.
The common deployment planning should all be about abstract geronomo services and not about specific types of services. Remember that the webcontainer, the webapp, the webconnector, the request log, etc are all first class geronimo services and we don't want to have to move detailed planning for all of these into a centralized spot.
So I'd like to build most of that into the application deployer service, and then have the application deployer call out to the WebContainer, EJBContainer, etc. at a later stage, more like:
start(String contextRoot, ClassLoader parent, File warDir, (DD POJO));
This is exactly the sort of API that I would like to avoid. The deployment mechanism should only be calling standard JSR77 style start/stop methods and nothing specific to a webapplication. I think all these parameters have better ways of being pased:
contextRoot - should be obtained from the DDs
parent - should be the Thread context loader for any call to the service.
warDir - is a configuration parameter passed during construction of the
service.
DD POJO - The API should not reflect our POJO DD's. A service should be free
to read the DDs from disk if it want's to. Of course we want it
to use the preparsed POJO DD's for efficiency and dynamic
deployments,
but I think that should be an option for a well written service.
Thus the service should use a DD API to ask for it's POJO DD rather
have it pushed at it.stop(...) restart(...)
Does that sound reasonable to you? Can you help me define what the WebContainer interface should look like for that? For example:
The webcontainer interface should look like a standard JSR77 lifecycle. Any bells and whistles we add should be common to all g-services and nothing should be specific for webapplications.
- Should we always unpack a WAR into a temporary dir before handing it over, or are you just as happy to get a packed WAR file?
I think unpacking should be the default option. It can be handled by the common deployer - but not in terms of war's specifically. I'd prefer to see it have a configurable none/shallow/deep unpacking mechanism that can be applied to arbitrary service bundles.
So I think we should look to moving common code out of the webcontainer deployer, but let's try to keep it as generic as possible. I think Jan is working on a constructive response that may suggest how to do this.
cheers
