>Root problem is the standard "I want to record who changed an object"
issue.
Did you try prepersist?
Here is comment from Marina that nicely describes what is going on
/
As you can see from the stack trace, PreUpdate is called during commit,
which
means there is no component invocation any longer. Most probably
PrePersist is
called at some earlier time (like a query execution that causes a flush
to the
database).
/
On 4/19/2012 1:07 PM, Laird Nelson wrote:
> Looking at http://java.net/jira/browse/GLASSFISH-6872 (which was
> fixed/closed a while back) reminded me of a problem we've had.
>
> We have an entity listener that does an explicit JNDI lookup to see if
> there's an EJBContext available. I was led to believe that there
> would be by the last paragraph of the JPA 2.0 specification (section 3.5):
>
> When invoked from within a Java EE environment, the callback listeners
> for an entity share the enterprise naming context of the invoking
> component, and the entity callback methods are invoked in the
> transaction and security contexts of the calling component at the time
> at which the callback method is invoked.
>
> But the final evaluation of the bug report seems (at least to my
> reading) to contradict this.
>
> So is it indeed the case that when an entity listener is kicked off
> during an invocation of an EJB--is it indeed the case that this entity
> listener, despite sharing the "enterprise naming context of the
> invoking component" which is an EJB in this case, cannot look up the
> EJBContext in that context?
>
> Root problem is the standard "I want to record who changed an object"
> issue.
>
> Thanks,
> Laird
>
> --
> http://about.me/lairdnelson
>