Comment deux programmes qui dépendent de différentes implémentations Xalan peuvent-ils coexister dans le même VM/System Classloader?

Question

J'ai posé cette question dans plusieurs flavors, et je pense que je ne pose pas la bonne question. Je soupçonne maintenant que Xalan, puisqu'il implémente une norme approuvée par Java, ne peut avoir qu'une implémentation sur un VM/ClassLoader donné.

Alors est-ce vrai? ne peut pas 2 implémentations Xalan "live" dans le même System ClassLoader? Ou s'ils le peuvent, Comment?

Answer 1

Cela semble être la réponse surprenante:

Pour chaque implémentation Xalan utiliser un séparé classloader, et ajouter un fichier dans

META-INF\services\ appelé

javax.xml.transform.TransformerFactory 

Modifier et mettre c'est seulement le contenu l'implémentation Xalan que le chargeur de classe utilisera, par exemple:

com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl 

NOTE: La belle chose ici est que opposé à la délégation de chargement de classe régulière, META-INF\services est recherché dans la classe actuelle chargeur premier, alors que les classes sont en cours de recherche dans le parent, le système, et seulement alors dans le classloder d'enfant

Answer 2

Il existe une version de xalan incluse dans le fichier jdk. Pour la plupart des usages, mon expérience personnelle est que l'utilisation de cette version est suffisante. Même s'il pourrait s'agir d'une version précédente, y a-t-il un nouveau développement de xalan de nos jours? Je préfère utiliser la version incluse, fortement testée.

Je ne pense pas avoir à transformer xsl dans le même jdk est une bonne idée (même si je suppose que cela peut être fait). Si vous avez vraiment besoin d'utiliser une version mise à jour de xalan, au lieu du jdk un, vous pouvez referer à cette FAQ: http://xml.apache.org/xalan-j/faq.html#faq-N100EF

Je dépouillèrent toutes les dépendances xalan spécifiques dans les grandes applications, en utilisant seulement une embarqué. Les bibliothèques comme FOP, bien qu'elles prétendent avoir besoin d'un jar xalan spécifique, fonctionnaient très bien sans cela, et résolvaient beaucoup de problèmes de chargement de classes (java ee app serveur posant des problèmes dans certaines situations quand xalan était empaqueté).