geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject [XML][Deployment]POJO design?
Date Mon, 08 Sep 2003 14:08:05 GMT

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














Mime
View raw message