geronimo-dev mailing list archives

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

	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?


View raw message