You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2003/08/30 18:14:01 UTC

[Deployment] Help plan for application deployment

	So I'm trying to figure out what needs to be done to be able to 
deploy an EJB JAR from the JSR-88 deployer.  Here's what I've found by 
looking through the code (please correct where wrong):

 - When you start Geronimo, a new JMX kernel is initialized, and it loads
a minimal set of MBeans (the DeploymentController, DeploymentScanner,
etc.)

 - the DeploymentScanner then identifies anything (in the deploy
directory) to deploy into the running server.  Currently it only knows how
to handle Geronimo services (either a service XML file, or an unpacked
archive with a service XML file), not applications.

 - When a service is identified, the ServiceDeploymentPlanner creates a 
deployment plan for it including tasks such as "register MBean" and "start 
MBean"

 - You can access MBeans running in Geronimo from outside the current JVM 
using the RemoteMBeanServerFactory

 - There are no EJB containers "ready to go" today

 - There is no "EJBContainer" interface corresponding to 
o.a.g.web.WebContainer, but there should be


	If all that is right, here's where I'm going with this:


 - I'll create a new ApplicationDeployer MBean.  For now, it won't have
directory scanners or anything, you'll have to call it over JMX.  It will
have a method that takes an archive and a JSR-88 "deployment plan" -- for
now, that will probably be a file name and two byte arrays for remote use,
and two URLs for local use.  (Is there a way to stream the file data to
the MBean over the remote JMX connection, instead of loading the whole 
puppy in memory?)

 - I'll have the JSR-88 DeploymentManager connect to the 
ApplicationDeployer MBean using the RemoteMBeanServerFactory

 - We need a structure to use to manage containers and their related 
information.  I'm thinking of something similar to OpenEJB, where we could 
have a ContainerSystem holding application-scoped stuff (JNDI tree, 
security service, etc.) and then the metadata for all the application 
components.

 - The ApplicationDeployer would prepare the ContainerSystem (including
creating implementation-neutral EJB/Web/Connector metadata), and then call
out to the EJBContainer and WebContainer (and ConnectorContainer?)
implementations to actually deploy stuff

 - It will be the responsibility of the EJBContainer implementation to 
instantiate new containers for each application, though it will be given 
things like the JNDI tree, ClassLoader, and metadata, so it will just be 
responsible for creating the runtime components, interceptors, etc.  
Likewise for the other containers.

 - The WebContainer interface will need to be adjusted somewhat to let
Geronimo do the unpacking and configuring and pass more detailed
information as part of the deployment request (base ClassLoader, security
system, perhaps a dir for static content, metadata...)


	All that sound right?  I also have one more question:


 - There will be JavaBean representations of the Geronimo-specific and
J2EE-standard deployment information based on Castor or XMLBeans or
something along those lines.  Currently, there is the beginning of another
set of the same data in o.a.g.ejb.metadata.  The latter has the advantage
that it can declare more useful enumerated contstants and so on, but its
getting tiresome copying the metadata from one object tree to another "the
same but different" object tree.  Can we remove the ejb.metadata classes
and rely on the Castor/XMLBeans classes, or is the friendlier interface of
the ejb.metadata classes too important to lose?


Thanks,
	Aaron