Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
From: "Jeremy Boynes" <jeremy@coredevelopers.net>
To: <geronimo-dev@incubator.apache.org>
Subject: RE: [XML][Deployment]POJO design?
Date: Mon, 8 Sep 2003 23:03:00 -0700
Message-ID: <001401c37698$05ebec80$b625a8c0@ABU>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3F5D44C7.1030801@mortbay.com>

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.

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().

Have we made any progress on the names?

Jeremy

> -----Original Message-----
> From: Gmane Remailer [mailto:public@main.gmane.org] On Behalf 
> Of Greg Wilkins
> Sent: Monday, September 08, 2003 8:11 PM
> To: 
> public-geronimo-dev=d1GL8uUpDdXTxqt0kkDzDmD2FQJk+8+b@ciao.gmane.org
> Subject: Re: [XML][Deployment]POJO design?
> 
> 
> 
> 
> sorry,
> 
> 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 
> properties 
> > 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???
> 
> cheers
> 
> 
> 
> 
> 
> 
>