One of the things that we omitted, then had to hack in, in a certain other app server was virtual host support. Virtual hosts are not (AFAIK) yet supported by the std dd. Of course, they can be supported in a proprietary dd (section), however, an number of people wanted e.g. 1 deploy dir per virtual host. I guess we need some sort of retrievable deployment content object that holds e.g. parsed dds, who did the deploying and other stuff, that the webcontainer may OPTIONALLY dip into in order to enrich it's understanding of what is going on. However deployment should be able to go ahead without access to this context?
If I am talking rubbish - it's because I haven't really been following this thread.... :-)
Jules
Greg Wilkins wrote:
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
-- /************************************* * Jules Gosnell * Partner * Core Developers Network (Europe) * http://www.coredevelopers.net *************************************/
