A quoi servent les Callbacks et les Entity Listeners ?

Version imprimable

04/05/2013, 16h27
naf87

A quoi servent les Callbacks et les Entity Listeners ?

Bonjour à tous,
Après avoir brièvement lu sur les Callbacks et les Entity Listeners, je pensais pouvoir auditer les opérations de manipulation de données (CRUD) de mon système. Mais au moment de me jeter à l’eau, je me rends compte qu’il n’est pas conseillé d’exécuter les méthodes du gestionnaire d’entité ou de l’objet Query dans ces méthodes (Bref, la spécification ne supporte pas cela) . Fort de ce constat, je me demande à quoi servent vraiment les callback et les entity listener ? Y-a-t ’il quelqu’un pour m’aider à voir clair ? Merci et bonne continuation à tous.
06/05/2013, 17h48
Philippe Bastiani

Effectivement... l'utilisation (et, l'utilité) des listeners dans JPA est assez limité puisque tu ne peux pas travailler avec l'entity manager :(

En se creusant la tête:
- auditing de tes entités
ou encore, le déclenchement d'évènements
- gestion des évènements CDI (mais, avec l'impossibilité d'injecter directement un bean CDI),
- gestion des messages via JMS,
- ...

a+
Philippe
06/05/2013, 20h41
ruscov

Personnellement j'utilise les listeners pour mettre automatiquement à jour certains champs de mes entity (lastmodified par exemple). Tu peux voir ça comme un trigger.
07/05/2013, 08h23
naf87

Là encore il y a une limitation. Il n'est pas possible de modifier les attributs relationnels de l'entité.
07/05/2013, 09h43
DevServlet

Citation:

Envoyé par naf87

Là encore il y a une limitation. Il n'est pas possible de modifier les attributs relationnels de l'entité.

Bonjour, peux tu développer ça? Les CallBack comme dit dans le précédent post doivent être considérés comme des triggers agissant sur tous les champs d'une entité (changement de valeur) avant sa persistence.Ils ont toute leur utilité pour garantir une certaine cohérence de la base de donnée avant toute transaction.Personnellement je n'ai pas encore eu besoin d'invoquer un em dans un Listener.Toutefois l'inconvenient que je peux trouver à ce mécanisme c'est un risque d'oubli lors d'une maintenance applicative (évolution, non report de correction de bug), le même inconvenient que je trouve aux mécanismes trigger.
07/05/2013, 11h18
naf87

Citation:

Là encore il y a une limitation. Il n'est pas possible de modifier les attributs relationnels de l'entité.

les attributs relationnels sont les attributs qui représente un ou plusieurs objet(s) d'une autre entité. Bref, le type de l'attribut est une Collection d'entité ou une entité. Et d'après la spécification (Si mon anglais est encore bon :mrgreen:), ce type d'attribut ne devrait pas être modifié dans les callbacks.

Et comme je l'ai dit dans mon tout premier post, je m'imaginais pouvoir renseigner ma table d'audit grâce aux callbacks. Étant donné qu'il y a des méthodes qui peuvent être exécutées avant et après la mise à jour, l'enregistrement et la suppression des données.

Citation:

Ils ont toute leur utilité pour garantir une certaine cohérence de la base de donnée avant toute transaction

Si le mot cohérence ici fait uniquement allusion à la validation des données, je dirais qu'il y a un mécanisme de validation définit par la jsr 303, que je trouve assez intéressant.
07/05/2013, 11h50
DevServlet

Citation:

Envoyé par naf87

les attributs relationnels sont les attributs qui représente un ou plusieurs objet(s) d'une autre entité. Bref, le type de l'attribut est une Collection d'entité ou une entité. Et d'après la spécification (Si mon anglais est encore bon :mrgreen:), ce type d'attribut ne devrait pas être modifié dans les callbacks.

C'est mal connaitre les listeners,pourquoi as tu besoin à partir d'un listener d'une entité en modifier une autre, si sur chaque entité tu peux définir un listener spécifique, qui va être automatiquement appelé derrière une propagation de modification par exemple.Encore une fois je ne vois pas trop l'interet d'un em dans les listener.
07/05/2013, 11h51
ruscov

Tu peux développer un peu plus ce que tu veux faire, peut-être qu'on pourra t'apporter une solution.
En fait je pense à Hibernate Envers qui permet de faire des audits.

Voici en substance ce que je voulais faire :

Exemple d'entité à auditer :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
@Entity
@EntityListeners(AuditEntityListener.class)
public class Produit extends Auditable implements Serializable {
    @Id
    private String numProd;
    private Integer pu;
    @Temporal(TemporalType.TIMESTAMP)
    private Date datecre;
 
 
    public Produit() {
 
    }
 
