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