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 J2EEEntityBean.
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.
Alex.
