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