geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <jer...@coredevelopers.net>
Subject RE: [web][deployment] Was: [dom4j/w3c] Exposing Documents on geronimo components
Date Sun, 24 Aug 2003 18:11:09 GMT
> From: Jan Bartel [mailto:jan@coredevelopers.net] 
> I've had a bit more of a look at the JSR88 spec. I'm not 
> convinced that 
> these DConfigBeans and DDBeans are the entities that the geronimo 
> deployer should be passing around to eg the web container.
> 
> Whilst the JSR88 beans are nice in that they provide a tree 
> modelling of 
> the contents of deployment descriptors, they are designed 
> specifically 
> to allow a 3rd party deployment tool to interoperate with a J2ee 
> platform provider. Therefore they necessarily provide a lot of 
> functionality (property change listeners, xpath listeners 
> etc) that just 
> isn't needed by the platform's internal deployment process. Moreover, 
> they provide methods that should not be exposed outside of the tool 
> environment - eg DConfigBean.removeDConfigBean().
> 
> Shouldn't the internal deployment process really just expose some 
> *immutable* bean trees representing the standard and geronimo 
> specific 
> deployment descriptors and pass these to the targets of the 
> deployment 
> eg the web container?  The deployment target (eg web container) then 
> executes xpath expressions on each descriptor tree in order 
> to extract 
> the configuration information.
> 

I don't know enough about the internals of the web container, so if you
can bear with me I'll go through how I envisage the AppClient container
working (as that is the simplest one). Hopefully it translates.

The AppClient container hosts a thick client application providing it
with J2EE resources:
* J2EE Environment accessed via JNDI in java:comp
* Security (login mechanism, propagation to invoked EJBs, URLs and
resources)
* Transactions (optional, but I want to make UserTransaction available)

I see these as being attributes of the AppClientContainer itself -
currently there are JMX Attributes for:
* The URL of the client jar, so it can construct a ClassLoader
* The name of the Class with main, so it can construct the invoker
* (uncommitted) The Context that will be bound to JNDI java:comp by the
interceptor

It is designed so that (when it is STOPPED) the container MBean can be
persisted and reloaded later (once Dain gets ModelMBean persistence
going).

With this model, the AppClientContainer does not need to know about XML,
about DDBean and DConfigBeans, even anything about the deployment
process. This keeps it lean - the last thing we need is 20MB of overhead
just to run HelloWorld. [Resource usage is important for thick client
apps especially in multi-user configurations e.g. LTSP or Citrix. ]

The deployment tool is responsible for generating this MBean
configuration from the XML DDs and user input by the Deployer. This
could happen in several ways:
* a adminstrator runs a GUI deployment tool for a specific client jar
* a platform installer configures the app during the installation
process
* the app client launcher reads the XML DDs during startup
However it happens, it is a totally distinct phase from
creating/starting the runtime container.

So there are three things participating here:
* the deployment tool, which has its own mechanism for converting XML
DDs to DDBeans
  and communicates with the deployment provider using DDBeans and
DConfigBeans
* the deployment provider, which deals with DDBeans and DConfigBeans and
the persistent
  form of the geronimo config (in XML or whatever). This converts the
configured deployment
  into MBean attributes for the container
* the container, which uses its MBean attributes to run and knows
nothing of DDBeans, 
  DConfigBeans, XML DDs or other editable configuration data.


--
Jeremy


Mime
View raw message