Problème de chargeur de classes dans JBoss AS 6 avec EJB et WAR déployés côte à côte

Question

J'ai trouvé un problème assez complexe lorsque je travaillais sur un projet avec plusieurs déployables EE. Le problème semble être une confluence des dépendances Hibernate de TimerService EJB3.1 et une isolation insuffisante du chargeur de classe. À partir d'une version AS 6 CR1 stockée, je déploie un fichier WAR. Ce fichier WAR contient des fichiers Hibernate.

Puis, je déploie un EJB (techniquement un MDB) dans un fichier JAR. Quand je le fais, JBoss démarre alors le TimerService, afin de fournir un support EJB3.1 complet. Le TimerService dépend d'Hibernate. JBoss se met alors en grève, car le chargeur de classe détecte une version déjà chargée d'Hibernate.

J'ai même essayé d'empaqueter chacun d'entre eux dans un fichier EAR distinct et de les déployer. Pas de dé. Quelque chose sur la façon dont le TimerService est chargé semble ignorer totalement l'isolation de la classe.

Ma question est, y at-il quelque chose que je peux faire à ce sujet, à moins de désactiver le TimerService? J'avais l'intention de faire usage de ses fonctionnalités astucieuses plus tard dans le projet. Honnêtement, je ne sais même pas s'il s'agit d'un bug, car la documentation du classloader pour JBoss semble avoir été écrite par des Klingons en colère. Toujours, j'espère pour un work-around.

EDIT - En fait, je n'ai même pas le moyen de désactiver le TimerService, car chacun de mes efforts a été contrecarré d'une manière ou d'une autre. En l'état, je ne vois pas comment n'importe qui peut déployer Hibernate et les EJB sur la même instance JBoss.

EDIT - J'ai éventuellement réussi à déployer en n'incluant pas les fichiers Hibernate dans mon MDB ou mon fichier WAR, mais je me suis basé sur l'implémentation Hibernate de JBoss. C'est insatisfaisant; Je suis laissé avec le sentiment qu'il n'y a pas d'isolement entre le conteneur et mes haricots. Mais au moins c'est une version actuelle d'Hibernate (3.6).

Answer 1

Je ne sais pas ce que vous avez essayé jusqu'à présent, mais cela devrait fonctionner:

EAR contenant:

• JAR pour les EJBs
• JAR pour l'Assemblée parlementaire paritaire
• WAR pour la webapp
• Toutes les bibliothèques dont vous avez besoin.
• jboss-app.xml, avec un "chargeur référentiel" unique

et comprennent une jboss-app.xml dans META-INF de votre oreille:

<jboss-app> 
    <loader-repository>...</loader-repository> 
</jboss-app> 

Vous pouvez vérifier ces deux pages:

http://community.jboss.org/wiki/ClassLoadingConfiguration

http://community.jboss.org/wiki/JBossClassLoadingUseCases

Mais je réexaminerait la décision de regrouper votre propre version de Hiberner. Bien que cela puisse sembler raisonnable, l'AS est là pour vous fournir un environnement d '«hébergement d'applications», et il fournit déjà certains services, comme la persistance. Donc, laissez cette inquiétude à l'AS ;-)

Answer 2

Je suggère de supprimer toutes les preuves des bocaux d'hibernation de l'installation de jboss. Je ne sais pas pourquoi ils sont inclus - provoque ce genre de choses. Jboss cherchera d'abord dans ses propres bibliothèques, donc vous aurez forcément des conflits.

En outre, je sais que Jboss4 n'a pas été configuré par défaut pour isoler chaque application dans son propre chargeur de classes, de sorte que toutes les classes ont été chargées à partir du même pool. Je ne sais pas si c'est toujours le cas, mais cela mérite d'être étudié. Lors de l'installation de jboss, vous pouvez le configurer pour isoler le chargeur de classe de chaque application si vous le souhaitez. Bien que s'il y a une version d'hibernate dans le common jboss/lib lib isoler les chargeurs de classe n'aidera pas.