geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Opacki <chris_opa...@yahoo.com>
Subject RE: J2EE DeploymentManager ( was J2EE deployment verifier)
Date Wed, 13 Aug 2003 18:49:52 GMT
Sounds like a plan.. it seems someone has already
implemented all of these javabeans.

--- Aaron Mulder <ammulder@alumni.princeton.edu>
wrote:
> 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 
> > > 
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Mime
View raw message