2013-02-28 12 views
6

Ho una classe JPA @Entity che usa @PrePersist da un po 'di tempo. Oggi volevo aggiungere alcune funzionalità in cui ho bisogno dell'ID di quell'entità. Questo ID viene generato durante la permanenza di un HIBERNATE_SEQUENCE nel database. Di solito è impostato dopo em.persist (entità).@PostPersist non chiamato ... @PrePersist è ... perché?

Per qualche ragione sconosciuta il metodo @PrePersist viene attivato ... mentre @PostPersist semplicemente mai spara:

@Entity 
public class MyEntity { 

    @PrePersist 
    protected void onCreate() { 
     System.out.println("ExtendedEntity.onCreate()"); 
    } 

    @PostPersist 
    protected void afterCreate() { 
     System.out.println("ExtendedEntity.afterCreate()"); 
    } 
} 

sto usando un ambiente v4.2 JBoss con Java v7 +, Hibernate v3.3.1.GA e Seam v2.2.2.Final ...

Esistono requisiti nascosti per l'attivazione di @PostPersist?

+0

Pensare a voce alta ... org.hibernate.event.PostInsertEventListener interferisce con JPA? –

+1

Interferisce ... vedi la mia risposta. –

risposta

8

Per tutti gli altri ... Gli ascoltatori di eventi in sospensione sembrano interferire con gli eventi di persistenza JPA ... dopo aver rimosso le seguenti righe dal mio persistence.xml viene attivato il callback @PostPersist.

<property name="hibernate.ejb.event.pre-insert" value="my.hibernate.events.listeners.Listener" /> 
<property name="hibernate.ejb.event.pre-update" value="my.hibernate.events.listeners.Listener" /> 
<property name="hibernate.ejb.event.pre-delete" value="my.hibernate.events.listeners.Listener" /> 
<property name="hibernate.ejb.event.post-insert" value="my.hibernate.events.listeners.Listener" /> 
<property name="hibernate.ejb.event.post-update" value="my.hibernate.events.listeners.Listener" /> 
<property name="hibernate.ejb.event.post-delete" value="my.hibernate.events.listeners.Listener" /> 

Non li usiamo più ... non sono mai stati completamente disattivati.

+0

Per i posteri, è perché Hibernate implementa effettivamente i suoi callback JPA tramite i suoi ascoltatori. Quindi, piuttosto che sovrascrivere gli ascoltatori, vorresti assicurarti di aggiungere gli ascoltatori; in questo modo entrambi possono coesistere (gli ascoltatori per tipo sono impilati). –

+0

Quindi le mie impostazioni disabilitano gli ascoltatori di Hibernate che utilizza per i callback JPA? Ricorda ... @PrePersist ha ancora funzionato con le voci sopra. I callback JPA dovrebbero funzionare indipendentemente dal fatto che io usi queste impostazioni o meno. –

+1

Forse. Non in disaccordo. Sto solo spiegando cosa è successo. Abbiamo zero richieste di miglioramento per consentire ai callback JPA e ai listener di eventi di Hibernate di lavorare insieme. Comunque sia, in realtà possono, semplicemente non usare questo modo di configurazione del listener basato su XML (che ora è deprecato comunque). –

0

Credo che venga chiamato durante un commit o un flush. Stai chiamando esplicitamente uno di questi? Quello che mi sto chiedendo è che forse c'è un ritardo da quando il gestore delle entità sta effettivamente persistendo nel database. Ad esempio, le transazioni potrebbero non essere impegnate fino a dopo la scrittura della risposta (nelle app Web).

Inoltre, provare a utilizzare un registratore, possono accadere cose strane quando si chiama standard fuori dalle applicazioni web.

+0

STDOUT era solo temporaneo ... sto usando Log4J normalmente. Un flush manuale() non ha modificato nulla ... vedi la mia risposta. –

+0

Bello ... non hai detto che avevi impostato gli ascoltatori di eventi in ibernazione nella tua domanda. –

+0

Non ho pensato nemmeno a questi ... Non li ho usati per molto tempo ma ho mantenuto una semplice classe di logger configurata. –

Problemi correlati