geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Opacki <>
Subject RE: J2EE DeploymentManager ( was J2EE deployment verifier)
Date Wed, 13 Aug 2003 18:19:41 GMT
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...

--- Aaron Mulder <>
> On Wed, 13 Aug 2003, Chris Opacki wrote:
> > I will check on the license issue. I might have to
> > wait until later on tonight though. If anyone has
> time
> > to do it now...go for it.
> > 
> > It seems that the deployment spec actually has
> divided
> > some of API between Tool Provider and J2EE Product
> > Provider. I don't think it means "The Deploy
> Tool",
> > but the interface between the tool and the server.
> The
> > confusion in that spec is definitely where the
> tool
> > provder part of the API resides. I guess it all
> > depends on how we plan on communicating.
> 	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

View raw message