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 Mon, 08 Sep 2003 22:30:05 GMT


Aaron Mulder wrote:
> 	Let me address the Describable and Displayable issue first.  They
> apply only to J2EE DDs (Geronimo has no additional requirements for *more*
> description, though it would inherit the J2EE descriptions).  I added
> these strictly as a convenience, since loads of tags have descriptions and
> display names and so on, and I figured why not share a common
> implementation?  

They are good classes/interfaces and I think they should be there.
But they need to be there in the geronimo  instances also (even though
we may never actually use them :-)  At the moment, some of the
geronimo classes do not inherit from anything that implements
Describable  (eg geronimo.ejb.Ejb)

 > If we're constrained for parent classes, then we should
> just copy the fields and properties into all the relavant classes, and
> declare an interface for them so the XML loader can treat them all the
> same.  But I think these two are probably safe: it can go
> Object->Describable->Displayable->ejb.EjbJar->geronimo.ejb.EjbJar

That example is simple enough because EJBJar is a leaf of the tree.
But it does not work so well for nodes of the tree. see below.

> 	The "Ejb" and "RpcBean" classes are similar -- they just group 
> fields and properties that would otherwise need to be copied into two or 
> more subclasses.  They can also be replaced by interfaces, but the J2EE 
> ones are probably safe and the and the Geronimo ones probably need to be 
> replaced, so it can go:
> ...Displayable->ejb.Ejb->ejb.RpcBean->ejb.Session->geronimo.ejb.Session

But geronimo.ejb.Session should extend geronimo.ejb.EJB

Or are you saying that we just just don't have a geronimo.ejb.EJB class
and multiple implement it's methods in geronimo.ejb.Session, geronimo.ejb.Entity

> 	All these superclasses were written before the idea came up to 
> combine the Geronimo & J2EE bean trees, 

Ah that explains a lot.

 > but again I think it's just the
> extra Geronimo superclasses that need to be eliminated (and/or replaced 
> with interfaces).

I don't know if that works as well as making the standard ones interfaces.
If the standard elements are interfaces, then I think we can implement
the POJOs with only a single implementation of every method.  If the
standard elements are POJOs then we are going to have to do multiple
implementations methods on geronimo.ejb.EJB etc.

> 	Finally, I think we do want POJOs for the J2EE DDs alone, and then 
> have the Geronimo ones extend those.  The JSR-88 deployer tool is supposed 
> to let you edit J2EE DDs (though it's not strictly required), and I 
> suspect we'll want to make use of the J2EE POJOs for that.  

There should be no problem generating the standard J2EE DDs using the
geronimo POJOs.  You should be able to use the geronomo instances via
the standard interfaces and thus you will not know about the extra
geronimo methods unless you want to.

So I still favour making the standard beans the interfaces.  Just to
be clear, here is the code snippets that I'm proposing again.   I
now think that option 2a is best plus I think the geronimo classes
should be named Geronimo* to avoid needing o.a.g.d.m.g.ejb package
names to disambiguate the names.

package o.a.g.d.m.j2ee;
interface EJBRef extends Describable
   public String getEJBLink();

package o.a.g.d.m.ejb;
interface EJB extends Describable
   public EJBRef[] getEjbRef();

interface Entity extends EJB

package o.a.g.d.m.geronimo.j2ee;
class GeronimoEJBRef extends GeronimoDescribable implements EJBRef
   String ejbLink;    // standard implementation
   String jndiName;   // geronimo implementation

   public String getEJBLink(){
     return ejbLink;

   public String getJndiName() {
     return jndiName;

package o.a.g.d.m.geronimo.j2ee;
class GeronimoEJB extends GeronimoDescribable implements EJB
    GeronimoEJBRef[] geronimoEjbRef;

    public EJBRef[] getEjbRef() {
         return geronimoEjbRef;

    public GeronimoEJBRef[] getGeronimoEjbRef() {
         return geronimoEjbRef;

class GeronimoEntity extends GeronimoEJB implements Entity

Note that as the Geronimo instances are the only concrete ones,
then we will always be creating Geronimo objects.  Thus I would
propose that the standards interfaces do not have setters, only


View raw message