geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: [XML][Deployment]POJO design?
Date Tue, 09 Sep 2003 22:48:27 GMT


Aaron,

Aaron Mulder wrote:
>>Eg. If we don't have a common geronimo.ejb.EJB class for Session, Entity
>>and Message, then we can't write any code that deals with these beans in
>>common - eg we are going to have to write the marshalling code 3 times, etc. etc.
> 
> 
> 	The only thing these classes have in common (currently) is the 
> content in (j2ee.)ejb.EJB!  And you can treat them in common in that way!  
> Then when you go to write the children (refs and so on), you'll have to 
> write a cast, but give me a break!!!

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.


> public void marshallGeronimoEjb(j2ee.ejb.EJB foo) {
>     marshallGeronimoEjbRef((GeronimoEJBRef[])foo.getEJBRef());
>     marshallGeronimoEnvEntry((GeronimoEnvEntry[])foo.getEnvEntry());
>     ...
> }

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.


> public void marshallGeronimoEjbRef(GeronimoEjbRef[] foo) {
>     ...
> }
> 
> 	Apparently, you even proposed adding some getters to do the cast 
> for you, so even that goes away.  I really don't see what your issue is.

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.

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

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.

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.

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.


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?

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





Mime
View raw message