Comment puis-je savoir qui JAXP mise en œuvre est en cours d'utilisation et où il a été chargé à partir de?

Je tiens à fournir des informations de diagnostic sur ce JAXP mise en œuvre est en cours d'utilisation, et le fichier JAR, il a été chargé de.

Une façon d'y parvenir est de créer une instance de l', par exemple, un DocumentBuilderFactory, et ensuite de vérifier les propriétés de cette classe:

private static String GetJaxpImplementation() {
    DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
    Class<? extends DocumentBuilderFactory> c = documentBuilderFactory.getClass();
    Package p = c.getPackage();
    CodeSource source = c.getProtectionDomain().getCodeSource();
    return MessageFormat.format(
            "Using JAXP implementation ''{0}'' ({1}) version {2} ({3}){4}",
            p.getName(),
            p.getImplementationVendor(),
            p.getSpecificationVersion(),
            p.getImplementationVersion(),
            source == null ? "." : " loaded from: " + source.getLocation());
}

Est-il un meilleur moyen pour y parvenir, peut-être sans avoir à créer une DocumentBuilderFactory?

InformationsquelleAutor Daniel Fortunov | 2009-11-25

56

Il est assez difficile de prédire ce que le béton JAXP usine de mise en œuvre sera chargé sans réellement la création d'une instance, car le processus de sélection d'une mise en œuvre.

De la Officiel JAXP FAQ (Question 14):
Quand une application veut créer un
nouveau JAXP DocumentBuilderFactory
exemple, il appelle la méthode staic
DocumentBuilderFactory.newInstance().
Cela provoque une recherche pour le nom d'un
béton sous-classe de
DocumentBuilderFactory à l'aide de la
ordre suivant:
1. La valeur d'un système de propriété comme javax.xml.parsers.DocumentBuilderFactory si elle existe et est accessible.
2. Le contenu du fichier $JAVA_HOME/jre/lib/jaxp.properties si elle existe.
3. Le Pot Fournisseur de Services de mécanisme de découverte spécifié dans le Fichier Jar de Spécification. Un fichier jar peut avoir une ressource (par exemple, un fichier incorporé) comme META-INF/services/javax.xml.parsers.DocumentBuilderFactory contenant le nom de la classe à instancier.
4. De secours plate-forme par défaut de la mise en œuvre.
Ajouter à cette complexité, chaque individu JAXP usine peut avoir une implémentation indépendante spécifié. Il est courant d'utiliser un analyseur de mise en œuvre et une autre XSLT mise en œuvre, mais la granularité du mécanisme de sélection ci-dessus vous permet de mélanger et assortir à un degré encore plus élevé.

Le code suivant affichera des informations sur les quatre principaux JAXP usines:
```
private static void OutputJaxpImplementationInfo() {
    System.out.println(getJaxpImplementationInfo("DocumentBuilderFactory", DocumentBuilderFactory.newInstance().getClass()));
    System.out.println(getJaxpImplementationInfo("XPathFactory", XPathFactory.newInstance().getClass()));
    System.out.println(getJaxpImplementationInfo("TransformerFactory", TransformerFactory.newInstance().getClass()));
    System.out.println(getJaxpImplementationInfo("SAXParserFactory", SAXParserFactory.newInstance().getClass()));
}

private static String getJaxpImplementationInfo(String componentName, Class componentClass) {
    CodeSource source = componentClass.getProtectionDomain().getCodeSource();
    return MessageFormat.format(
            "{0} implementation: {1} loaded from: {2}",
            componentName,
            componentClass.getName(),
            source == null ? "Java Runtime" : source.getLocation());
}
```
L'exemple de sortie suivant illustre un mix-and-match de trois différents JAXP implémentations (Intégré dans Xerces et externes Pots pour Xerces 2.8 et Xalan) de travailler ensemble:
```
DocumentBuilderFactory implementation: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl loaded from: file:/C:/Projects/Scratch/lib/xerces-2.8.0.jar
XPathFactory implementation: com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl loaded from: Java Runtime
TransformerFactory implementation: org.apache.xalan.processor.TransformerFactoryImpl loaded from: file:/C:/Projects/Scratch/lib/xalan.jar
SAXParserFactory implementation: org.apache.xerces.jaxp.SAXParserFactoryImpl loaded from: file:/C:/Projects/Scratch/lib/xerces-2.8.0.jar
```
InformationsquelleAutor Daniel Fortunov
9

Juste ajouter
```
-Djaxp.debug=1
```
à JAVA_OPTS et vous permettra de voir de telles informations.

Pour plus de détails: https://docs.oracle.com/javase/7/docs/api/javax/xml/parsers/DocumentBuilderFactory.html

InformationsquelleAutor trang
4

c'est facile, il suffit de fixer
```
System.setProperty("jaxp.debug", "1");
```
la piste sera vous dire où impl,et auquel façon jaxp utilisation.

InformationsquelleAutor zg_spring
1

Il dépend, mais généralement pas.

DocumentBuilderFactory.newInstance() renvoie à la mise en œuvre de DocumentBuilderFactory qui est configuré dans le système de la propriété "javax.xml.les parseurs.DocumentBuilderFactory" ou le JRE d'usine par défaut si le système de propriété n'est pas définie. La valeur par défaut de l'usine est le plus susceptible codées en dur dans la mise en œuvre de la méthode newInstance et pas autrement accessibles.

Si le système de la propriété est définie, vous pouvez au moins utiliser la méthode getResource sur le chargeur de classe pour obtenir l'URL, à partir de laquelle le chargeur de classe serait de charger le fichier de classe correspondante. Si c'est à partir d'un fichier jar, vous devriez être en mesure d'extraire le nom du fichier (ou URL de la source) à partir du pot: l'URL. Les informations détaillées du paquet devrait également être disponible si vous manaully lire les méta-données des fichiers depuis le classpath.

Si le système de propriété n'est pas définie, je suis sûr que vous n'avez aucun moyen d'obtenir les informations que vous recherchez sans pour autant créer une nouvelle usine que vous êtes déjà en train de faire.

InformationsquelleAutor jarnbjo
1

Il y a un autre endroit qui est recherchée avant le "secours plate-forme par défaut de la mise en œuvre" et qui est le java.endorsed.dirs répertoire comme indiqué dans le Java A Approuvé Les Normes De Remplacer Le Mécanisme De

L'a Approuvé les Normes de Remplacer le Mécanisme fournit un moyen par lequel les versions ultérieures de classes et d'interfaces qui mettent en œuvre Approuvé les Normes ou Autonome Technologies peuvent être intégrées à la Plate-forme Java.
- Qui est BTW obsolète depuis 8u40, vous pouvez vérifier si elle est toujours utilisée avec -XX:+CheckEndorsedAndExtDirs.
InformationsquelleAutor jwd630

Vous devez vous connecter pour publier un commentaire.