This didn't get posted somehow.
-Dan
------- Forwarded message follows -------
From: Dan OConnor <[EMAIL PROTECTED]>
To: "jBoss Developer" <[EMAIL PROTECTED]>
Subject: RE: [jBoss-Dev] setEJBObject
Send reply to: [EMAIL PROTECTED]
Date sent: Mon, 10 Jul 2000 13:18:23 -0400
Hi Juha,
I think that your analysis of the situation is exactly right. Your
solution addresses both Rickard's concerns for pluggability of the
callback algorithms and Marc's observation that object/relational
mapping and EJB container callbacks are different domains and
should be handled by different plugins.
I think that it's hard to argue against the conceptual and practical
arguments for the three layers (entity container->persistence
manager->o/r mapper), rather than two (with the persistence
manager being combined with the o/r mapping--Rickard's original
code--or with the entity container--Marc's new code.)
Thanks for a clear, dispassionate view of the technical issues. +1.
-Dan
On 10 Jul 00, at 19:01, Juha Lindfors wrote:
>
> Would seem to me that the current implementation just suffers from mixing
> too many responsibilities into one class. We need to separate the different
> roles of a persistence manager and that of an O/R mapper behind two
> different interfaces.
>
> Currently the JAWSPersistenceManager does both the callbacks to the
> EntityContainer and deals with the JDBC calls to the database (this was how
> it worked before this weekend's changes anyhow). I believe marc is correct
> to point out that this is not a good solution since it leaves the
> responsibility of the callbacks to the O/R mapper plugin authors (that are
> required to have the knowledge of jBoss to be able to provide container
> management part as well). In addition, this leaves a door open for writing
> "bad" plugins that can fuck up the container by not doing the required
> calls or doing them in unexpected ways. I think we should attempt to
> isolate the plugins more in order to prevent this. Otherwise we might end
> up having to review all the possible persistence plugins to make sure they
> do work correctly.
>
> So we should provide an implementation of a PersistenceManager that does
> the callbacks to the container in correct places and that requests the
> services of the O/R mappers when needed. This would require us to define an
> interface for the O/R mappers to implement, thus separating the
> "management" part of doing the callbacks from the JDBC stuff of mapping
> objects to relational data. JAWS would be one such mapper and it would get
> its requests of service from jBoss PersistenceManager whenever it requires
> the operations. The same manager could also delegate the O/R services to
> other modules, such as Cocobase, when they too implement this yet to be
> named interface (basically doing a wrapper that implements it, and not
> having to know about the container callbacks).
>
> This would separate the JDBC calls from container calls and still maintain
> container's role as a mediator that receives callbacks from the plugins (or
> at least from the managers that make use of the plugins).
>
>
> Flame on.
>
> ----+
> C |
> o |
> n | +-------+
> t | | | +------+
> a | callback | | uses | |
> i |<-----------| PM |--------->| O/R |
> n | | | |mapper|
> e | | | | |
> r | +-------+ +______+
> ----+ |
>
> |
>
> |
> +-----------------------------
> | instance of JAWS, Cocobase, \
>
> | some other O/R mapper? |
> | |
> +------------------------------+
>
> -- Juha
>
>
>
> At 10:20 9.7.2000 -0700, you wrote:
> >
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> >> Sent: Sunday, July 09, 2000 8:59 AM
> >> To: jBoss Developer
> >> Subject: Re: [jBoss-Dev] setEJBObject
> >>
> >>
> >> marc fleury wrote:
> >> > to have JAWS (!) implement the ejbCreate and ejbPostCreate
> >> calls is silly.
> >>
> >> No, that is your opinion. My opinion is that it is the right way to do
> >> it.
> >
> >Rickard,
> >
> >It's not an opinion, it's a trivial fact.
> >
> >Container calls mixed jdbc calls in the same 3 lines is absurd.
> >
> >What are we going to do for the Cocobase integration? give them a map of all
> >the calls they need to implement? and the reason why? and a crash course on
> >the EJB representation in jboss2.0? so they can call the right setEJBObject
> >on the "EnterpriseEntityContext.java" in the wrapper for the instance? when
> >all they should do is generate the JDBC stuff?
> >
> >You really can't be serious, Rickard.
> >
> >> > If you want to do it in CMPPersistenceManager or
> >> BMPPersistenceManager, that
> >> > is fine and then we propagate the MetaData knowledge, but NOT JAWS!!!!!!
> >>
> >> Huh. Now you really confused me. JAWS *IS* a CMP persistence manager.
> >> You're saying that
> >> 1. It is ok to do it in a CMP persistence manager
> >> 2. It is not ok to do it in JAWS
> >>
> >> But since JAWS *IS* a persistence manager that doesn't make any sense.
> >
> >You are wasting my time, and everybodies time kid.
> >
> >I am saying
> >
> >1- JAWS the O/R Mapper right now is a spaghetti code of 2000 lines, with no
> >architecture whatsoever that on top of it does CONTAINER CALLS!!!!!!!
> >
> >2- JAWS does EJB container calls!!!!!!!!! *AND* JAWS does JDBC calls!!!!
> >
> >3- YOU MIX JDBC Generation and DEEP EJB CONTAINER CALLS!!!!!!
> >
> >4- Clear?
> >
> >Zha'ts all! what part don't you understand?
> >
> >Conclusion.
> >
> >To put container calls mixed with jdbc calls as it was in
> >JAWSPersistenceManager is not code, it's not an opinion, it's not "elegant
> >architecture", it's a mistake, pure and simple... and a trivial one at that
> >rickard! why are we EVEN discussing this sucky stuff? I'll tell you why?
> >
> >Where do we go from here.
> >
> >You coded about 30k lines of code. The basic architecture is great and I
> >think it will pay off in the long run.
> >
> >I have taken a big bet on you and your ideas rickard when I decided to scrap
> >a year of work to go straight to jboss2.0. I have worked hard to build a
> >group I think can make it happen. We decided to force the move for the
> >whole group to work on your codebase. BUT IF EACH TIME we fix something
> >silly in your codebase you spend 3 days arguing "trivial" points then we are
> >going NOWHERE. See you don't really intimidate me however a newcomer that
> >fixes that and then spends 3 days fighting with you is going to leave,
> >intimated and thinking "wow, this is not open source". It has been
> >happening already, you know it!
> >
> >There is ALOT of stuff that needs fixing, re-thinking, re-factoring,
> >de-bugging, re-architecting and sometimes plain implementing. When Aaron
> >fixed some of the metadata stuff you got all worried and started crying "put
> >it back!". I see a pattern here and I am trying to correct it. When people
> >change your code, since THIS IS OPEN SOURCE, it is normal, it is not a
> >personal insult, even if they are picking up poopoo and saying so. So relax
> >because it is going to happen a lot to you, let it go.
> >
> >
> >Marc
> >
> >>
> >> /Rickard
> >>
> >> --
> >> Rickard �berg
> >>
> >> @home: +46 13 177937
> >> Email: [EMAIL PROTECTED]
> >> http://www.telkel.com
> >> http://www.jboss.org
> >> http://www.dreambean.com
> >>
> >>
> >
> >
> >
>
>
------- End of forwarded message -------
