Comment Fool l'API Java Service Provider (JAXP)

Question

J'ai une applet qui doit appeler JAXP, en particulier SAXParserFactory . Maintenant, comme vous pouvez le voir sur la Javadoc, celui-ci utilise en interne le mécanisme du fournisseur de services tel que documenté :

Plus précisément, si elle ne trouve pas un fichier dans l'un de mes JARs application appelée META-INF/services/javax.xml.parsers.SAXParserFactory il va essayer de chercher dans ma base de code d'application. Si j'ai mon applet déployée comme suit:

<applet code="com.example.applets.MyApplet" 
 codebase="http://www.example.com/myapp/" archive="myapp.jar, dom4j.jar">

Ensuite, il va essayer de faire une requête HTTP à http://www.example.com/myapp/META-INF/services/javax.xml.parsers.SAXParserFactory

Je préfère ce pas le faire, en particulier parce que mon applet est signé et cet appel HTTP supplémentaire déclenche un avertissement sur code non signé .

Maintenant, la solution évidente est de mettre juste le fichier META-INF / services dans mon application JAR comme il est dit, mais comment puis-je faire encore comprends toujours à utiliser JRE l'implémentation par défaut de JAXP de l'utilisateur? Sinon, est-il un moyen de convaincre l'exécution de l'applet pour regarder que dans mes fichiers JAR et non dans le codebase pour ce fichier?

Note:. Je sais que je pourrais aussi déployer ma propre copie de JAXP-RI, mais c'est assez lourd poids pour une applet

Answer 1

Désactiver la recherche codebase:

<applet ...>
 <param name="codebase_lookup" value="false">
</applet>

Les contrôles de AppletClassLoader pour un sun.applet.AppletClassLoader.codebaseLookup de propriété booléenne, qui peut être influencé en définissant le paramètre ci-dessus. La méthode sun.applet.AppletPanel.init() lit le paramètre et le mettre dans le AppletClassLoader. Une fois désactivé, le AppletClassLoader cessera de recherches à distance pour les classes et les ressources du code de base, qui est l'URL donnée par codebase="http://www.example.com/myapp/" et seulement regarder dans les archives et les chemins de classe système.

Note: Je n'ai pas testé moi-même, je crois sincèrement, mais selon la révision du code dans le code désassemblé il pourrait fonctionner

.

Il est également documenté dans JavaSE - Notes techniques - Plugin Guide du développeur - Attributs spéciaux :

  

codebase_lookup

     

Lorsque l'applet classloader a besoin de charger une classe ou d'une ressource (par exemple, les fichiers de configuration pour les fournisseurs de services connectables dans le répertoire META-INF / services), il recherche d'abord les fichiers requis dans les fichiers JAR de l'applet et de la codebase applet. En règle générale applets sont déployés avec toutes les classes et les ressources nécessaires stockées dans les fichiers JAR de l'applet. Dans ce cas, la recherche de base de code est inutile.

     

Si la classe ou ressources ne sont pas disponibles à partir des fichiers JAR de l'applet, il peut être préférable d'avoir le classloader fail plutôt que de tenter une recherche de base de code. Dans le cas contraire, une connexion doit être faite à la base de code applet pour rechercher la classe ou de la ressource, et il peut avoir un impact sur les performances du moteur d'exécution de l'applet.