Aaron,
I don't think my proposed approach was adding anything? The classes all exist anyway, I'm just proposing moving the implementations about a bit and cleaning up the inheritance tree so that extend is used for geronimo classes and implement is used for standards interfaces. It think it would have resulted in less code.
I find the current setup very confusing and it does not feel like a unified standard+vendor structure to me. But it does not really effect me much, as the web container POJOs are mostly standard anyway. So if we are happy with it, I'll leave it alone.
cheers
Aaron Mulder wrote:
On Tue, 9 Sep 2003, Greg Wilkins wrote:
...Displayable->ejb.Ejb->ejb.RpcBean->ejb.Session->geronimo.ejb.Session
But geronimo.ejb.Session should extend geronimo.ejb.EJB
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?). geronimo.ejb.RpcBean, if it existed, would have a JndiName. You're introducing an awful lot to avoid writing a very few properties in both Session and Entity -- it's really not worth it.
I don't know if that works as well as making the standard ones interfaces. If the standard elements are interfaces, then I think we can implement the POJOs with only a single implementation of every method. If the standard elements are POJOs then we are going to have to do multiple implementations methods on geronimo.ejb.EJB etc.
I'm not sure I agree. Some classes have a description only. Some have a display name only. Others have a display name and a description. How can you have a single implementation of getDescription and getDisplayName?
There should be no problem generating the standard J2EE DDs using the geronimo POJOs. You should be able to use the geronomo instances via the standard interfaces and thus you will not know about the extra geronimo methods unless you want to.
Perhaps, but it seems like a bit of a runaround. If someone can edit both the J2EE and Geronimo DDs separately, then we have two complete Geronimo DD trees in memory? I don't think this is better.
So I still favour making the standard beans the interfaces. Just to be clear, here is the code snippets that I'm proposing again.
(code omitted)
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.
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.
Aaron
