JAX-RS-2.0-Integration mit EJB und CDI
Enterprise JavaBeans (EJB) und Contexts and Dependency Injection (CDI) können mit JAX-RS 2.0 (Java™ API for RESTful Web Services) in WebSphere Application Server Traditional Version 9 integriert werden.
Damit JAX-RS 2.0 mit Enterprise-Beans funktioniert, müssen Sie die Annotation @Path für die Klasse einer Bean verwenden und sie in eine Stammressourcenklasse konvertieren.
Wenn Sie EJB integrieren, können Sie die Enterprise JavaBeans mit Annotationen versehen und sie als REST-Endpunkte zugänglich machen. Sie können auch die Java Transaction API (JTA) und Sicherheitsfunktionen von EJB verwenden. JAX-RS 2.0 in WebSphere Application Server Traditional unterstützt die Verwendung von Stateless und Singleton-Session-Beans als Stammressourcenklassen, Provider und Anwendungsunterklassen.
Wenn Sie CDI integrieren, können Sie CDI-Beans oder Managed Beans als REST-Endpunkte annotieren und CDI-Injektion für Web-Services verwenden. JAX-RS 2.0 in WebSphere Application Server Traditional unterstützt CDI-Beans als Stammressourcenklassen, Provider und Anwendungsunterklassen. Provider und Anwendungsunterklassen müssen Singletons sein oder den Anwendungsbereich verwenden. Die CDI-Spezifikation vereinfacht die Integration von Java EE-Komponenten verschiedener Arten. Sie stellt einen allgemeinen Mechanismus für das Injizieren von Komponenten wie EJBs oder Managed Beans in andere Komponenten, z. B. in JSPs oder EJBs, bereit.
- Verwenden Sie für eine Stateless Session-Bean die Annotation @Stateless wie im folgenden Beispiel:
@Stateless @Path("stateless-bean") public class StatelessResource {...}
- Verwenden Sie für eine Singleton-Bean die Annotation @Singleton wie im folgenden Beispiel:
@Singleton @Path("singleton-bean") public class SingletonResource {...}
@ApplicationScoped
@Path("/ApplicationScopedResource")
public class ApplicationScopedResource {
private @Inject
SimpleBean injected;
...
}
Einschränkungen in JAX-RS 2.0 mit EJB und CDI
Nachfolgend sind die Einschränkungen für JAX-RS 2.0 in WebSphere Application Server Traditional aufgeführt:
- Wenn Sie EJB als JAX-RS-Ressource, -Provider oder -Anwendung verwenden, können Sie die Annotation @Context nicht in den Konstruktor der EJB-Bean injizieren.Anmerkung: Der Grund hierfür ist, dass die EJB mit Standardkonstruktor nur gemäß der EJB- und der JAX-RS-Spezifikation für JAX-RS verwendet werden kann.
- Wenn eine Anwendungsklasse keine Schnittstelle implementiert oder mit der Annotation @Localbean versehen ist, wird sie als EJB betrachtet. Implementiert die Anwendungsklasse lokale oder POJO-Schnittstellen, wird sie nicht als EJB betrachtet.
- Nachfolgend sind die Bedingungen aufgelistet, nach denen eine Klasse als gültiger EJB-Provider betrachtet wird oder nicht:
- Wenn eine Klasse POJO-Providerschnittstellen ausschließlich ohne die Annotation @Local implementiert, wird sie als gültiger EJB-Provider betrachtet.
- Wenn eine Klasse mit der Annotation @LocalBean versehen ist und die POJO-Providerschnittstelle implementiert, wird sie als gültiger EJB-Provider betrachtet.
- Wenn eine Klasse die lokale Schnittstelle mit der Annotation @Local hat, ist die lokale Schnittstelle eine Providerschnittstelle. Implementiert diese Klasse die Providerschnittstelle, wird sie als gültiger EJB-Provider betrachtet.
- Wenn eine Klasse eine lokale Schnittstelle mit der Annotation @Local hat und die lokale Schnittstelle keine Providerschnittstelle ist, ist die Klasse kein gültiger Provider. Der Grund hierfür ist, dass der EJB-Container in diesem Fall nur einen EJB-Stub für die lokale Schnittstelle und nicht für die POJO-Providerschnittstelle generieren kann.
- Wenn eine Klasse nur mit der Annotation @Local versehen ist, die auf eine Providerschnittstelle verweist, diese Providerschnittstelle jedoch nicht implementiert, ist die Klasse kein gültiger Provider. In der Spezifikation heißt es: Ein Provider ist eine Klasse, die JAX-RS-Schnittstellen implementiert, die in dieser Spezifikation beschrieben sind und zur automatischen Erkennung mit der Annotation @Provider versehen werden können.
- Nachfolgend sind die Bedingungen aufgelistet, nach denen die Methoden in einer Klasse als JAX-RS-Ressourcen verfügbar sind oder nicht:
- Wenn eine EJB-basierte Ressource keine Schnittstelle implementiert, sind alle in dieser Klasse deklarierten Methoden als JAX-RS-Ressourcen verfügbar.
- Wenn eine EJB-basierte Ressource eine Schnittstelle (lokal oder POJO) implementiert, sind alle in dieser Schnittstelle deklarierten Methoden als JAX-RS-Ressourcen verfügbar.
- Wenn eine EJB-basierte Ressource mehrere Schnittstellen implementiert:
- Wenn alle Schnittstellen POJO-Schnittstellen ohne die Annotation @Local sind, sind alle in der Schnittstelle deklarierten Methoden als JAX-RS-Ressourcen verfügbar.
- Wenn alle Schnittstellen lokale Schnittstellen mit der Annotation @Local sind, sind alle in der Schnittstelle deklarierten Methoden als JAX-RS-Ressourcen verfügbar.
- Wenn einige Schnittstellen lokale Schnittstellen mit der Annotation @Local sind und einige keine lokalen Schnittstellen sind, sind nur in den lokalen Schnittstellen deklarierte Methoden als JAX-RS-Ressourcen verfügbar.Anmerkung: Der Grund hierfür ist, dass der EJB-Container in diesem Szenario nur einen EJB-Stub für lokale Schnittstellen generieren kann.
- Wenn die EJB-basierte Ressource mit der Annotation @LocalBean versehen ist, sind alle in der Klasse deklarierten Methoden als JAX-RS-Ressourcen verfügbar.
- Wenn eine EJB-basierte Ressource eine Schnittstelle implementiert, muss die JAX-RS-Ressourcenmethode in der Schnittstelle deklariert sein. Ist die Schnittstelle ein Provider, der nicht modifiziert werden kann, müssen Sie eine neue Schnittstelle für die Ressourcenklasse erstellen, um die Ressourcenmethode hinzuzufügen. Andernfalls wird sie nicht als EJB-Ressource betrachtet.
- Wenn eine Ressourcenklasse mit der Annotation @Path eine JAX-RS-Providerschnittstelle implementiert oder mit der Annotation @Provider deklariert, funktioniert diese Klasse als Ressource und als Provider. Die JAX-RS-2.0-Engine verwendet in diesem Fall standardmäßig nur eine Instanz dieser Klasse, die von der Ressource und dem Provider gemeinsam genutzt wird. Der Lebenszyklus der Instanz ist ein Singleton.
- Wenn eine Klasse in den Methoden getClasses und getSingletons der Anwendungsklasse registriert ist, verwendet die JAX-RS-2.0-Engine standardmäßig die Instanz der Methode getSingletons und ignoriert die Registrierung in der Methode getClasses.
- Wenn eine REST-konforme Ressource gleichzeitig eine CDI-gesteuerte Bean mit dem Bereich javax.enterprise.context.Dependent ist, kann die Methode PreDestroy aufgrund der CDI-Beschränkung nicht aufgerufen werden.
Lebenszyklus von JAX-RS 2.0-Beans und EJB-Beans
Anwendung | JAX-RS 2.0 | EJB | Ergebnis |
---|---|---|---|
Ressource | perRequest | Nicht kontextsensitiv (Stateless) | Nicht kontextsensitiv (Stateless) |
perRequest | Singleton | Singleton | |
Singleton | Nicht kontextsensitiv (Stateless) | Nicht kontextsensitiv (Stateless) | |
Singleton | Singleton | Singleton | |
Provider | Singleton | Nicht kontextsensitiv (Stateless) | Nicht kontextsensitiv (Stateless) |
Singleton | Singleton | Singleton |
Lebenszyklus des Bereichs für JAX-RS 2.0 und für CDI
Anwendung | JAX-RS 2.0-Bereich | CDI-Bereichsannotation | Ergebnis |
---|---|---|---|
Ressource | perRequest | @ApplicationScoped | Singleton |
perRequest | @RequestScoped | perRequest | |
perRequest | @Dependent | perRequest | |
perRequest | @SessionScoped | Session | |
perRequest | perRequest | ||
Singleton | @ApplicationScoped | Singleton | |
Singleton | @RequestScoped | perRequest | |
Singleton | @Dependent | Singleton | |
Singleton | @SessionScoped | Session | |
Singleton | Singleton | ||
Provider | Singleton | @ApplicationScoped | Singleton |
Singleton | @RequestScoped | Singleton | |
Singleton | @Dependent | Singleton | |
Singleton | @SessionScoped | Singleton | |
Singleton | Singleton |
Konfliktmeldungen für JAX-RS 2.0-Bereich und CDI-Bereichslebenszyklus
Die folgenden Warnhinweise werden angezeigt, wenn der Bereichslebenszyklus von JAX-RS 2.0 mit CDI in Konflikt steht. Es handelt sich um Warnhinweise, die keine Maßnahmen erfordern.
Diese Nachricht wird angezeigt, wenn der JAX-RS-2.0-Ressourcenbereich nicht mit dem CDI-Bereich übereinstimmt und die Ressourceninstanz in CDI vorhanden ist, sodass WebSphere Application Server Traditional die Ressourceninstanz aus CDI abruft. Wenn die Instanz aus JAX-RS stammt, schließt sie keine CDI-Injektion ein.CWWKW1001W: The scope {1} of JAXRS-2.0 Resource {0} does not match the CDI scope {2}. WebSphere Application Server traditional gets resource instance from {3}.
Diese Nachricht wird angezeigt, weil die Providerinstanz ein Singleton ist. WebSphere Application Server Traditional ruft die Providerinstanz von CDI ab, wenn der Provider den Bereich Dependent oder ApplicationScoped hat. Wenn die Instanz aus JAX-RS stammt, schließt sie keine CDI-Injektion ein.CWWKW1002W: The CDI scope of JAXRS-2.0 Provider {0} is {1}. WebSphere Application Server traditional gets the provider instance from {2}.