Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Mon, 8 Sep 2003 10:20:23 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: geronimo-dev@incubator.apache.org
Subject: Re: [XML][Deployment]POJO design?
In-Reply-To: <bji2gb$rj4$1@sea.gmane.org>
Message-ID: <Pine.LNX.4.44.0309081003130.31412-100000@www.princetongames.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	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?  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

	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

	All these superclasses were written before the idea came up to 
combine the Geronimo & J2EE bean trees, but again I think it's just the 
extra Geronimo superclasses that need to be eliminated (and/or replaced 
with interfaces).

	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.  Right now we 
use JDOM for read-only access, and I don't think that will work well for 
read-write access, since (if you dig a little) the DDBeans may be 
different for every DConfigBean implementation, but we need some standard 
set of JavaBeans available to construct "editor screens".

Aaron

On Tue, 9 Sep 2003, Greg Wilkins wrote:
> I'm looking at the POJOs for the deployment descriptors and I'm a
> little confused by their design and what conventions they are meant
> to follow.
> 
> The source of my confusion is that there are two inheritance
> hierarchies that are partially implemented in the POJOs
> 
> One hierarchy is the standard typing of elements :
> 
>    ejb.Entity is-a ejb.RpcBean is-a ejb.Ejb is-a j2ee.Displayable is-a Describable
> 
> The other is the vendor typing of elements :
> 
>    geronimo.j2ee.EjbRef is-a j2ee.EJBRef
>    geronimo.web.WebApp  is-a web.AbstractWebApp
> 
> But as multiple inheritance is not supported in java classes, the hierarchies
> are not complete.  For example:
> 
>    geronimo.ejb.Entity  is-NOT-a  ejb.Entity
>    geronimo.ejb.Ejb     is-NOT-a  ejb.Ejb
> 
> I work out if there is a pattern for when which hierarchy is used?
> And there are strange artifacts of this. eg
> 
>   + multiple implementations of methods like *.Ejb.getEjbLocalRef
> 
>   + methods like j2ee.Describable.getDescription() are not available
>     on geronimo.ejb.Ejb, which is NOT a ejb.Ejb (which is a j2ee.Describable).
> 
> The basic problem here is that we just can't implement both
> inheritance hierachies in java.   So my question is should we try?
> 
> Do we actually need concrete classes in the o.a.g.deployment.model.* packages?
> We will always be constructing o.a.g.deployment.model.geronimo.* instances
> so do we need classes like ejb.Ejb, as we will always create geronimo.ejb.Ejb?
> 
> 
> So I think that either
> 
> 0) there is some pattern that I am missing about which hierarchy to use?
> in which case we need to document what that is.
> 
> 1) we just don't bother with the o.a.g.deployment.model.* versions
> 
> 2) We make the o.a.g.deployment.model.* versions interfaces so that we
> can multiply inherit them
> 
> 
> 1) is simpler and type safe, but does not indicate what is standard and
> what is not.
> 
> I think 2) should work ok and we would end up with things like:
> 
>    class Entity extends Ejb
>      implements o.a.g.deployment.model.ejb.Entity
>    {
>       ...
>    }
> 
> The main problem with this approach is that methods like
> getEjbRef() will return a o.a.g.deployment.model.ejb.Ejb[]
> and we will have to cast to o.a.g.deployment.model.geronimo.ejb.Ejb
> in order to get the geronimo specific methods.
> 
> Alternately we could double up the methods (which we have done anyway):
> 
>    class Ejb extends Entity implements o.a.g.d.m.ejb.Ejb
>    {
>       EjbRef[] ejbRef;
> 
>       EjbRef[] getGeronimoEjbRef() {
>          return ejbRef;
>       }
> 
>       o.a.g.d.m.ejb.EjbRef getEjbRef() {
>          return ejbRef;
>       }
>       ...
>    }
> 
> Let's call this option 2a)
> 
> Or we could we could just do 1):
> 
>    class Ejb extends Entity
>    {
>       EjbRef[] ejbRef;
> 
>       EjbRef[] getEjbRef() {
>          return ejbRef;
>       }
> 
>       ...
>    }
> 
> 
> I'm a bit cautious about starting to fix this as I'm unclear about
> exactly what XML tools we are intending to eventually use and what
> conventions they require of the POJOs. I'm guessing we still have no tools
> set selected, so we should be able to do anything?
> 
> In which case, I propose that we/I start working towards 2).
> This can be easily extended to 2a) or 1) if we decide we want more type
> safety and less casting.   I think 2a) is probably the best compromise
> between having a standards structure and vendor type safety.
> 
> There are also a few naming convention problems that need to be
> fixed (we have both EjbRef and EJBRef and some field names EJBRef instead
> of ejbRef). I'll start fixing these while we decide what to do about the
> rest of this.
> 
> cheers
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>