Jeremy
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.
Jan
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 <[EMAIL PROTECTED]> * Associate * Core Developers Network LLC * http://www.coredevelopers.net ****************************************/
