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 Tue, 09 Sep 2003 07:02:47 GMT

Jeremy Boynes wrote:
 > I think a concrete class hierarchy is easiest here, with the Geronimo
 > POJOs extending the Standard ones. That way tools can work with standard
 > objects or geronimo objects as they like (provided they remain
 > consistent) - this fits Aaron's use cases and I think simplifies the
 > structure.

That approach is going to result in some really ugly duplication
of code and hundreds of extra implementation methods.

For example, the current implementation of o.a.g.d.m.g.ejb.MessageDriven is

   public class MessageDriven extends Ejb {

Which is good, except that it does not implement/extend the standard EJB or
MessageDriven classes. So this is not a unified POJO tree. I'm proposing that
we change this to:

   public class MessageDriven extends Ejb
                              implements o.a.g.d.m.ejb.MessageDriven

and remove the implementations from o.a.g.d.m.ejb.*.  This is
simple and reduces our code volume.   At the cost that we have
to use the geronimo instances of the POJOS (but can do so via
the standard interfaces if we wish).

If somebody really wants a non-geronimo version of the standard
interfaces, then we can provide implementations of them.

I think that what Jeremy & Aaron are proposing is that we change this to

   public class MessageDriven extends o.a.g.d.m.ejb.MessageDriven
      // reimplement all the array getters/setter & instance getter/setter for
      //   EjbRef
      //   ResourceRef
      //   ServiceRef
      //   EjbLocalRef
      //   JndiContextParam
      //   MessageDesination
      //   ResourceEnvRef
      //   SecurityRoleRef
      //   etc.
      // to use geronimo object.

      // reimplement them all again for type safe versions.

So that's at least 64 methods that need to be reimplemented.
And we can't reuse those implementations in Entity or Session, so
we have to reimplement them all over again -that's > 186 trivial methods
that we have cut and pasted by hand!!!

This can be simplified, if we don't reimplement the standard methods
and just store geronimo types in the base class arrays and fields.
But :
  - we lose type safety (one of the reasons to use POJOs)
  - the risk of having mixed trees is large
  - we will have to write copy constructors for everything so we can
    convert between standard trees and geronimo trees
  - we have to have lots of explicit type checking and casting.
  - if we add type safe methods, they will have to copy arrays
  - We still have to have type safe impls replicated in Entity, MessageDriven
    and Session.

> You had originally proposed additional methods like getGeronimoEjbRef()
> - what was wrong with them (apart from the name)? A user can use those
> or can cast the result from getEJBRef().

Because either we reimplement hundreds of methods or we end up
copying arrays every time the type safe methods are called.

> Have we made any progress on the names?

I've decided that progress is highly overrated and that I much prefer
to write long ranting emails:-) Sorry guys, but I am having trouble getting
into the "apache way" here.   I don't want to do anything without consensus,
but I appear unable to reach consensus with anybody about anything  - even
the neighbours cat is disagreeing with me about who is meant to feed it !-)

I did start the refactoring, but there is some code that relies
on the fact that EJB* comes from one package and Ejb* come from another.
So renaming all to EJB gives name clashes that need to be resolved
with package names.  This is a lot of code to change and I would prefer
to remove most of it (as above) rather than fix it.  So either we
need to reach consensus on the above or I have to stop worrying about it :-)


>>-----Original Message-----
>>From: Gmane Remailer [mailto:public=SUao4/] On Behalf

>>Of Greg Wilkins
>>Sent: Monday, September 08, 2003 8:11 PM
>>Subject: Re: [XML][Deployment]POJO design?
>>I tried to let this one go... but I can't... one more try :-)
>>Aaron Mulder wrote:
>>>>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 etc.
>>>	Yes, I'm saying skip the geronimo.ejb.EJB.  It would 
>>currently have 
>>>no properties beyond what ejb.EJB has, and later would support only 
>>>the most basic (pool size perhaps?).
>>But that does not work, because geronimo.ejb.EJB is need to 
>>provide implementation of all the standard methods that 
>>return the geronimo specific versions of EJBRef etc.
>>If we don't have geronimo.ejb.EJB, then we have to implement 
>>most the methods in most of the classes.
>>>>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 getters.
>>>	That is clearly unacceptable.  You say above that I can use the
>>>J2EE interfaces to edit J2EE DDs, and below that the J2EE 
>>interfaces have 
>>>no setters.
>>Why?  We are writing geronimo code, so what it the problem with
>>creating geronimo versions of the DD POJOs?   If you don't want to
>>do anything with the non-standard elements then don't set 
>>them and don't render them in the XML.
>>Note that jeremies current proposal has no difference between 
>>the standard and vendor DD's anyway!
>>>	But that aside, I still disagree with this approach.  
>>You're adding a 
>>>whole lot of complexity and baggage to save yourself the writing of 
>>>getJndiName in more than one place.  This is silly.  Of the 
>>>that need to go in the Geronimo classes, about 5% would go 
>>in "EJB", 
>>>as opposed to 95% in "Session", "Entity", or 
>>"MessageDriven".  If you 
>>>just leave out geronimo.ejb.EJB, then all these problems go away.
>>No - the reason that the geronomo classes exist is to provide 
>>typed versions of the methods, so you don't have to cast to 
>>the geronimo specific instances all the time. If we are happy 
>>with untyped interfaces - then let's just use DOM!
>>I think my proposal is actually removing code and complexity. 
>> We will only have concrete implementations for of geronimo 
>>objects. There will be no standards only implementations, no 
>>copy constructors to convert standard to geronimo, no 
>>casting, no type checking before casting, no marshalling code 
>>for standard only, etc.
>>I am sure that we could get by without a standard version of 
>>the DD POJOs and only use the G DD POJOs. But having the 
>>standard interfaces is less code that we have already and at 
>>least gives a good indication of what's standard and what's not.
>>It seams bizarre to me that on one hand we are trying to 
>>merge the standard and vender XML into a single file, but on 
>>the other we are keeping separate implementations of the 
>>elements as POJOs???

View raw message