You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by is_maximum <mn...@gmail.com> on 2009/03/04 09:02:40 UTC
regarding StoreListener
Hi
First I don't know why there is no useful document on these sort of
listeners and how to use it.
Second after toiling I was able to find dirty fields and fire the pre-update
event. This is for a logging service we have to implement for our
application but now the problem is that if you want to listen to an
store-event (pre-update, pre-delete ...) you need to cast the em into
openjpa-em and then add your listener to it. First I did it in
@PostConstruct callback method but soon I found that this method will be
called once each time the container instantiate my stateless so after that
the listener won't work at all.
now I have implemented some save() update() and delete() method as DAO
interface and before each method I add this listener to.
The problem is that I think this way of adding listeners is not correct.
I've already used Hibernate and they have a simple XML file in which you can
simply define your desired listeners and they are guaranteed to work each
time a CRUD operation being applied
Is there anythink like that in OpenJPA or Do we need to open an issue in
JIRA and request such feature?
thanks
--
View this message in context: http://n2.nabble.com/regarding-StoreListener-tp2420847p2420847.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: regarding StoreListener
Posted by Michael Dick <mi...@gmail.com>.
The same code should work. The callback methods for an EntityListener class
take an Object as an input parameter. That Object should be the same as the
one passed in on the StoreListener when you called getRelated().
-mike
On Wed, Mar 4, 2009 at 2:14 PM, is_maximum <mn...@gmail.com> wrote:
>
> Well so we can define a listener for all the entities.
>
> that's pretty good but one more question is that if we use these entity
> listeners, can we still find out those fields that has been changed (dirty
> fields) for example in pre-update and persist the result in DB. As far as I
> know, inside the callback methods the context has been closed so you can't
> access the entity manager so we have to get it in a way to persist the
> result. Can we place the codes we are using in StoreListener inside the
> callback methods without any problem?
>
>
>
> Michael Dick wrote:
> >
> > Hi,
> >
> > I think I understand your concern. You're looking for a default set of
> > listeners which apply to all your entities. This is also supported by the
> > JPA specification. Relevant section :
> > 3.5.7.2 Specification of the Binding of Entity Listener Classes to
> > Entities
> > The entity-listeners subelement of the persistence-unit-defaults element
> > is
> > used to
> > specify the default entity listeners for the persistence unit.
> >
> > Here's an example from one of our unit tests :
> > <entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm
> > http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
> > version="1.0">
> > <persistence-unit-metadata>
> > <persistence-unit-defaults>
> > <entity-listeners>
> > <entity-listener
> >
> class="org.apache.openjpa.persistence.annotations.common.apps.annotApp.ddtype.DefaultCallbackListener">
> > <pre-persist method-name="prePersist" />
> > <post-persist method-name="postPersist" />
> > <pre-remove method-name="preRemove" />
> > <post-remove method-name="postRemove" />
> > <pre-update method-name="preUpdate" />
> > <post-update method-name="postUpdate" />
> > <post-load method-name="postLoad" />
> > </entity-listener>
> > </entity-listeners>
> > </persistence-unit-defaults>
> > </persistence-unit-metadata>
> > . . .
> >
> > Is that more what you're looking for?
> >
> > -mike
> >
> >
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/regarding-StoreListener-tp2420847p2425189.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: regarding StoreListener
Posted by is_maximum <mn...@gmail.com>.
Well so we can define a listener for all the entities.
that's pretty good but one more question is that if we use these entity
listeners, can we still find out those fields that has been changed (dirty
fields) for example in pre-update and persist the result in DB. As far as I
know, inside the callback methods the context has been closed so you can't
access the entity manager so we have to get it in a way to persist the
result. Can we place the codes we are using in StoreListener inside the
callback methods without any problem?
Michael Dick wrote:
>
> Hi,
>
> I think I understand your concern. You're looking for a default set of
> listeners which apply to all your entities. This is also supported by the
> JPA specification. Relevant section :
> 3.5.7.2 Specification of the Binding of Entity Listener Classes to
> Entities
> The entity-listeners subelement of the persistence-unit-defaults element
> is
> used to
> specify the default entity listeners for the persistence unit.
>
> Here's an example from one of our unit tests :
> <entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm
> http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
> version="1.0">
> <persistence-unit-metadata>
> <persistence-unit-defaults>
> <entity-listeners>
> <entity-listener
> class="org.apache.openjpa.persistence.annotations.common.apps.annotApp.ddtype.DefaultCallbackListener">
> <pre-persist method-name="prePersist" />
> <post-persist method-name="postPersist" />
> <pre-remove method-name="preRemove" />
> <post-remove method-name="postRemove" />
> <pre-update method-name="preUpdate" />
> <post-update method-name="postUpdate" />
> <post-load method-name="postLoad" />
> </entity-listener>
> </entity-listeners>
> </persistence-unit-defaults>
> </persistence-unit-metadata>
> . . .
>
> Is that more what you're looking for?
>
> -mike
>
>
>
>
--
View this message in context: http://n2.nabble.com/regarding-StoreListener-tp2420847p2425189.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: regarding StoreListener
Posted by Michael Dick <mi...@gmail.com>.
Hi,
I think I understand your concern. You're looking for a default set of
listeners which apply to all your entities. This is also supported by the
JPA specification. Relevant section :
3.5.7.2 Specification of the Binding of Entity Listener Classes to Entities
The entity-listeners subelement of the persistence-unit-defaults element is
used to
specify the default entity listeners for the persistence unit.
Here's an example from one of our unit tests :
<entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm
http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
version="1.0">
<persistence-unit-metadata>
<persistence-unit-defaults>
<entity-listeners>
<entity-listener
class="org.apache.openjpa.persistence.annotations.common.apps.annotApp.ddtype.DefaultCallbackListener">
<pre-persist method-name="prePersist" />
<post-persist method-name="postPersist" />
<pre-remove method-name="preRemove" />
<post-remove method-name="postRemove" />
<pre-update method-name="preUpdate" />
<post-update method-name="postUpdate" />
<post-load method-name="postLoad" />
</entity-listener>
</entity-listeners>
</persistence-unit-defaults>
</persistence-unit-metadata>
. . .
Is that more what you're looking for?
-mike
On Wed, Mar 4, 2009 at 1:02 PM, is_maximum <mn...@gmail.com> wrote:
>
> Hi Michael,
>
> As far as I know these are entity listener and we have to declare our
> listener for each entity and I think this is not a good idea. consider that
> we have nearly 30 entities and it may be added in the future we don't like
> to declare a listener for each pre-update, pre-remove and pre-persist,
> instead we need a listener just like StoreListener in OpenJPA in which we
> are notified by any changes in any entity and then we can find dirty fields
> and old/new values so we can save the history of any changes. Keeping this
> history is inevitable and very important to our customers
>
> Now the StoreListener I already stated works fine but the problem is that
> before any invocation of one of merge(), delete() and persist() of
> EntityManager we have to add this listener to the EM and I think this is a
> bit messy and not a good idea. Sorry maybe because of my poor English you
> could not understand me very well if so ask me to put the snippet code here
> to clarify everything. Now I'm at home but tomorrow I will post the code.
>
> Thanks
>
>
> Michael Dick wrote:
> >
> > Hi,
> >
> > The JPA specification defines several listeners which can be configured
> > via
> > orm.xml or annotations in your entity classes. Here's a quick view of the
> > available listeners :
> > The following annotations are defined to designate lifecycle event
> > callback
> > methods of the corresponding
> > types.
> > • PrePersist
> > • PostPersist
> > • PreRemove
> > • PostRemove
> > • PreUpdate
> > • PostUpdate
> > • PostLoad
> >
> > Section 3.5 of the JPA 1.0 specification covers how these listeners are
> > used
> > in more detail.
> >
> > Do you need a listener for any other lifecycle event for your entity, or
> > does this cover everything you need?
> >
> > -mike
> >
> > On Wed, Mar 4, 2009 at 2:02 AM, is_maximum <mn...@gmail.com> wrote:
> >
> >>
> >> Hi
> >>
> >> First I don't know why there is no useful document on these sort of
> >> listeners and how to use it.
> >>
> >> Second after toiling I was able to find dirty fields and fire the
> >> pre-update
> >> event. This is for a logging service we have to implement for our
> >> application but now the problem is that if you want to listen to an
> >> store-event (pre-update, pre-delete ...) you need to cast the em into
> >> openjpa-em and then add your listener to it. First I did it in
> >> @PostConstruct callback method but soon I found that this method will be
> >> called once each time the container instantiate my stateless so after
> >> that
> >> the listener won't work at all.
> >>
> >> now I have implemented some save() update() and delete() method as DAO
> >> interface and before each method I add this listener to.
> >>
> >> The problem is that I think this way of adding listeners is not correct.
> >> I've already used Hibernate and they have a simple XML file in which you
> >> can
> >> simply define your desired listeners and they are guaranteed to work
> each
> >> time a CRUD operation being applied
> >> Is there anythink like that in OpenJPA or Do we need to open an issue in
> >> JIRA and request such feature?
> >>
> >> thanks
> >> --
> >> View this message in context:
> >> http://n2.nabble.com/regarding-StoreListener-tp2420847p2420847.html
> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/regarding-StoreListener-tp2420847p2424814.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: regarding StoreListener
Posted by is_maximum <mn...@gmail.com>.
Hi Michael,
As far as I know these are entity listener and we have to declare our
listener for each entity and I think this is not a good idea. consider that
we have nearly 30 entities and it may be added in the future we don't like
to declare a listener for each pre-update, pre-remove and pre-persist,
instead we need a listener just like StoreListener in OpenJPA in which we
are notified by any changes in any entity and then we can find dirty fields
and old/new values so we can save the history of any changes. Keeping this
history is inevitable and very important to our customers
Now the StoreListener I already stated works fine but the problem is that
before any invocation of one of merge(), delete() and persist() of
EntityManager we have to add this listener to the EM and I think this is a
bit messy and not a good idea. Sorry maybe because of my poor English you
could not understand me very well if so ask me to put the snippet code here
to clarify everything. Now I'm at home but tomorrow I will post the code.
Thanks
Michael Dick wrote:
>
> Hi,
>
> The JPA specification defines several listeners which can be configured
> via
> orm.xml or annotations in your entity classes. Here's a quick view of the
> available listeners :
> The following annotations are defined to designate lifecycle event
> callback
> methods of the corresponding
> types.
> • PrePersist
> • PostPersist
> • PreRemove
> • PostRemove
> • PreUpdate
> • PostUpdate
> • PostLoad
>
> Section 3.5 of the JPA 1.0 specification covers how these listeners are
> used
> in more detail.
>
> Do you need a listener for any other lifecycle event for your entity, or
> does this cover everything you need?
>
> -mike
>
> On Wed, Mar 4, 2009 at 2:02 AM, is_maximum <mn...@gmail.com> wrote:
>
>>
>> Hi
>>
>> First I don't know why there is no useful document on these sort of
>> listeners and how to use it.
>>
>> Second after toiling I was able to find dirty fields and fire the
>> pre-update
>> event. This is for a logging service we have to implement for our
>> application but now the problem is that if you want to listen to an
>> store-event (pre-update, pre-delete ...) you need to cast the em into
>> openjpa-em and then add your listener to it. First I did it in
>> @PostConstruct callback method but soon I found that this method will be
>> called once each time the container instantiate my stateless so after
>> that
>> the listener won't work at all.
>>
>> now I have implemented some save() update() and delete() method as DAO
>> interface and before each method I add this listener to.
>>
>> The problem is that I think this way of adding listeners is not correct.
>> I've already used Hibernate and they have a simple XML file in which you
>> can
>> simply define your desired listeners and they are guaranteed to work each
>> time a CRUD operation being applied
>> Is there anythink like that in OpenJPA or Do we need to open an issue in
>> JIRA and request such feature?
>>
>> thanks
>> --
>> View this message in context:
>> http://n2.nabble.com/regarding-StoreListener-tp2420847p2420847.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/regarding-StoreListener-tp2420847p2424814.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: regarding StoreListener
Posted by Michael Dick <mi...@gmail.com>.
Hi,
The JPA specification defines several listeners which can be configured via
orm.xml or annotations in your entity classes. Here's a quick view of the
available listeners :
The following annotations are defined to designate lifecycle event callback
methods of the corresponding
types.
• PrePersist
• PostPersist
• PreRemove
• PostRemove
• PreUpdate
• PostUpdate
• PostLoad
Section 3.5 of the JPA 1.0 specification covers how these listeners are used
in more detail.
Do you need a listener for any other lifecycle event for your entity, or
does this cover everything you need?
-mike
On Wed, Mar 4, 2009 at 2:02 AM, is_maximum <mn...@gmail.com> wrote:
>
> Hi
>
> First I don't know why there is no useful document on these sort of
> listeners and how to use it.
>
> Second after toiling I was able to find dirty fields and fire the
> pre-update
> event. This is for a logging service we have to implement for our
> application but now the problem is that if you want to listen to an
> store-event (pre-update, pre-delete ...) you need to cast the em into
> openjpa-em and then add your listener to it. First I did it in
> @PostConstruct callback method but soon I found that this method will be
> called once each time the container instantiate my stateless so after that
> the listener won't work at all.
>
> now I have implemented some save() update() and delete() method as DAO
> interface and before each method I add this listener to.
>
> The problem is that I think this way of adding listeners is not correct.
> I've already used Hibernate and they have a simple XML file in which you
> can
> simply define your desired listeners and they are guaranteed to work each
> time a CRUD operation being applied
> Is there anythink like that in OpenJPA or Do we need to open an issue in
> JIRA and request such feature?
>
> thanks
> --
> View this message in context:
> http://n2.nabble.com/regarding-StoreListener-tp2420847p2420847.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>