geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: [XML][Deployment]POJO design?
Date Sat, 13 Sep 2003 09:31:42 GMT

Jeremy Boynes wrote:
> For those who missed the Jira mail, I have uploaded a derivative of
> Aaron's patch that allows the geronimo EJB POJO's (like Session) to
> subclass the spec ones and still implement JNDIEnvironmentRefs

For me this patch is a little bit better - it is starting down the
path of my original proposal of linking the two trees with interfaces.

However there are still many things that I don't like about it:

- I see it as a pragmatic handcrafted rendering of the DD schema that will
work for current usage.  But without a common pattern applied to all elements it
will be vulnerable to problems if/when we need to extend other elements with
geronimo config or find common  uses for elements other than JNDIEnvironmentRefs.

- Without a strong design pattern being used to map from the schema(s) to the POJOs
we will have problems doing any automation that works from the schemas.  This
will make it more difficult to implement what was decided in the XML Parsing discussion,
namely to look for an XML framework to load/store the POJOs.

- The use-case for have dual trees has not been well established.
   All we have is "Tools that edit a standard-only DD", yet:

     + Will geronimo have any tools that deal with only the standard DD?

     + Tools are free to ignore the geronimo methods - which are not
       great in number and we can identify with interfaces or javadoc.

     + We have elsewhere made the decision to merge the XML of the
       standard and geronimo DD descriptors - so geronimo tools will probably
       have to deal with merged DDs anyway.

     + The existance of a standard only tree may encourage dual parsing of DDs.
       If code that only needs standard elements loads a standard tree, then that
       tree will not be usable by other code that wants the geronimo tree. What is
       the policy for loading - will we always load the geronimo tree to avoid double

- The dual method approach for getXxx and getGeronimoXxx is a bit
ugly and confusing (yeah I know I proposed it).  Also the setXxx() methods
only provides runtime type safety not compile time type safety.  I guess
we can't avoid this with dual trees.

- There are no methods for converting between standard and geronimo elements
and/or trees.  So a lot more code is needed before this solution is complete and
generally usable.

I'm sorry but I still see the current approach as hand crafted pragmatism, when
there is no reason to avoid application of a rigourous design pattern.

I don't think there has been any real criticism of the patch that I have
done - other than the lack of a standard tree.

If the case for a standard tree is made, then I think we would be better of with
a rigorous application of a dual tree design pattern to the standard and geronimo
DD schemas.  This is perhaps bit more code, but it is regular in design and easy
to understand and predice.

 > I am not convinced we have reached conclusion yet and so would suggest
 > that if we do start committing thigs they go in a different branch.

we need to move on, so lets have a vote.  I'll post a vote messages shortly.


View raw message