JPA JPA Entities EJB-fähig

[darkcode3]

Bekommen auch JPA Entitiy-Klassen vom Container Beans injiziert? Oder können nur Beans und Servlets mittels @EJB-Annotation etwas injiziert bekommen? Bei mir funktioniert es bei JPA-Entities nicht, aber das kann auch an etwas anderem liegen.

Beispiel:

@Entity
public class Irgendetwas {

@Transient
@EJB
IrgendeinModul modul;

void bla() {
// modul == null
}
}

"Darf" man das überhaupt?

 

[stg]

Kannst du ein wenig konkreter werden, was dein eigentliches Ziel ist?

Aber um vorab schon einmal auf deine Frage zu antworten: Nein, das geht so nicht so einfach. Was aber funktioniert ist CDI in EntityListenern.

 

[darkcode3]

Danke dir, alles klar.

Mein eigentliches Ziel war, dass die JPA-Klasse "Benutzer" auch ein setPasswort(String passwort) besitzt, welches aber nicht direkt das Passwort setzt, sondern zuerst einen Salt erstellt und das Passwort mitsamt dem Salt hasht und den Hash dann im Attribut "private byte[] hash;" zu speichern.

Die Hashing-Funktion wollte ich an zentraler Stelle definieren. Wollte ein Singleton erstellen, und dann habe ich mir Gedacht, realisiere ich das Singleton doch einfach mittels EJBs @Singleton-Annotation.

Vielleicht sollte ich das aber ohnehin nicht tun, weil EJB vom Gefühl her mehr für fachliche Prozesse gedacht ist und die Entity-Klassen nicht von EJB abhängig sein sollten. So im Sinne des Schichtenmodells. (Servlets -> EJBs -> JPA-Entities)

Ich werde dann einfach mal an dieser Stelle ein klassisches Singleton einsetzten statt der Technik von EJB. Oder irgendwann OSGI, falls sich das für JEE als sinnvoll herausstellen sollte.

Bin seit geraumer Zeit etwas mit JEE am experimentieren und muss einfach mal sehen, wie man die Dinge "richtig" macht.

 

[BuckRogers]

Hi,

was ist eigentlich dein Ziel? Willst du einfach nur salzen und hashen und dann was damit machen?

Zu EJB:
Entities(deine sogenannten JPA-Objekte ;-) ) sind nur dazu da um peristierbare Objekte(mit Beziehungen untereinander) abzubilden/speichern/laden...
Also EntityClass ist deine Objektabbildung(nur getter setter + attribute) POJO mit @Entity Deklaration(+ Annotations für Entitykonfiguration).
Der ganze komplexe Kram wird in die SessionBeans ausgelagert. Welche Art von Bean du verwendest hängt davon ab was du machen möchtest.
Möchtest du ein neues Passwort eines Nutzers salten und hashen und speichern? Möchtest du deinen public salt durch einen Service erneuern der regelmäßig läuft?
Es gibt verschiedene Anforderungen. Alle sind unterschiedlich lösbar und JavaEE hat die Lösung ;-)

Grüße
und Gute Nacht erstmal

 

[stg]

Entities(deine sogenannten JPA-Objekte ;-) ) sind nur dazu da um peristierbare Objekte(mit Beziehungen untereinander) abzubilden/speichern/laden...
Also EntityClass ist deine Objektabbildung(nur getter setter + attribute) POJO mit @Entity Deklaration(+ Annotations für Entitykonfiguration).
Der ganze komplexe Kram wird in die SessionBeans ausgelagert.

Das "nur" würde ich doch ein wenig einschränken. BeanValidation wird von JPA beispielsweise voll unterstützt, außerdem kann es sinnvoll sein einfache Prozesse innerhalb von CallBack Methoden direkt ins Model einzubauen, etwa Audit Logging, JMS Massaging, oder die initialisierung komplexerer @Transient Fields.