2017-05-02 1 views
1

Nous avons une application développée en JSF et nous la convertissons pour utiliser CDI. Au cours de ce processus, nous avons fait des tests sur Wildfly et nous avons pu le faire fonctionner comme avant la conversion. Des problèmes sont survenus lorsque nous l'avons déployé sur Websphere!javax.enterprise.inject.UnsatisfiedResolutionException sur Websphere

Notre application comporte deux parties, pour simplifier la partie 1 et la partie 2, où le pot résultant de la partie 1 est inclus dans la partie 2, ce qui signifie que le fichier de guerre déployé dans Websphere contient déjà le fichier jar de la partie 1.

maintenant, lorsque l'application démarre en Websphere l'erreur suivante est générée

[4/28/17 16:35:54:107 CEST] 00000083 BeansDeployer E BeansDeployer deploy 
           javax.enterprise.inject.UnsatisfiedResolutionException: Api type [web.frmwrk.mgbean.WebSession] is not found with the qualifiers 
Qualifiers: [@javax.enterprise.inject.Default()] 
for injection into 
Field Injection Point, field : protected web.frmwrk.mgbean.WebSession web.frmwrk.FacesBean.ws, Bean Owner : [-2102135427,Name:dealerLink,WebBeans Type:MANAGED,API Types:[web.mgbean.dealer.Link,web.frmwrk.FacesBean,java.lang.Object,java.io.Serializable],Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named]] 
    InjectionType : [class web.frmwrk.mgbean.WebSession] 
    Annotated  : [Annotated Field,Base Type : class web.frmwrk.mgbean.WebSession,Type Closures : [class web.frmwrk.mgbean.WebSession, class web.frmwrk.FacesBean, class java.lang.Object, interface java.io.Serializable],Annotations : [@javax.inject.Inject()],Java Member Name : ws] 
    Qualifiers  : [[@javax.enterprise.inject.Default()]] 
    at org.apache.webbeans.util.InjectionExceptionUtils.throwUnsatisfiedResolutionException(InjectionExceptionUtils.java:92) 

Nous avons cherché une solution possible, mais pas de chance jusqu'à présent. Au cours de notre recherche, nous avons trouvé ce page. Nous avons ajouté un chemin de classe sur MANIFEST.MF en mentionnant la partie 1, mais rien n'a changé.

L'un de vous a-t-il fait face à un problème similaire? Y a-t-il une configuration spéciale que nous pourrions avoir besoin de faire sur Websphere pour que cela fonctionne comme sur Wildfly?

+0

Wildfly Weld (implémentation de référence CDI). Alors que Websphere utilisait une implémentation alternative - OpenWebBeans (les dernières versions utilisent aussi Weld). Il y a quelques différences connues dans ces deux et vous pourriez en avoir rencontré quelques-uns. Je ne sais pas grand-chose sur OWB, mais aussi voir ce qui se passe, s'il vous plaît poster votre structure de déploiement tel qu'il est. Surtout si nous parlons d'EAR, ou de libs partagées etc ... Ce sont des domaines dans lesquels ces impls diffèrent souvent. – Siliarus

Répondre

1

Il est probable que vous utilisiez un niveau de spécification CDI ou EE différent dans Wildfly.

Vous n'avez spécifié aucune version ni quelle classe est censée satisfaire cette dépendance, ni où elle est stockée. Mais vous avez probablement besoin d'un beans.xml dans le jar contenant la classe destinée à satisfaire cette dépendance.

+0

Je ne pense pas que ce soit le truc habituel "' beans.xml' blindshot ". On dirait que c'est causé par les différences entre Weld et OWB. Si cela fonctionnait sans beans.xml sur un AS, cela devait marcher sur l'autre, c'est ce que disent les spécifications. – Siliarus

+0

Semble assez probable pour moi, étant donné que 1 AS est connu pour être sur CDI 1.0. – covener

+1

En effet, même si nous utilisons JEE7, OWB doit toujours avoir bean.xml. Merci beaucoup. – Miguel