geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adriano Orlando Campestrini <cam...@gmail.com>
Subject Re: DConfigBeans Starter Info
Date Fri, 08 Jul 2005 04:48:17 GMT
Aaron,

Hi, I have studied hard the geronimo environment. Now I've made
familiar with maven, svn and the eclipse configuration for geronimo. I
could note that the project is too big. And in this cases its better
to ignore details of another modules and go ahead with DConfigBeans.

You told me about DCondigBeans on geronimo-connector-builder. I have
some basics quastions that I prefer not to post on dev list:
1 - About the objectives of the connector and connector-builder
modules. It seems that connector is a implementation or a abstraction
layer of JCA. In this case why there are these builder modules? Why
all of this packages have builders (client, axis, assembly, namig,
servicemix...)?
2 - Will all of DBeanConfig extend DConfigBeanSupport?
3 - I saw xml versions 1.0 and 1.5 of connector. Do the DConfigBeans
implement the version 1.5? How could I know about what xml files and
versions should I implement?
4 - In ResourceAdapterDConfigBean there are XPATH to some other
entities, but just one of this entities doesnt have a DBeanConfig
implementation: outbound-resourceadapter. Does this entity need to
have a DBeanConfig? And where, in the code, are implemented another
simple entities, for example, <connectionfactory-interface> and
<connectionmanager>? I need to read and think more about your
discussion about when to use DConfigBeans or simples JavaBeans.

Adriano...


Can you send me your GUI with some instructions on how to run it?


On 6/28/05, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
>         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