Jeremy,
a good summary of a very long conversation. Just a few small differences I'd put at the end....
Jeremy Boynes wrote:
Greg and I ended up having a very long IM discussion on the subject. We did not reach agreement on a solution, but we did come up with a plan to proceed.
Firstly, a couple of things we did reach agreement on.
A lot of the usage problem here comes from a difference in where the majority of changes happen between the web and ejb tiers. For a web container configuration, most of the changes happen in the standard deployment information (for example, adding servlets or filters, changing security constraints) and the vendor deployment information is fairly static. In an EJB configuration, there tend to be a lot more changes to the vendor deployment information, especially with CMP.
This tends to encourage people in the EJB tier to generate their deployment descriptors using tools like XDoclet rather than editing them by hand. If people do that, then the true source becomes the meta-tags and which approach we use becomes fairly irrelevant.
The trend is toward tools, especially with JSR88 on the horizon and when that gets here which approach we use is again irrelevant. However, that utopian solution is not with us now.
Finally, the current POJO model (where the Geronimo POJOs specialize the standard ones leading to a unified data mode) is a good idea and will remain.
With the new approach, the biggest problem is the duplication of configuration data between the standard and geronimo descriptors. This is especially true for the web layer where the majority of changes occur to the standard descriptor, often by IDEs, and may not be reflected in the geronimo configuration (leading to a consistency problem).
With the traditional approach, the biggest problem is the separation of data into different files with the need to keep the structure in sync between them. This is especially true for CMP EJBs where changes often need to be made in two or three files, with the potential for inconsistencies between them.
To address these issues, we have the following plan: Firstly, we will implement a loader for the web POJOs Aaron just defined that represent the standard web.xml data model. We need this regardless.
We will also generate an XML Schema definition for geronimo-web.xml that uses the new approach (this is fairly easy given as most of the extensions are already in geronimo-j2ee.xml).
We will then implement a loader for a new-style combined DD as utilities already exist for the extended J2EE schema (GeronimoJ2EELoader), making this a trivial specialization of the one above.
To solve the consistency problem with the new approach, we will implement a consistency checker that verifies that the two documents are in sync.
To solve the structure sync problem with the old approach, we will implement a fuzzy match algorithm that will build up the unified POJO model by combining information from multiple files. If necessary, we will also implement a tool that allows changes to the standard DD to be propogated to the vendor DDs (keeping the structures in sync).
I also proposed that once we have the a mechanism to build the POJOs out of multiple files, that I would removed the duplicated elements from the geronimo-web.xml file so that duplicate content would not be supported.
So we would have ejb's implementing the single file model and the web tier implementing the distinct multiple file model, but with an infrastructure that could support the merged multiple file model.
This will provide us with a framework in which to discuss the merits of the different solutions.
But I don't want that to stop discussion while the code is being written. I think what is best for web is bad for ejb and what is best for ejb is bad for web - so Jeremy and I are a little entrenched in our view points - and would appreciated input from others.
cheers
-- Jeremy
