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 :-)
cheers
-----Original Message-----
From: Gmane Remailer [mailto:public=SUao4/[EMAIL PROTECTED] On Behalf
Of Greg Wilkins
Sent: Monday, September 08, 2003 8:11 PM
To:
[EMAIL PROTECTED]
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
