> >Finally I would like to say that activate still reaches the store (even
> >though it is pure EJB) to allow for the context setting by the
> plugin (jaws
> >uses it for smart updates) so that it is a good place to do it.
>
> Sorry to respond to this a month later - all this happened while I was
> on holiday, and I'm still catching up on mail from that time.
>
> What currently happens in JAWS on activate is that it creates a *new*
> (and empty) persistence context. This is not the right thing to do!
right let's fix that (if it is still the case, there was a silly bug in
tuned updates)...
> Passivation should save the persistence context, and activation should
> restore it. Then the calls relating to activation and passivation
> wouldn't need to come to JAWS. (Alternatively, we should get rid of the
> persistence context. It is only used for 'tuned' updates and 'read only'
> entities, neither of which is required by the EJB spec. I'm all for
> keeping things simple until they are working properly...)
hummmm tuned updates is good... we fixed a bug (sebastien) to get it working
properly.
Activation and passivation imho needs to reach the store since you deal with
your information accordingly. If the activation in jaws doesn't set the
stuff correctly then that should be fixed.
>
> The fundamental problem here is that if the bean context is extensible,
> the passivation/activation mechanisms must recognise any extension.
which is why it should be done by jaws and not the container or the manager
(PersistenceManager).. this is "store" specific, not "manager" specific.
marc
