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