Re: DConfigBeans Starter Info

[Adriano Orlando Campestrini <ca...@gmail.com>]

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 <am...@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.
>

Re: DConfigBeans Starter Info

[David Jencks <da...@yahoo.com>]

On Jul 7, 2005, at 9:48 PM, Adriano Orlando Campestrini wrote:

> 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...)?

Geronimo is more or less divided into runtime and deploy time pieces.  
At runtime, everything is a gbean, and the artifacts that are started 
are Configurations including serialized gbean state.  The deploy time 
phase consists mostly of taking j2ee artifacts and plans and turning 
them into gbean configurations.  The non-builder modules (e.g. 
connector) have the runtime classes that actually implement the 
functionality.  The builder modules translate j2ee artifacts + plans 
into gbean configurations that typically use the runtime classes.

> 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?

the DConfigBeans model the geronimo plans.  For connectors, we 
translate a 1.0 connector ra.xml into an equivalent 1.5 ra.xml before 
"building" it.  This makes it easier to use geronimo plans of the same 
format for both 1.0 and 1.5 connectors.  We do similar though less 
dramatic transformations for ejbs and web apps to bring the descriptor 
we deploy up the the latest spec version.

> 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.

Offhand I'm not sure.   AFAIK the DConfigBean code has not been 
maintained for about a year or more and most of it no longer 
corresponds with the plan structure.

As a comment, when I last worked on DConfigBeans I attempted to keep a 
live correspondence between the DConfig javabeans and the xmlbeans used 
for reading/storing the xml.  IMO it is somewhat difficult to do this 
with things like reordering arrays of beans.  It may be a better idea 
to initially read the xmlbeans into a tree of javabeans, and then on 
save simply create a new xmlbeans structure from the javabeans.  On the 
other hand you may find a simpler more generic way of translating 
between the javabeans and the xmlbeans.

thanks
david jencks

>
> Adriano...
>
>
> Can you send me your GUI with some instructions on how to run it?
>
>
> On 6/28/05, Aaron Mulder <am...@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.
>>
>