Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@www.apache.org Received: (qmail 25138 invoked from network); 30 Aug 2003 14:36:40 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 30 Aug 2003 14:36:40 -0000 Received: (qmail 41658 invoked by uid 500); 30 Aug 2003 14:36:26 -0000 Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 41528 invoked by uid 500); 30 Aug 2003 14:36:25 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 41509 invoked from network); 30 Aug 2003 14:36:24 -0000 Received: from unknown (HELO www.princetongames.org) (66.250.40.202) by daedalus.apache.org with SMTP; 30 Aug 2003 14:36:24 -0000 Received: from localhost (ammulder@localhost) by www.princetongames.org (8.11.6/8.11.6) with ESMTP id h7UGE1c31703 for ; Sat, 30 Aug 2003 12:14:01 -0400 X-Authentication-Warning: www.princetongames.org: ammulder owned process doing -bs Date: Sat, 30 Aug 2003 12:14:01 -0400 (EDT) From: Aaron Mulder X-X-Sender: ammulder@www.princetongames.org To: geronimo-dev@incubator.apache.org Subject: [Deployment] Help plan for application deployment Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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