geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <>
Subject RE: Geronimo Deployment Descriptors
Date Mon, 08 Sep 2003 05:32:04 GMT
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

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

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

This will provide us with a framework in which to discuss the merits of
the different solutions.


View raw message