geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [XML][Deployment]POJO design?
Date Tue, 09 Sep 2003 16:03:41 GMT

On Tuesday, Sep 9, 2003, at 14:28 Europe/London, Aaron Mulder wrote:

> 	Comments below...
> On Tue, 9 Sep 2003, Alex Blewitt wrote:
>> Why should session not be able to extend it? I don't understand:
>> public interface EJB
>> public interface EntityBean extends EJB
>> public interface SessionBean extends EJB
>> public interface MessageDrivenBean extends EJB
>> public class J2EEEJB implements EJB
>> public class J2EEEntityBean extends J2EEEJB implements EntityBean
>> public class J2EESessionBean extends J2EEEJB implements SessionBean
>> public class J2EEMessagDrivenBean extends J2EEEJB implements
>> MessageDrivenBean
>> public class GeronimoEJB implements EJB
>> public class GeronimoEntityBean extends GeronimoEJB implements
>> EntityBean
>> public class GeronimoSessionBean extends GeronimoEJB implements
>> SessionBean
>> public class GeronimoMessageDrivenBean extends GeronimoEJB implements
>> MessageDrivenBean
> It does not make sense for GeronimoEJB to extend nothing, and for
> GeronimoEntityBean to extends GeronimoEJB.  All the content that
> GeronimoEntityBean needs to inherit is in J2EEEntityBean.

I disagree with your thought that GeronimoEJB needs to subclass 
something, or for the fact that GeronimoEntityBean is a subclass of 

This is a common issue on OO projects -- to use inheritance, or to use 
composition. The right answer is almost always to use composition.

What you get with composition is the flexibility to change the 
underlying structure at runtime (at either end). With inheritance, this 
is a 1-1 fix and cannot be changed (one instance always has one 
superclass instance). Such structures tend to result in somewhat ugly 
copy-constructors that convert between the two types where necessary.

So I argue that it does entirely make sense for GeronimoEJB to extend 
nothing, in the same way that the J2EEEJB extends nothing. It's a 
composition relationship; a GeronimoEJB contains geronimo-specific 
stuff and a reference to the non-specific J2EE object.

> The way you've
> set it up above, GeronimoEJB needs to duplicate all the code in 
> J2EEEJB in
> order to implement the EJB interface, and likewise GeronimoEntityBean
> needs to duplicate the code in J2EEEntityBean, and so on.  Whereas if
> GeronimoEntityBean extends J2EEEntityBean, all that is inherited not
> duplicated.

Not necessarily; if there were methods in the EJB that were required as 
part of the standard, these could simply be forwarded to the 
appropriate J2EE object:

interface EJB { public String getName(); }
class GeronimoEJB implements EJB {
   public String getName() {  getSpec().getName(); }
class J2EEEJB implements EJB {
   public String getName() {
     return name;

That way, no data is duplicated, and methods are simply delegated 
through. This would only need to happen once and would be trivial to 
set up using an IDE that generates delegation methods.

>> ...
>> I agree that there should be interfaces (hence above).
> I disagree; the interfaces add nothing, and require lots of code
> duplication.  If GeronimoEJB extends J2EEEJB, then you can treat both
> types as a J2EEEJB without an interface.

Interfaces allow you to treat two different hierarchies as the same 
type. If you merge them in to one hierarchy, the main reason for using 
them disappears. So depending on which model goes forward, they may or 
may not be necessary.

>> I also agree that the code shouldn't be in one place; it should be
>> split across the two hierarchies. The J2EE stuff should have the
>> vendor-neutral representation, the rest should go into the Geronimo
>> representation. And you can still achieve the transparent connection 
>> by
>> providing delegate methods from the Geronimo stuff to the J2EE stuff.
> Yes, two sets of POJOs, one J2EE-only, one Geronimo-only.  You can
> do this without interfaces (but with inheritance).  See comments above.

It then becomes more difficult to write out a web-deployment descriptor 
or Geronimo-deployment descriptor without assuming that (a) all 
elements in a tree are J2EE ones, or (b) all elements in a tree are 
Geronimo ones. With the dual-hierarchy approach, this isn't an issue at 
all, and you simply use a Visitor to walk over the content.

>> If the above types don't gel, I can knock up a skeletal code example
>> for how to represent it, but my thoughts are that the representation
>> should be in a pair of POJOs, not just a single one.
> I understand your position, no code necessary.  I simply disagree.
> Look at the GERONIMO-76 patch for the POJO hierarchy I'm recommending.
> Note that all of the Geronimo classes are virtually empty, though we 
> need
> to introduce a few new ones to cover the references.

I don't think that a code sample will help fix the basic issue that I 
have with your design. I simply disagree that it makes sense to merge 
the two hierarchies into one, since it then results in a lot more work 
in separating them out when you use them.

Remember; you only have to design a hierarchy ones. You get to use it a 
lot of times throughout the code. Optimise the use, not the design.


View raw message