> 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.
Yes, we were actually discussing it with Rickard, when Juha posted it.
We all seem to be reaching the simplest conclusion, but at what price?
I am waiting for feedback from Rickard on this but +1, I will code it.
marc
>
> 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 -------
>
>
