Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Wed, 13 Aug 2003 16:12:26 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: geronimo-dev@incubator.apache.org
Subject: RE: J2EE DeploymentManager ( was J2EE deployment verifier)
In-Reply-To: <20030813181941.20197.qmail@web11007.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0308131553040.31193-100000@www.princetongames.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 13 Aug 2003, Chris Opacki wrote:
> That's exactly it! My bad for not being a bit more
> verbose. The DConfig objects are actually constructed
> from the DDBeans. Which makes me believe we want to be
> using RMI if we load the DDBeans remotely. Maybe we
> can try to more than one strategy to see what is best.
> It does appear that there would be a 1 to 1
> relationship between DDBean and the
> DConfigBeans...lots of stuff...

	Well, let me go on, then.  Let's say we're deploying an EJB "Foo"  
with an EJB Reference to another EJB "Bar" (with the reference named
ejb/Bar), and both are in the same EJB JAR, but inexplicably don't use 
an ejb-link.

	The tool side should provide a DDBeanRoot for ejb-jar.xml in the 
EJB JAR, with DDBeans for each EJB, for the EJB Reference, and for other 
tags in the ejb-jar.xml.  (I just fat-fingered that to jar-jar.xml and had 
a horrible flashback, but that's a different story.)

	When the tool wants to configure this for Geronimo, it gets a 
DeploymentManager, and then says, more or less, "dear deployment manager, 
I have this nice EJB JAR represented by [DDBeanRoot], please give me a 
DConfigBeanRoot that represents the information your product needs in 
order to configure this EJB JAR."

	So Geronimo would prepare a DConfigBean tree that has, let's say,
the root, a DConfigBean for each EJB, and a DConfigBean for the EJB
reference.  The DConfigBeans matching each EJB have properties to set the
JNDI name.  The DConfigBean matching the EJB reference has a variety of
properties -- an option for the JNDI name to map the EJB ref to, as well
as JNDI context configuration properties in case the bean is in a
different server.

	Now, since presumably the user is working on all this at the same
time in the tool, let's say they resolve the EJB Reference from Foo to Bar
by configuring a JNDI name for Bar and then mapping the reference to Bar's
JNDI name.  But now they go back and change the EJB name of Bar to Alice.  
This would invalidate the DConfigBeans, which presumably are holding
something like this under the covers:

Foo -> JNDI name "myapp.Foo"
Bar -> JNDI name "myapp.Bar"

	So there's a mechanism for the DConfigBeans to "listen for 
changes" on particular DDBeans.  Thus, when the user changes the EJB name 
of "Bar" to "Alice", the "Bar" DConfigBean gets notified, rereads the 
properties of the DDBean formerly known as "Bar", and updates its internal 
data model to something like:

Foo -> JNDI name "myapp.Foo"
Alice -> JNDI name "myapp.Bar"

	And then the user can go and update the JNDI setting for Alice in
the Alice DConfigBean screen.  Or, the user can now delete Alice
altogether, in which case the server side had better delete its Alice
DConfigBean, so the DConfigBeanRoot contains only a DConfigBean for Foo.

	So that's why the tool's DDBean implementation has to be able to 
fire XPathEvents for the DConfigBeans, and why DConfigBeans want to 
listen for events on specific XPaths.

	Also, all this work is going on in the JVM of the tool.  The tool
is directly invoking DConfigBeans which are present in the tool's space.  
If the DConfigBeans have to communicate with the server, that's something 
they handle under the covers, and it's all irrelevant to the tool, which 
just introspects the DConfigBeans that it's been given.  So the tool 
doesn't need any RMI or anything.

	Make sense?

Aaron

> --- Aaron Mulder <ammulder@alumni.princeton.edu>
> wrote:
> > 	Oops -- upon looking at the spec, I think I've been
> > the confused
> > one.  Let me back up and try to lay this out, and
> > then you tell me if you
> > agree.
> > 
> > 	The goal of the spec is for a single tool to be
> > able to configure
> > and deploy applications to any server.  So all the
> > servers will provide a
> > common API, and all the tools will be coded against
> > that API.  However, a
> > fixed API can't represent all the configuration
> > information required by
> > all app servers, so JSR-88 provides base classes and
> > then mandates that
> > the extensions to those base classes be JavaBeans,
> > so they can be
> > introspected and configured at runtime.  So the
> > server provides some 
> > methods like "deploy" and a set of configuration
> > classes that can be used 
> > by the tool to configure a specific app.  The tool
> > then creates and 
> > packages an app, creates the standard J2EE DDs for
> > it, invokes the server 
> > implementation to edit server-specific deployment
> > information for it, and 
> > then invokes the server implementation to actually
> > do the deployment, etc.
> > 
> > 	Where I was confused is that the DDBeans represent
> > the standard 
> > J2EE deployment descriptor, as opposed to the
> > DConfigBeans, which 
> > represent the server-specific deployment
> > information.  Since the tool 
> > packaged the xAR in the first place, it is assumed
> > that the tool is 
> > responsible for the standard J2EE DDs, so the tool
> > provides the DDBean 
> > objects.  The server is responsible for the
> > DConfigBean objects, which 
> > make use of the information in the DDBean objects,
> > in order to configure 
> > the server-specific information.
> > 
> > 	So if you want to work on the DDBeans, you really
> > *are* talking 
> > about the tool implementation.  The tool needs to
> > implement the DDBeans, 
> > and also present a user interface for the arbitrary
> > JavaBean DConfigBeans.  
> > The tool side doesn't need to worry about
> > communicating with the server 
> > over the network -- it just grabs a
> > DeploymentManager locally, and it's 
> > the responsibility of the server implementation of
> > DeploymentManager and 
> > the DConfigBeans to communicate with the server as
> > appropriate (and when 
> > in connected mode, etc.).
> > 
> > 	Sound right to you?
> > 
> > Aaron 
> > 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>