You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Greg Wilkins <gr...@mortbay.com> on 2003/10/04 05:57:37 UTC
Re: [webapp deployment] Progress (was Re: [Deployment] Application
Deployment Status)
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
RE: [webapp deployment] Progress (was Re: [Deployment] Application
Deployment Status)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I agree with the ideas below. One note: I'd like the default, if
no jndi-root is specified, to be that each application goes in its own
JNDI root (rather than defaulting to everything being shared in one).
I'd also like to back this up with ClassLoader separation, so that if two
apps end up in different "spaces" then they can't poke each other at all,
except through the usual external interfaces.
I think this separation would enable us to do some cool things,
like mapping each application to a different security or transaction
service, even while running in the same VM (in addition to the ability to
set up different deploy dirs and different VMs to achieve the same thing).
Finally, I'm expecting that a single EAR cannot span multiple
vhosts. You know, you can't wrap 1 JAR/WAR pair in 1 vhost block and
another JAR/WAR pair in a different vhost block. It looks like that's
true from the snippet below, but I just want to make sure.
Aaron
On Mon, 6 Oct 2003, Jeremy Boynes wrote:
> You know, thinking about it there is nothing in the standard DD
> information about binding anything to the outside world. For a WAR file,
> there is nothing that defines the context or vhost, for an EJB file
> there is nothing that defines the EJBs JNDI name or vhost. An EAR file
> defines the context for a web app, but says nothing for EJBs or vhosts.
>
> This got me thinking we can have a common mechanism for specifying a
> root context for binding things too, with lower level overrides.
>
> For example, in the geronimo-application.xml file we could have
> something like
> <application>
> <ger:vhost>mydomain.com</ger:vhost>
> <ger:jndi-root>ldap://dirserver/myapp</ger:jndi-root>
> <module>
> <web>
> <web-uri>app1.war<web-uri>
> <context-root>/app1</context-root>
> </web>
> </module>
> <module>
> <ejb>ejb1.jar</ejb>
> </module>
> </application>
>
> This would result in app1 being bound to all listeners for the host
> mydomain.com and the JNDI names for EJBs in ejb1.jar being bound to
> myapp context of the LDAP server on dirserver. Or at, least that's the
> general idea, a lot more detail is needed.
>
> This sounds like information that would be passed in a DeploymentContext
> instance associated with the unit being deployed. Then the EARDeployer
> would read its geronimo DD and populate a WARDeploymentContext which
> would be passed to the WARDeployer; the WARDeployer works out the actual
> connector to use based on the information passed in from outside plus
> what it finds in its DD. The DeploymentContext is the bridge and there
> is no need for the EAR and WAR deployers to understand each other's DD
> POJOs.
>
> --
> Jeremy
>
RE: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)
Posted by Jeremy Boynes <je...@coredevelopers.net>.
> From: Jules Gosnell [mailto:jules@coredevelopers.net]
> Sent: Monday, October 06, 2003 8:54 AM
>
> 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?
>
You know, thinking about it there is nothing in the standard DD
information about binding anything to the outside world. For a WAR file,
there is nothing that defines the context or vhost, for an EJB file
there is nothing that defines the EJBs JNDI name or vhost. An EAR file
defines the context for a web app, but says nothing for EJBs or vhosts.
This got me thinking we can have a common mechanism for specifying a
root context for binding things too, with lower level overrides.
For example, in the geronimo-application.xml file we could have
something like
<application>
<ger:vhost>mydomain.com</ger:vhost>
<ger:jndi-root>ldap://dirserver/myapp</ger:jndi-root>
<module>
<web>
<web-uri>app1.war<web-uri>
<context-root>/app1</context-root>
</web>
</module>
<module>
<ejb>ejb1.jar</ejb>
</module>
</application>
This would result in app1 being bound to all listeners for the host
mydomain.com and the JNDI names for EJBs in ejb1.jar being bound to
myapp context of the LDAP server on dirserver. Or at, least that's the
general idea, a lot more detail is needed.
This sounds like information that would be passed in a DeploymentContext
instance associated with the unit being deployed. Then the EARDeployer
would read its geronimo DD and populate a WARDeploymentContext which
would be passed to the WARDeployer; the WARDeployer works out the actual
connector to use based on the information passed in from outside plus
what it finds in its DD. The DeploymentContext is the bridge and there
is no need for the EAR and WAR deployers to understand each other's DD
POJOs.
--
Jeremy
Re: [webapp deployment] Progress (was Re: [Deployment] Application
Deployment Status)
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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
*************************************/