Unterschied @Named in JSR-299 und 330

Raphalon

Aktives Mitglied
Hallo,

ich komme mit der Annotation @Named durcheinander.
  • Nach JSR-299 handelt es sich dabei um die Definition einer CDI Bean, die Bean ist dann z.B. an einen context gebunden und in einer xhtml-Seite unter dem definierten Namen ansprechbar.
  • Nach JSR-330 wird damit wohl eine generelle "Dependency Injection for Java" für die jeweilige Bean definiert. Die Bean erhält einen Namen und muß z.B. in Spring nicht separat konfiguriert werden.
In beiden Fällen bezieht sich die Annotation auf javax.inject.Named.

Kann mir jemand sagen, worin der Unterschied besteht? Ist JSR-330 nur eine Erweiterung von JSR-229?

Gruß,

Raphalon
 
M

maki

Gast
Umgekehrt wird ein Schuh draus, JSR-299 baut auf JSR-330 auf, auch wenn die Zahlen das Gegenteil suggerieren.

CDI ist eben nur mit Weld/SEAM nutzbar, so gehsehn, wenn du Weld bzw. SEAM nutzt, interessiert du dich Hauptsächlich für den JSR-299.

@Named sollte man imho in "normalem" DI (nach JSR-330) mit Vorsicht geniessen da nicht typssicher, @Inject ist da besser.
In CDI kommst du um @Named eigentlich nicht herum.
 

Raphalon

Aktives Mitglied
In dem Buch Core Java Server Faces von Horstmann, Geary werden aber CDI Beans auch im Zusammenhang mit dem Glassfish verwendet (Erklärung dazu z.B. auf Seite 39). Das funktioniert auch und es ist nicht Weld/SEAM!?

Wenn man sowohl für "normale" DI (330) als auch CDI (299) die Annotation javax.inject.Named verwendet, woher weiß man, um welche DI es sich handelt? Ich habe z.B. aus einem anderen Buch (siehe unten) ein Stück Code, welcher dieses Annotation verwendet. Angeblich wird in dem geg. Fall eine Spring-Bean definiert (ersetzt also die <bean...> Konfiguration). Ist die Bean dann automatisch auch eine CDI - Bean? Reicht es dann aus, Spring (z.B. im pom.xml für ein Maven-Projekt) einzubinden, damit aus einer CDI-Bean eine "normale" DI plus CDI wird?
Code:
@Named("customerDao")
@Singleton
public class JpaCustomerDao implements CustomerDao {

  @PersistenceContext private EntityManager em;

  public Customer createNew() {
    Customer customer = new Customer();
    return customer;
  }
  public void persist(Customer customer) {
    em.persist(customer);
  }
  public List<Customer> findAll() {
    return em.createQuery("select c from Customer c")
        .getResultList();
  }
  public Customer findById(long id) {
    return em.find(Customer.class, id);
  }
  public void delete(Customer customer) {
    em.remove(customer);
  }
}
 

Noctarius

Top Contributor
In einem Application Server bist du im JEE Umfeld und damit im CDI (JSR-299). Der JSR-330 ist der globale JSR, welcher Annotations und Injection Mechanismen generell im Java-Umfeld beschreibt. Dieser ist sehr stark SpringDI und Guice geprägt, die 2 größten Vertreter der Java DI Schiene.

CDI hat einige Erweiterungen eben für den Bereich Enterprise Java und ist angepasst auf die Umgebung Application Server.

CDI kannst du dabei nicht AUCH mit Weld nutzen, sondern Weld ist die Referenzimplementierung der JSR-299 :D

Das die Nummer des JSR für CDI tiefer ist, liegt daran, dass die Idee schon länger zurück liegt. Mit dem JSR-330 kam dann aber die perfekte Basis für das Vorhaben. Immerhin ist dank oben genannten Frameworks der Entwicklungsstand sehr hoch (PS für JSR-330 ist Guice in Version 3.0 die Referenzimplementierung).
 

Raphalon

Aktives Mitglied
Danke für Eure Antworten. Habe noch an anderer Stelle gesucht und gefunden - was ich zunächst nicht verstand: wenn normale DI verwendet wird, wie kann man dann in einer xhtml auf die Bean zugreifen (z.B. mittels #{beanName.methode})? Normalerweise macht das der EL-Resolver von JSF und findet dann die Bean und Methode. In solch einem Fall macht die Annotation @Named aus einer Bean eine CDI-Bean.

Wenn aber nun Spring verwendet wird, handelt es sich um JSR-330, also "normale" DI. Damit nun dennoch mittels EL aus einer xhtml - Seite auf die Bean zugegriffen werden kann, muß mittels Spring-Konfiguration sichergestellt werden, daß JSF die Beans nicht mehr selbst auflöst, sondern dies Spring überläßt. Dann werden Beans über den ApplicationContext von Spring aufgelöst und nur noch dann von JSF, wenn die Spring-Auflösung erfolglos war.
 

Ähnliche Java Themen


Oben