geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject DConfigBeans Starter Info
Date Tue, 28 Jun 2005 19:15:20 GMT
	So here's some background on where we stand with the deployment 
plan configuration beans for JSR-88 (DConfigBeans).

-- DConfigBean Background --

	The DConfigBeans are a series of JavaBeans that represent the 
content of the Geronimo deployment plans for each J2EE module.  For 
example, if the geronimo-jetty.xml plan looks like this:

<web-app ...>
  <context-root>/MyApp</context-root>
  <security>...</security>
  <ejb-ref>
    <ref-name>ejb/SomeEJB</ref-name>
    <target-name>geronimo.server:...</target-name>
  </ejb-ref>
</web-app>

The we'd need something like:
 - A DConfigBean to represent the web-app, with a property to represent 
   the content-root
 - A DConfigBean to represent the ejb-ref, with properties to represent 
   the ref-name and target-name
 - A JavaBean to represent the security element and its children

Why a DConfigBean in some places and a JavaBean in other places?
 - A DConfigBean is only used to represent Geronimo data that corresponds 
   directly to an element in the J2EE deployment descriptor (here, 
   web.xml)
 - A JavaBean is used to represent Geronimo data that does not directly
   correspond to an element in the standard J2EE DD, but is more complex
   than we can represent as a series of properties on the parent
   DConfigBean

So here, the web-app DConfigBean corresponds to the web-app element in 
web.xml.  The content-root can just be represented as a property on the 
web-app DConfigBean.  The security element does not correspond to any 
specific element in web.xml, and it's too complex to represent as 
properties (it has around 20 interesting elements and attributes), 
therefore it must be a JavaBean (most likely itself with a combination of 
simple properties and nested JavaBean properties).  The ejb-ref 
corresponds to an ejb-ref in web.xml, so that's another DConfigBean, and 
its child elements shown above can be represented as properties (though 
if you look at the element in detail, the objectNameGroup might be 
represented as a nested JavaBean).

-- Geronimo DConfigBean Status --

Geronimo has a couple DConfigBeans right now.  They are generally not 
current, so they can be used as a reference, but need to be updated and/or 
replaces.  The best place to look is in the connector-builder module, as 
it has a couple DConfigBeans and a couple JavaBeans in 
org.apache.geronimo.connector.deployment.dconfigbean

I put a little work into making a viable example out of those -- they load 
properly, and have some BeanInfo objects that provide property names and 
descriptions that a tool can take advantage of.  But they are still not 
necessarily correct as far as representing the current deployment 
information for connectors -- they were built based on an older 
geronimo-ra.xml format.

There are few or no DConfigBeans for Web (Jetty or Tomcat), EJB, EAR, or 
Client App modules.

The existing DConfigBeans are built on some base classes in the 
deploy-config package.  These are all in turn built to use code 
generated by XMLBeans to represent the Geronimo deployment plans.

-- Where to go from here --

To begin with, my recommendation would be to pick a module, get familiar
with the J2EE deployment descriptor and Geronimo deployment plan format,
and make a list of the DConfigBeans, JavaBeans, and properties you think
are appropriate for that module, and run that by the mailing list for 
review.

-- Testing --

I have a little Swing GUI that lets you load a J2EE module (JAR/WAR/etc.)  
with existing J2EE DD and Geronimo deployment plan, and it will present a
dynamic user interface built off the J2EE DD (JSR-88 DDBeans) and the
DConfigBeans.  This is still a pretty basic tool, but it'll let you make 
sure that the beans don't blow up, that they get mapped to deployment 
descriptor elements correctly, etc.

Mime
View raw message