    @PrePersist
    @PreUpdate
    @PreRemove
    public void initValues(){
        entityName = "Produit";
        entityId = numProd;
    }
 
    public String getNumProd() {
        return numProd;
    }
 
    public void setNumProd(String numProd) {
        detailsAudit.put("numProd", new AuditValue(numProd, this.numProd));
        this.numProd = numProd;        
    }
 
    public Integer getPu() {
        return pu;
    }
 
    public void setPu(Integer pu) {
        detailsAudit.put("pu", new AuditValue(""+pu, ""+this.pu));
        this.pu = pu;
    }
 
    public Date getDatecre() {
        return datecre;
    }
 
    public void setDatecre(Date datecre) {
        detailsAudit.put("datecre", new AuditValue(""+datecre, ""+this.datecre));
        this.datecre = datecre;
    }
 
    //...
 
}

Le listener :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
public class AuditEntityListener {
    private EntityManager entityManager;
 
   public AuditEntityListener(){
       // lookup de l'entity manager déclaré dans un EJB
   }
 
    @PostUpdate
    public void auditUpdate(Auditable auditable){
        auditOperation(auditable, "UPDATE");
    }
 
    @PostRemove
    public void auditRemove(Auditable auditable){
        auditOperation(auditable, "REMOVE");
    }
 
    @PostPersist   
    public void auditPersist(Auditable auditable){
        auditOperation(auditable, "PERSIST");
    }
 
    private void auditOperation(Auditable auditable, String operation){        
        Audit audit = new Audit();
        ObjectUtils.copyProperties(audit,auditable);
        audit.setDateoperation(new Date());
        audit.setOperation(operation);
 
        entityManager.persist(audit);    
 
        //sauvegarde du détail
        for(String attribute : auditable.getDetailsAudit().keySet()){
            AuditValue value = auditable.getDetailsAudit().get(attribute);
            Detailsaudit detail = new Detailsaudit();
            detail.setFieldname(attribute);
            detail.setAudiId(audit.getId());
            detail.setNewlvalue(value.getNewValue());
            detail.setOdlvalue(value.getOldValue());
            entityManager.persist(detail);
        }
    }
}

l'entité Audit :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@Entity
public class Audit  implements Serializable {
    @Id
    @GeneratedValue(strategy= GenerationType.SEQUENCE)
    private int id;
    private String userid;
    private String operation;  
    @Temporal(TemporalType.TIMESTAMP)
    private Date dateoperation;
    private String entityname;
    private String entityid;
 
   // getter et setter    
}

La classe Auditable :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
public class Auditable {
    protected String entityName;
    @Enumerated(EnumType.STRING)
    protected OperationType operation;
    protected String userId;
    protected Date dateoperation;
    protected String entityId;
    protected Map<String,AuditValue> detailsAudit;
 
    {
        detailsAudit = new HashMap<String, AuditValue>();
    }
 
  // getter et setter      
}

la classe AuditValue

Code:

1
2
3
4
5
6
7
8
9
10
11
12
public class AuditValue {
    private String newValue;
    private String oldValue;
 
    public AuditValue(){}
 
    public AuditValue(String newValue, String oldValue){
        this.newValue = newValue;
        this.oldValue = oldValue;
    }
   //getter et setter
}

et l'entité Detailsaudit :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
@Entity
public class Detailsaudit implements Serializable {
    @Id
    private int id;
    private int audiId;
    private String fieldname;
    @Column(length=1000)
    private String odlvalue;
    @Column(length=1000)
    private String newlvalue;
 
    //getter et setter 
}

08/05/2013, 10h24
Philippe Bastiani

Il y a surement une raison pour laquelle tu souhaites séparer ton audit... Moi perso, je mets tout celà dans une @MappedSuperclass avec toutes les méthodes qui vont bien pour l'audit...
Néanmoins, si tu veux continuer dans ce sens, IMHO, il faudrait auditer les méthodes de ta DAO via AOP et non pas tes entités directement... Après, tout dépend du framework que tu utilises par ailleurs !

Si tu utilises Hibernate... comme te l'a indiqué Ruscov Hibernate Envers est une autre soluce pour l'audit...

a+
Philippe
08/05/2013, 10h26
ruscov

Tu as regardé Hibernate Envers? C'est typiquement ce que tu as besoin.
08/05/2013, 16h12
naf87

Merci pour les réponse. Dès que je finis de regarder Hibernate Envers, je vous fait parvenir un mini compte rendu.