Intégration de JAX-RS 2.0 à EJB et CDI
Java™ API for RESTful Web Services (JAX-RS) 2.0 s'intègre à Enterprise JavaBeans (EJB) et Contexts and Dependency Injection (CDI) dans WebSphere Application Server Traditional V9.
Pour que JAX-RS 2.0 soit compatible avec les beans d'entreprise, vous devez utiliser @Path pour annoter la classe d'un bean et la convertir en une classe de ressources racine.
Avec l'intégration à EJB, vous pouvez annoter les beans EJB pour les afficher en tant que noeuds finaux REST. Vous pouvez également utiliser l'API JTA (Java Transaction API) et les fonctions de sécurité d'EJB. L'implémentation JAX-RS 2.0 dans WebSphere Application Server Traditional prend en charge l'utilisation de beans session singleton et sans état en tant que classes de ressources racine, fournisseurs et sous-classes d'application.
Avec l'intégration à CDI, vous pouvez annoter les beans CDI ou les beans gérés en tant que noeuds finaux REST et utiliser l'injection CDI pour les services Web. L'implémentation JAX-RS 2.0 dans WebSphere Application Server Traditional prend en charge l'utilisation de beans de style CDI en tant que classes de ressources racine, fournisseurs et sous-classes d'application. Les fournisseurs et les sous-classes d'application doivent être des singletons ou utiliser la portée d'application. La spécification CDI facilite l'intégration de composants Java EE de différents types. Elle fournit un mécanisme commun pour injecter des composants, tels que des composants EJB ou des beans gérés, dans d'autres composants, tels que des Java Server Pages (JSPs) ou d'autres EJB.
- Pour un bean session sans état, utilisez l'annotation @Stateless comme illustré dans l'exemple suivant :
@Stateless @Path("stateless-bean") public class StatelessResource {...}
- Pour un bean singleton, utilisez l'annotation @Singleton comme illustré dans l'exemple suivant :
@Singleton @Path("singleton-bean") public class SingletonResource {...}
@ApplicationScoped
@Path("/ApplicationScopedResource")
public class ApplicationScopedResource {
private @Inject
SimpleBean injected;
...
}
Restrictions relatives à JAX-RS 2.0 avec EJB et CDI
Pour connaître les restrictions relatives à JAX-RS 2.0 dans WebSphere Application Server Traditional, examinez les points suivants :
- Si vous utilisez EJB en tant que ressource, fournisseur ou application JAX-RS, vous ne pouvez
pas utiliser l'injection @Context sur le constructeur du bean
EJB. Remarque : En effet, l'EJB avec un constructeur par défaut peut uniquement être utilisé pour la spécification JAX-RS basée sur EJB et JAX-RS.
- Si une classe d'application n'implémente aucune interface ou comporte une annotation @Localbean, elle est considérée comme un EJB. Mais, si elle implémente des interfaces locales ou POJO, elle n'est pas considérée comme un EJB.
- Pour un fournisseur, voici les conditions selon lesquelles une classe peut être ou non considérée comme un fournisseur EJB valide :
- Si une classe implémente des interfaces de fournisseur POJO uniquement sans l'annotation @Local, elle est considérée comme un fournisseur EJB valide.
- Si une classe comporte l'annotation @LocalBean et implémente le fournisseur POJO, elle est considérée comme un fournisseur EJB valide.
- Si une classe comporte l'interface locale avec l'annotation @Local, l'interface locale est une interface de fournisseur. Si cette classe implémente l'interface de fournisseur, elle constitue un fournisseur EJB valide.
- Si une classe comporte une interface locale avec l'annotation @Local, et si l'interface locale n'est pas une interface de fournisseur, elle ne constitue pas un fournisseur valide. En effet, le conteneur d'EJB peut générer un module de remplacement EJB pour l'interface locale uniquement et non pour l'interface de fournisseur POJO.
- Si une classe comporte l'annotation @Local, et si l'annotation n'implémente pas l'interface de fournisseur à laquelle elle fait référence, elle ne constitue pas un fournisseur valide. Selon la spécification JAX-RS 2.0, un fournisseur est une classe qui implémente une ou plusieurs interfaces JAX-RS qui sont introduites dans cette spécification et qui peuvent être annotées avec @Provider pour la reconnaissance automatique.
- Pour une ressource, voici les conditions selon lesquelles les méthodes d'une classe sont disponibles ou pas en tant que ressources JAX-RS :
- Si une ressource basée sur EJB n'implémente aucune interface, toutes les méthodes qui sont déclarées dans cette classe sont disponibles en tant que ressources JAX-RS.
- Si une ressource basée sur EJB implémente une interface (locale ou POJO), toutes les méthodes qui sont déclarées dans cette interface sont disponibles en tant que ressources JAX-RS.
- Si une ressource basée sur EJB implémente plusieurs interfaces.
- Si toutes les interfaces sont des interfaces POJO sans l'annotation @Local, toutes les méthodes qui sont déclarées dans l'interface sont disponibles en tant que ressources JAX-RS.
- Si toutes les interfaces sont des interfaces locales avec l'annotation @Local, toutes les méthodes qui sont déclarées dans l'interface sont disponibles en tant que ressources JAX-RS.
- Si certaines des interfaces sont des interfaces locales avec l'annotation @Local alors que d'autres ne sont pas des interfaces locales, seules les méthodes qui sont déclarées dans les interfaces locales sont disponibles en tant que ressources JAX-RS. Remarque : En effet, le conteneur d'EJB peut générer un module de remplacement EJB pour les interfaces locales uniquement dans ce scénario.
- Si la ressource basée sur EJB comporte l'annotation @LocalBean, toutes les méthodes qui sont déclarées dans la classe sont disponibles en tant que ressource JAX-RS.
- Si la ressource basée sur EJB implémente une interface, la méthode de ressource JAX-RS doit être déclarée dans l'interface. Si l'interface est un fournisseur qui ne peut pas être modifié, vous devez créer une nouvelle interface pour la classe de ressources afin d'ajouter la méthode de ressource. Sinon, elle n'est pas considérée comme une ressource EJB.
- Si une classe de ressources avec l'annotation @Path implémente une interface JAX-RS ou est déclarée avec l'annotation @Provider, cette classe fonctionne en tant que ressource et fournisseur. Dans ce cas, par défaut, le moteur JAX-RS 2.0 utilise une seule instance de cette classe qui est partagée par la ressource et le fournisseur, et le cycle de vie de l'instance est un singleton.
- Si une classe est enregistrée dans les méthodes getClasses et getSingletons de la classe d'application, par défaut, le moteur JAX-RS 2.0 utilise l'instance de la méthode getSingletons et ignore l'enregistrement dans la méthode getClasses.
- Si une ressource RESTful est aussi un bean géré par CDI et si sa portée est javax.enterprise.context.Dependent, la méthode PreDestroy ne peut pas être appelée en raison de la restriction CDI.
Cycle de vie du bean JAX-RS 2.0 et du bean EJB
Application | JAX-RS 2.0 | EJB | Résultat |
---|---|---|---|
Ressource | perRequest | Sans état | Sans état |
perRequest | Singleton | Singleton | |
Singleton | Sans état | Sans état | |
Singleton | Singleton | Singleton | |
Fournisseur | Singleton | Sans état | Sans état |
Singleton | Singleton | Singleton |
Cycle de vie de la portée JAX-RS 2.0 et de la portée CDI
Application | Portée JAX-RS 2.0 | Annotation de portée CDI | Résultat |
---|---|---|---|
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 | ||
Fournisseur | Singleton | @ApplicationScoped | Singleton |
Singleton | @RequestScoped | Singleton | |
Singleton | @Dependent | Singleton | |
Singleton | @SessionScoped | Singleton | |
Singleton | Singleton |
Messages de conflit du cycle de vie de la portée JAX-RS 2.0 et de la portée CDI
Les messages d'avertissement ci-après s'affichent lorsque le cycle de vie de portée de JAX-RS 2.0 et CDI sont en conflit. Il s'agit de messages d'avertissement et aucune action n'est requise.
Ce message s'affiche si la portée de ressource JAXRS-2.0 ne correspond pas à la portée CDI et que l'instance de ressource existe dans CDI. Dans ce cas, WebSphere Application Server Traditional extrait l'instance de ressource de CDI. L'instance inclut pas l'injection CDI si elle provient de JAXRS.CWWKW1001W: La portée {1} de JAXRS-2.0 Resource {0} ne correspond pas à la portée CDI {2}. WebSphere Application Server Traditional extrait l'instance de ressource de {3}.
Ce message s'affiche parce que l'instance de fournisseur est Singleton uniquement. WebSphere Application Server Traditional extrait l'instance de fournisseur de CDI si la portée CDI du fournisseur est dépendante ou au niveau de l'application. L'instance inclut pas l'injection CDI si elle provient de JAXRS.CWWKW1002W: La portée CDI de JAXRS-2.0 Provider {0} est {1}. WebSphere Application Server Traditional extrait l'instance de fournisseur de {2}.