Christ...
you guys sort it out and I will code it, ok?
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dan OConnor
> Sent: Tuesday, July 11, 2000 7:25 AM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] setEJBObject
>
>
> On 11 Jul 00, at 8:36, Rickard �berg wrote:
>
> > Agree, with the addition that I have changed my mind and would rather go
> > with Marc's suggestion to put this code in EntityContainer. Since there
> > is (AFAICT) only one way to implement these callbacks it doesn't seem
> > necessary to have it in a separate place, which would introduce more
> > complexity to the code.
>
> Hi Rickard,
>
> I wanted to suggest a couple of examples where the three-layer
> solution would be useful (entity container->persistence manager-
> >object/relational mapper).
>
> 1. Although for the most part, the callback methods must be
> invoked according to the specification's finite state machine, the
> invocations of ejbLoad and ejbStore are flexible, and policy
> decisions might be made. An example of this in the current code
> is the "read-only" test, where a request to load an object's state is
> ignored unless a certain amount of time has passed, and a request
> to store an object's state is always ignored. These policy
> decisions shouldn't be in the entity container, but apply equally to
> all object/relational mapping schemes.
>
> 2. A particular persistence-management scheme may require
> additional private callbacks that are not part of the specification.
> An example of this might be an implementation of EJB 1.1 CMP
> that wants to wrap collection classes to provide lazy loading and
> tuned updates of dependent objects after the invocation of
> ejbPostCreate (the first point at which the object's identity is
> available) but before the invocation of any business methods.
> These invocations shouldn't be hard-coded to the entity container,
> since they are not generally applicable.
>
> 3. It's possible that users of the jBoss container may desire non-
> compliant optimizations that would require changing the callbacks.
> For instance, they may want us to check an "is-modified" method
> for BMP beans, and not call ejbStore if it returns false. This is not
> compliant, but what can you do if your fans are screaming for it? :-)
>
> Rickard, you have a better sense of the trade-offs involved in
> factoring out a third layer of code (rather than the two you are
> currently advocating). I'd appreciate your feedback--are these
> points worth considering, or is code simplicity the overriding value
> in this particular case?
>
> -Dan
>
>
> >
> > There are a few places that needs to be changed:
> > * For create the EntityContainer should do ejbCreate, and handle the BMP
> > and CMP cases differently. Then call PM (which may be an O/R mapper),
> > then call ejbPostCreate. The EntityContainer should be responsible for
> > hooking up the instance with a EJBObject from the ContainerInvoker
> > before returning.
> > * For finders the PM should be responsible for returning one or more
> > primary keys. Again, the EntityContainer hooks up these with EJBObjects
> > before returning
> > * Two methods, activate() and passivate() should be added to
> > EntityContainer (and StatefulSessionContainer) which call the PM and
> > then ejbActivate, and ejbPassivate and the PM (respectively). The caches
> > should be changed to call the EntityContainer to ask for
> > activation/passivation instead of calling the PM directly.
> >
> > I think this should be enough. This would provide a good refactoring of
> > the code, and will make it easier and less error-prone to code PM's.
> >
> > Thanks to Marc and Juha for catching this and providing an interesting
> > (although a bit heated) discussion on the subject.
> >
> > Sounds ok? Marc, if you agree (and I think you do), can you please make
> > the above changes?
> >
> > regards,
> > Rickard
> >
> > --
> > Rickard �berg
> >
> > @home: +46 13 177937
> > Email: [EMAIL PROTECTED]
> > http://www.telkel.com
> > http://www.jboss.org
> > http://www.dreambean.com
> >
>
>
>
>
