geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: [XML][Deployment]POJO design?
Date Wed, 10 Sep 2003 01:43:04 GMT
On Wed, 10 Sep 2003, Greg Wilkins wrote:
> They have a lot more in common.  Even for the standard methods (eg getEjbRef)
> they all need this to be a collection of geronimo EjbRefs rather than
> standard EjbRefs.

	I don't think they "need to be", though certainly it's handy to 
avoid casts.

> But that does not work, as foo.getEJBRef may be an array of standard
> EJBRefs.  It may contain geronimoEJBRef or it may not!  If we support
> both sets of concrete instances, then we will always need to check
> which has be passed before we attempt a downcast.

	This, I disagree with.  Who's ever going to build a tree of 
Geronimo objects and put non-Geronimo data in there?  When would you ever 
literally have an array of EJBRef, some of which were Geronimo ones and 
some of which were not?  This would be really dumb.  Either you're using 
the plain J2EE-only DD, or you're using the Geronimo DD.  If you mix, it's 
a bug.

> No - it is the other way around.  I'm proposing that we up-cast
> not down-cast.
> We only support concrete storage of arrays of geronimo Object.
> IF (and that is a big IF) we need to write code that does not know about
> geronimo, then we can cast that arrary to a standard array.  Up-casting
> is safe and can always be done.  Down casting is not safe and can't be
> done if the array or anything it contains is not a geronimo  instance.

	I don't see why we'd want to always create subclasses even when we 
don't want them (i.e. editing a J2EE DD).  That just seems wrong.

> But I also don't understand why you don't like my proposal?  It correctly
> provides both a standard and  geronimo hierarchy type hierarchy and
> I have demonstrated that it is less code.  I'm happy to do it so long as we
> have some concensus that it is at least not wrong (we don't all have to
> agree that it is 100% the best way).

	I haven't seen a demonstration that it is less code.  I maintain
that it's more code.  If you look at the patch that's in JIRA for my
proposal, I updated the existing classes for ejb-jar, enterprise-beans,
entity, session, and message-driven.  There are a total of 4 methods
across all of them (getJndiName and setJndiName on Entity and Session).  
How many methods do you propose putting in that same set of classes?  Is
it fewer than 4?  Or do all of them have fewer than 1 line?  Are the two
interfaces plus one implementation fewer than the one implementation plus
one subclass?  Where are the savings?

> My objection to your proposal remains that we need a common geronimo.ejb.EJB
> type, because many of the standard methods need to be extended to
> work with geronimo types (GeronimoEjbRefs etc.).  While these subtypes
> could be stored in the standard type array, I have enumerated a number
> of concerns with that approach which have not been addressed.

	What can I say?  I am not convinced by your concerns.  I don't
mean to be rude, I just don't mind a cast here or there, and if you want
to wrap the property with additional helper methods that do the cast for
you, you can even eliminate that.  If the only down side is that you have
to copy and paste some helper methods from Session to Entity, live with
it.  I don't see a huge maintenance issue because you have two helper
methods that read "return (GeronimoFoo[])super.getFoo();" (one in Entity,
one in Session)  These properties will *never* change.

> And the other view point being expressed is that maybe we don't need
> the standard only pojos at all.   I could easily convinced of that, but am
> happy to use interfaces if others really want the just the standard API.

	For everyone who isn't concerned with a JSR-88 tool that edits 
J2EE deployment descriptors, this is a valid point of view.  I am not a 
member of that group.

> This is a classic problem that we are trying to solve - that is why there
> are lots of chapters in patterns books about how to do this.  I really
> don't think we should ignore past experience and think that we can get
> by with a few casts.   We should either avoid the problem with just a
> single type hierarchy or adopt one of the standards solutions - which is
> going to involve interfaces for multiple typing.

	Please!  I can't seem to respond to this paragraph without being
rude.  Let me just say that I also don't find it compelling to say "there
are lots of chapters in patterns books about how to do this" and I'll
leave it at that.

> To futher this discussion, I think we need two questions answered:
> What exactly is the use case for having standard-only API for these classes?

	Tools that edit a standard-only DD.

> Given that there is a use-case for standard-only, why is a set of standard
> interfaces to the geronimo implementations insufficient?

	It is not insufficient, it is overkill.  Creating objects of the
wrong type and then upcasting them to purposely restrict yourself to a
subset of their available properties is not an advantage.


View raw message