geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <>
Subject Re: [web][deployment] Was: [dom4j/w3c] Exposing Documents on geronimo components
Date Mon, 25 Aug 2003 13:07:02 GMT

It seems like the app client container is 1 : 1 with an application 
instance. This is also similar to the situation with the ejb container, 
where whilst the container may have a number of beans within it, all 
beans are of the same type. In both of these cases, setters on the 
container for configuration make sense. This isn't the case with the web 
container - it will contain many different web applications, each with 
different config. Setters on an individual webapp to pass in the 
contents of the web.xml could make sense, but this would be a little 
awkward as the web app must provide the xml of it's deployment 
descriptor as a String to satisfy JSR77 - the webapp would have to 
reconstruct it from the data from the setters. Plus, as the concrete 
containers all want to access the web.xml file anway, I'm starting to 
think it would just be easier (for now) to assume the web container only 
requires to be passed the URI of a webapp to deploy, and possibly a 
context path derived from an application.xml file if the webapp is part 
of an ear.


> 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


  * Jan Bartel <>
  * Associate
  * Core Developers Network LLC

View raw message