J'ai déployé 2 oreilles sur JBoss As 7.1.0.Alpha1-Snapshot (version 7.0.1.finale). Les deux disparaissent bien.
J'ai une classe EJB singleton emballée dans un pot, dans l'une des oreilles: p> quand il déploie, il est indiqué que l'EJB est lié à : p> jusqu'à présent, si bon. Lorsque j'essaie de la chercher via JNDI à partir d'une classe non-CDI, non-EJB dans un pot dans l'autre oreille déployée, il ne se trouve que sur les noms JNDI sous «Global» - à nouveau, attendu. p> Cependant, lorsque j'essaie de lancer l'objet résultant à la classe d'interface réelle: p> i Obtenez l'exception suivante: p> @Local(Store.class)
@Remote(Store.class)
@LocalBean
6 Réponses :
Ceci est un bug dans as7: https://issues.jboss.org/browse/ AS7-1658
Une solution de contournement possible ne doit pas lancer l'objet retourné, puis l'utiliser pour incendier les méthodes via Réflexion . Bien collé cependant.
Une meilleure approche consiste à déployer les interfaces partagées dans un module JBoss et à inclure ce module dans la catégorie de classe des artefacts avec (lors de l'utilisation de Maven)
Ahh, je n'ai pas réalisé ça. Pas actuellement une option pour nous, mais un excellent point.
aussi je reçois de l'aide avec ce commentaire;):
David Lloyd Ajout d'un commentaire - 07 / Mar / 12 16h02 C'est parce que vous utilisez des interfaces locales. Lorsque vous utilisez des interfaces locales, vous ne pouvez avoir qu'une seule copie de la classe d'interface (c'est ce qui le rend local). Passez à l'utilisation d'interfaces distantes (ou, utilisez la parcelle de classe pour obtenir vos interfaces locales au lieu de les dupliquer) et le problème devrait disparaître.
J'avais le même problème; Essayé de mettre la classe d'interface comme un module d'espèce et l'inclure dans une oreille et l'inclure comme prévu dans l'autre oreille;
Dans JBoss, les classes de chaque oreille sont chargées par un chargeur de classe distinct. Donc, si une oreille a la classe A, et une autre a la même classe A, vous recevez une exception de classe de classe. Donc, dans la deuxième oreille, donnez la dépendance telle que fournie et dans JBoss-Déploitation-Structure.xml Ajoutez la première oreille sous forme de dépendance du module. Notez que la dépendance dynamique du module peut justifier que le nom du fichier d'oreille soit constant; Vous pouvez spécifier modifié également la recherche de la section locale à distance - voir ci-dessous et inclus le module Maven contenant l'interface dans les deux modules p> et vous voudriez modifier la recherche de Java: application à Java: global p> et depuis le L'oreille est généralement enregistrée avec la version comme celle-ci p> et que vous ne souhaitez pas rechercher la version pilotée dans votre code, vous devez faire deux autres choses. Dans votre application.xml dans votre Builder Ear Ear Maven Dir (SRC \ Main \ Resources \ Application.xml) Vous devez ajouter la balise "Nom de l'application" comme p> java.lang.ClassCastException: com.package.TaskSplitterItf$$$view210 cannot be cast to com.package.TaskSplitterItf
Modification de la portée de la dépendance du module EJB sur "fourni" dans le fichier POM du module Web a résolu le problème d'exception de la classe. Merci.
Même question également si votre client EJB est dans une oreille et la mise en œuvre de l'EJB dans un autre "service", et invoquez une méthode d'interface @Remote sur l'EJB renvoyant un objet complexe au lieu d'un type primitif. L'objet complexe étant renvoyé est également déclaré comme une interface, correctement déclarée, connue et disponible pour le client EJB. L'implémentation de l'objet retourné est celle-ci contenue dans le "service" -ear avec la mise en œuvre cible de l'EJB. Malgré un tel code conformément, JBoss échoue sur une exception de la classe.
J'ai noté que vous pouvez en effet conserver une interface @Remote pour déclarer toutes les méthodes EJB cible, mais ne peut utiliser qu'une déclaration de classe unie pour tous les objets renvoyés par ces méthodes. Si vous déclarez les objets retournés en tant qu'interfaces, des exceptions de distribution de classe s'ensuivent dans JBoss.
Ceci est une limitation (ou un bug) dans JBoss; Il fonctionne dans Glassfish et Weblogic où nous avions le même code une fois en cours d'exécution.
Même problème s'est produit si vous avez le fichier JAR avec vos EJB plus comme une fois dans votre oreille.
échantillon:
vous avez
Si votre mywebApp.war contient également le myejb.jar par moi-même, vous aurez cette erreur (Classcastexc). Semble que l'objet EJB est créé à l'intérieur du Myejb.jar de la Myenterprise.ear. Et si vous allez ensuite lancer cet objet dans la même classe du myejb.jar à l'intérieur du mywebApp.war, cela ne fonctionnera pas car c'est la classe est définie dans un autre pot.
Si vous avez cette erreur, vous devez supprimer le myejb.jar à partir de votre fichier de guerre et que le classcastexc est parti ...