> From: Jan Bartel [mailto:[EMAIL PROTECTED] > 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
