© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: EnterpriseTales

Java Persistence API 2.1: Nur ein Minor Release?

Eine neue Version der Java-Persistence-API-(JPA-)Spezifikation steht vor der Tür. Grund genug, den ersten „Early Draft“ innerhalb der EnterpriseTales-Kolumne genauer zu untersuchen. JPA-Experte und Apache OpenWebBeans Committer Arne Limburg stellt die wesentlichen Neuerungen vor. Mehr als zwei Jahre nach dem Release der Version 2.0 des JPA-Standards wurde im Januar der erste Early Draft der nächsten Version dieses Standards veröffentlicht. Dieser trägt die Versionsnummer 2.1, was darauf hindeutet, dass es sich „nur“ um ein Minor Release handelt. Aber ist das tatsächlich so? Was gibt es tatsächlich für neue Features, und für wen lohnt es sich, früh auf diesen „Versionszug“ aufzuspringen?

Matthias Weßendorf, Arne Limburg, Lars Röwekamp


Was lange währt, wird gut?Listing 1@EntityListeners(AuditingListener.class)@MappedSuperclasspublic class AuditableEntity { ... public void setCreatedBy(String user) { createdBy = user; }  public void setModifiedBy(String user) { modifiedBy = user; }}@EntityListeners(AuditingListener.class)@MappedSuperclasspublic class AuditableEntity { ... public void setCreatedBy(String user) { createdBy = user; }  public void setModifiedBy(String user) { modifiedBy = user; }}Listing 2public class AuditingListener {  @Inject @Authenticated private User user;  @PrePersist public void auditPersist(AuditableEntity entity) { entity.setCreatedBy(user.getName()); }  @PreUpdate public void auditUpdate(AuditableEntity entity) { entity.setModifiedBy(user.getName()); }}public class AuditingListener {  @Inject @Authenticated private User user;  @PrePersist public void auditPersist(AuditableEntity entity) { entity.setCreatedBy(user.getName()); }  @PreUpdate public void auditUpdate(AuditableEntity entity) { entity.setModifiedBy(user.getName()); }}Auf Deutsch bedeutet das nichts anderes, als dass wir in den Methoden auditPersist(…) und auditUpdate(…) zwar das Auditable-Objekt selbst mit all seinen Attributen verändern dürfen, aber nicht seine Beziehungen zu anderen Objekten. Also dürfen wir auch keine neue Beziehung zu dem aktuell angemeldeten Benutzer herstellen. Würde es sich bei dem Benutzerobjekt anstatt einer Entität um ein Embedded Object handeln (das zum Berispiel nur Benutzername und Kennwort kapselt), wäre die Modifikation wieder erlaubt, weil Embedded Objects Teil des Zustands der Entität sind, zu der sie gehören (vergleiche [2], Abschnitt 2.5). Zwar verbietet die obige Formulierung aus der Specification nicht, dass einzelne Implementierungen damit umgehen können, dass in einem EntityListener auch Beziehungen zwischen Entitäten geändert werden. Zugesichert ist das allerdings nicht, auch wenn es in einer Fußnote der Specification explizit in Aussicht gestellt wird, dass dieses Verhalten gegebenenfalls zu einem späteren Zeitpunkt standardisiert wird. Aber auch mit dieser Einschränkung eröffnet die Integration von CDI in JPA einige neue Möglichkeiten und ist folgerichtig, da auch viele andere Java-EE-Standards in ihren aktuellen Versionen die Integration von CDI vorantreiben.Transaktional oder nicht?Es gibt allerdings Situationen, in denen die...

Java Magazin
Kolumne: EnterpriseTales

Java Persistence API 2.1: Nur ein Minor Release?

Eine neue Version der Java-Persistence-API-(JPA-)Spezifikation steht vor der Tür. Grund genug, den ersten „Early Draft“ innerhalb der EnterpriseTales-Kolumne genauer zu untersuchen. JPA-Experte und Apache OpenWebBeans Committer Arne Limburg stellt die wesentlichen Neuerungen vor. Mehr als zwei Jahre nach dem Release der Version 2.0 des JPA-Standards wurde im Januar der erste Early Draft der nächsten Version dieses Standards veröffentlicht. Dieser trägt die Versionsnummer 2.1, was darauf hindeutet, dass es sich „nur“ um ein Minor Release handelt. Aber ist das tatsächlich so? Was gibt es tatsächlich für neue Features, und für wen lohnt es sich, früh auf diesen „Versionszug“ aufzuspringen?

Matthias Weßendorf, Arne Limburg, Lars Röwekamp


Was lange währt, wird gut?Listing 1@EntityListeners(AuditingListener.class)@MappedSuperclasspublic class AuditableEntity { ... public void setCreatedBy(String user) { createdBy = user; }  public void setModifiedBy(String user) { modifiedBy = user; }}@EntityListeners(AuditingListener.class)@MappedSuperclasspublic class AuditableEntity { ... public void setCreatedBy(String user) { createdBy = user; }  public void setModifiedBy(String user) { modifiedBy = user; }}Listing 2public class AuditingListener {  @Inject @Authenticated private User user;  @PrePersist public void auditPersist(AuditableEntity entity) { entity.setCreatedBy(user.getName()); }  @PreUpdate public void auditUpdate(AuditableEntity entity) { entity.setModifiedBy(user.getName()); }}public class AuditingListener {  @Inject @Authenticated private User user;  @PrePersist public void auditPersist(AuditableEntity entity) { entity.setCreatedBy(user.getName()); }  @PreUpdate public void auditUpdate(AuditableEntity entity) { entity.setModifiedBy(user.getName()); }}Auf Deutsch bedeutet das nichts anderes, als dass wir in den Methoden auditPersist(…) und auditUpdate(…) zwar das Auditable-Objekt selbst mit all seinen Attributen verändern dürfen, aber nicht seine Beziehungen zu anderen Objekten. Also dürfen wir auch keine neue Beziehung zu dem aktuell angemeldeten Benutzer herstellen. Würde es sich bei dem Benutzerobjekt anstatt einer Entität um ein Embedded Object handeln (das zum Berispiel nur Benutzername und Kennwort kapselt), wäre die Modifikation wieder erlaubt, weil Embedded Objects Teil des Zustands der Entität sind, zu der sie gehören (vergleiche [2], Abschnitt 2.5). Zwar verbietet die obige Formulierung aus der Specification nicht, dass einzelne Implementierungen damit umgehen können, dass in einem EntityListener auch Beziehungen zwischen Entitäten geändert werden. Zugesichert ist das allerdings nicht, auch wenn es in einer Fußnote der Specification explizit in Aussicht gestellt wird, dass dieses Verhalten gegebenenfalls zu einem späteren Zeitpunkt standardisiert wird. Aber auch mit dieser Einschränkung eröffnet die Integration von CDI in JPA einige neue Möglichkeiten und ist folgerichtig, da auch viele andere Java-EE-Standards in ihren aktuellen Versionen die Integration von CDI vorantreiben.Transaktional oder nicht?Es gibt allerdings Situationen, in denen die...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang