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 Tue, 09 Sep 2003 13:43:29 GMT

Aaron Mulder wrote:
> On Tue, 9 Sep 2003, Alex Blewitt wrote:
> 	The rationale for not having geronimo.ejb.EJB (the abstract 
> supertype for Session/Entity/Message beans) is that geronimo.ejb.Session 
> can't extend it!
> 	That's why Greg is proposing that everything in J2EE land should
> turn into interfaces, but I continue to object to having all the 
> implementation in the Geronimo objects only, especially since you STILL 
> can't avoid duplicating code.

The rational for the interfaces and dual inheritance trees is not to
avoid code duplication with the POJOs - but code reduction is a benefit.

The main thing is that it allows the correct inheritance hierarchy to
be defined.

Thus I can write code that deals with a geronimo.ejb.EJB.  Without the
correct inheritance tree, I may have to write the same code to deal
with geronimo.ejb.Session, g.e.Entity and g.e.MessageDriven
because they would not be subtypes of a common g.e.EJB.  Our hand
crafted marshalling code is one example that comes to mind here!

Ditto for subtypes of the  standard beans.  Currently the geronimo.ejb.Ejb
is not a subtype of the standard EJB.  Thus I can't pass the geronimo
object to code written against the standard API, even though all the
methods exist.

So my primary concern was to get the typing hierarchy correct.
The fact that both my proposals also reduce the code volume is bonus (and
a reflection that the type hierarchy is better).

> but I continue to object to having all the implementation in the Geronimo 
> objects only.

Can you expand on your objections?

Note that my idea of removing the setters from the standard API was
probably not a good one, and we should be able to keep them there.  So
code could be written against the standard APIs.


View raw message