Geronimo DD Changes

[Aaron Mulder <am...@alumni.princeton.edu>]

	We (by which I think I mean myself, Jeremy, and David J) talked a 
bit at ApacheCon about changing our strategy on deplyoment descriptors.  
Our conclusion was that we should split the DDs up again, so that Geronimo 
DDs *do not* extend J2EE DDs, but we have 2 separate DD structures.  As 
for the POJOs, we would have one set of POJOs containing both J2EE and 
Geronimo deployment information, in a single tree instead of a "Geronimo 
extends J2EE" tree (because we really have no use for a J2EE tree on its 
own).  It would make both the schemas and the POJOs quite a bit cleaner, 
though we would have to do a bit of mapping at load time.

	This has two implications:

1) We'll have to rewrite the schemas and POJOs

2) We can't use a XML binding tool that generates its own POJOs (since we
will have 2 schemas going into one POJO tree).  On the up side, I've
recently heard of tools where you have to configure the tool to bind XML
to existing beans, so this might not be a big problem.

	I'm willing to undertake 1, and I'm not heartbroken by 2 (mainly 
because we've been having such problems with tools already).  But I guess 
I should put in a 3:

3) The deployment process will go unstable while we work this out

	At ApacheCon, we decided to hold off until "after the demo".  The
demo is over, but now people are talking about a release.  What do you
think about undertaking this now?

Aaron

Re: Geronimo DD Changes

[Greg Wilkins <gr...@mortbay.com>]

Aaron Mulder wrote:
> 	We (by which I think I mean myself, Jeremy, and David J) talked a 
> bit at ApacheCon about changing our strategy on deplyoment descriptors.  
> Our conclusion was that we should split the DDs up again, so that Geronimo 
> DDs *do not* extend J2EE DDs, but we have 2 separate DD structures.  As 
> for the POJOs, we would have one set of POJOs containing both J2EE and 
> Geronimo deployment information, in a single tree instead of a "Geronimo 
> extends J2EE" tree (because we really have no use for a J2EE tree on its 
> own).  It would make both the schemas and the POJOs quite a bit cleaner, 
> though we would have to do a bit of mapping at load time.

+1000000000000000000000000000000000000000000000000000000000000000000000

> 	This has two implications:
> 
> 1) We'll have to rewrite the schemas and POJOs

Well not the J2EE ones of course :-)

I think a key thing to do, now that we will not base the G-DDs on
the J2EE ones is to define up with a decent "inheritance"/include
hierarchy of the schemas.

We will have many common types and elements in the various DDs and these
should obviously come from a common schemas/parsers   It may be as simple as
have a single root G-DD schema from which all other depend, but it may
need a few base schemas ?

Once we have that structure, Jan and I can work on the Web related schemas.


> 2) We can't use a XML binding tool that generates its own POJOs (since we
> will have 2 schemas going into one POJO tree).  On the up side, I've
> recently heard of tools where you have to configure the tool to bind XML
> to existing beans, so this might not be a big problem.

As I understand it, the main reason for having a single POJO tree is to
avoid the double navigation of two DD trees that are very much the same.

So we could have separately generated POJO trees IFF we can come up
with an automated process for bonding them together into a single
tree, so that the G-DD POJOs would be available at the appropriate
location when navigating the J2EE DD POJOs.

Also note that having a single DD POJO tree is much more important
for EJBs than it is for the Web tier.  In EJB's there is considerable
duplicate structure, while in the web there is not much.
Perhaps a single tree is only an EJB container requirement?

Thus I think we should evaluate a few options before starting
to hand code lots of POJOs again.

Maybe we should defer chosing a particular technology/approach.
Instead, while you are doing the first cut at the new schemas and
DD's we could have a thread to come up with a short list of
requirements for the POJOs.  Then armed with a schema design and
some requirements we would be better placed to evaluate the many
marshalling alternatives that are bound to again be proposed.


cheers

Re: Geronimo DD Changes

[Jan Bartel <ja...@mortbay.com>]

Aaron Mulder wrote:
> 	We (by which I think I mean myself, Jeremy, and David J) talked a 
> bit at ApacheCon about changing our strategy on deplyoment descriptors.  
> Our conclusion was that we should split the DDs up again, so that Geronimo 
> DDs *do not* extend J2EE DDs, but we have 2 separate DD structures.  
> As 
> for the POJOs, we would have one set of POJOs containing both J2EE and 
> Geronimo deployment information, in a single tree instead of a "Geronimo 
> extends J2EE" tree (because we really have no use for a J2EE tree on its 
> own).

Actually there's less emphasis on the geronimo dd for the web tier as 
compared to the ejb tier.

>  It would make both the schemas and the POJOs quite a bit cleaner, 
> though we would have to do a bit of mapping at load time.
> 
> 	This has two implications:
> 
> 1) We'll have to rewrite the schemas and POJOs
> 
> 2) We can't use a XML binding tool that generates its own POJOs (since we
> will have 2 schemas going into one POJO tree).  On the up side, I've
> recently heard of tools where you have to configure the tool to bind XML
> to existing beans, so this might not be a big problem.
I can see the appeal of a single merged POJO, but on the other hand, I'd 
rather we used an automated tool than having to maintain a lot of custom 
code.

Just one other consideration: to satisfy JSR77, containers need to be 
able to return, as a String, the xml of the j2ee deployment descriptor 
of their application components. Currently, this involves a lot of 
faffing around with DOMS plus converting to POJOs. So, I'd like to see 
some way of easily obtaining this stringified form from a (merged?) POJO.


> 	I'm willing to undertake 1, and I'm not heartbroken by 2 (mainly 
> because we've been having such problems with tools already).  But I guess 
> I should put in a 3:
> 
> 3) The deployment process will go unstable while we work this out
> 
> 	At ApacheCon, we decided to hold off until "after the demo".  The
> demo is over, but now people are talking about a release.  What do you
> think about undertaking this now?
> 
> Aaron

cheers
Jan