geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)
Date Sat, 04 Oct 2003 14:36:51 GMT
	Okay, this is a bunch of inline responses, with a specific code & 
procedure proposal at the very end:

On Sat, 4 Oct 2003, Jan Bartel wrote:
> I agree there may be common code that can be extracted for the 
> deployment of various j2ee artifacts such as ears and wars. This will 
> come out as development continues and matures. However, there will 
> inevitably be differences between deploying say, a war, and a rar. It 
> seems to me almost as if you are arguing for one big happy generic 
> "application" deployer rather than specific deployers. If so, then I 
> don't agree with that approach.

	I'm arguing to split it up, so we do much of the common reusable 
tasks in a central deployer and then dispatch to a specific deployer for 
the truly custom details.

> 1. JSR88 deployment lifecycle vs geronimo hot deploy lifecycle

	My feeling is that distribute can be done nearly entirely by the
common code, with 1 or 2 calls to the WebContainer.  Let's look at the
case of an EAR.  Something needs to set up a series of ClassLoaders,
create one MBean for the EAR and another per module, validate all the
modules, and generate container-specific classes.  There are a number of 
steps invokving Goals and Tasks and Plans.  I think the application 
deployer could do everything listed above, with calls to the WebContainer 
to:

 - get the AppModule MBean class name (to use for a createMBean task)
 - validate the application (given URL, DD, etc.)
 - generate container classes (which I think amounts to precompiling JSPs 
in the case of a web container)

	If there was other web-specific logic, it would presumably happen 
in the postRegister event on the application MBean.  I think these same 3 
steps would work for implementing "distribute" for every container type.  
Most of the container-specific work seems to be in "start", which is 
implemented by the container-specific app module MBean anyway.

> 2. typed deployers
> the central deployment mechanism should only be responsible for 
> detecting things to be deployed, and arranging for distribute(), 
> start(), undeploy() or whatever to be called on the appropriate 
> deployer. Typed deployers are necessary because the things that are 
> being deployed are different. Sure, they might go through a certain 
> amount of common steps, and these can be abstracted for re-use within 
> each deployer, but it does not follow that therefore there should only 
> be one deployer for everything. For example, the web deployer, and only 
> the web deployer, should be responsible for determining such things as 
> the context path of a web application. This is very webby specific and 
> the natural place for this is in a web module. The information that is 
> used to determine that path can come from many sources: the name of the 
> directory or war, a tag in an application DD, or an override in a 
> geronimo-web DD, but the algorithm for choosing is specific to web 
> deployments only.

	I agree with the spirit but potentially disagree with the example.  
I do not believe that the application deployer should instruct the web
deployer on how to set up a servlet context or something like that.  As 
above, though, I think it can take most of the "distribute" work off your 
hands, except for a couple container-specific callbacks.  And startup is 
in your court anyway, thanks to JSR-77.
	As far as the context root is concerned, I don't want the web
container groping for content outside the web app -- the last things we
want is inadvertent dependencies where the web container penetrates its
interface to root around in the guts of the server or the application.  
So I thought it would be easy enough for the common deployer to do that
calculation for you (after all, it has the EAR DD, the file name, etc.).  
But it doesn't *have* to be done that way -- we could instead pass the EAR
DD POJOs to the web container along with the WAR DD POJOs and let you do
the calculation yourself.

	Thinking back, I seem to have overlooked how the ObjectName will 
be generated.  Personally I would rather have standard application module 
ObjectNames no matter what container is plugged in, so I'd rather see 
"geronimo.deployment:role=WebApplication,instance=(unique ID)" instead of 
"jetty:...".  So I'd prefer to add a 4th method "getUniqueID" to the 3 
listed above.  But if you feel strongly it could just be "getObjectName" 
and you can construct a Jetty name instead.

> 3. ear/war relationship
> wars can be deployed standalone, or bundled as part of an ear. In the 
> latter case, then some of the deployment information for the war is 
> contained in the deployment descriptor for the ear, and as you point 
> out, the classloader hierarchy needs to be established. I think this 
> should be handled as much as possible via the normal deployment mechanism.
> 
> To that end, I suggest we augment the signature of the deploy, 
> distribute, undeploy etc methods with another parameter: 
> DeploymentContext. This context can contain deployment descriptor POJOs 
> or xml, or classloader objects or perhaps state information. Anything 
> that defines the context in which the deployment is taking place.

	Well, I agree that we need to get more information to each 
container.

	Let me propose a revised base WebContainer and WebApplication, and
let me know what you think.  I believe this should leave the bulk of the
"geronimo kernel"-specific logic in the central deployer, and the bulk of
the module-specific logic in the container, which seems to me like the
right split:

abstract class AbstractWebContainerMBean {
  // returns i.e. JettyWebApplication
  public abstract String getModuleMBeanClass()

  // validates the deployment and returns an ObjectName if valid
  public abstract ObjectName validateDeployment(URL, EAR-POJOs, WAR-POJOs)
}

abstract class AbstractWebApplicationMBean
  public void setURL(URL)
  public void setBaseClassLoader(ClassLoader/ClassSpace)
  public void setEARDeploymentInfo(EAR-POJOs)
  public void setWARDeploymentInfo(WAR-POJOs)

  // will be called during distribution process; can precompile JSPs
  public abstract void generateContainerClasses()
}

	So now the sequence is something like this:

 - common deployer identifies app and modules
 - (something) validates EAR
 - common deployer creates app MBean
 - for each RAR in EAR:
   - common deployer calls ConnectorContainer to validate a RAR, gets
     ObjectName for valid ones
   - common deployer gets connector MBean class from ConnectorContainer
   - common deployer creates Connector MBean w/class & ObjectName provided
   - common deployer sets properties on Connector MBean
   - common deployer tells Connector MBean to generate custom code
   - common deployer gets ClassSpace from Connector MBean
 - for each EJB JAR in EAR:
   - common deployer calls EJBContainer to validate a JAR, gets
     ObjectName for valid ones
   - common deployer gets EJB JAR MBean class from EJBContainer
   - common deployer creates EJB JAR MBean w/class & ObjectName provided
   - common deployer sets properties on EJB JAR MBean
   - common deployer tells EJB JAR MBean to generate custom code
   - common deployer gets ClassSpace from EJB JAR MBean
 - for each web app in EAR:
   - common deployer calls WebContainer to validate a web app, gets
     ObjectName for valid ones
   - common deployer gets web MBean class from WebContainer
   - common deployer creates web app MBean w/class & ObjectName provided
   - common deployer sets properties on web app MBean
   - common deployer tells web app MBean to generate custom code

Note that all the deployment plans and goals and tasks are managed by 
the common deployer -- when it says "creates web app MBean" and "sets 
properties on web app MBean" it really means "registers a task in the 
deployment plan to..."  So the WebContainer is doing web stuff not 
deployment plan stuff.

Then at start time, there are just a bunch of JSR-77 start() commands
executed, so the detailed startup logic is left to the module.

You seemed to be saying that there were web-specific steps that either the 
common deployer would do inappropriately or the web container wouldn't be 
given the opportunity to do -- would that still be the case?

Aaron


Mime
View raw message