Quels sont les inconvénients de définir l'ordre de chargement des classes pour privilégier les classes de l'application dans une application Java EE ?

Question

Sur mon serveur d'applications WebSphere 8, l'ordre de chargement des classes par défaut est le suivant parent_premier (essayez de charger à partir du chargeur de classes du serveur d'applications, puis seulement à partir du chargeur de classes de l'EAR).
Cela crée une collision entre l'utilisation de HttpClient d'Apache par mon application et l'utilisation interne de WebSphere.
J'envisage de changer l'ordre de chargement pour parent_dernier ( prefer-web-inf-classes dans WebLogic).

Quels sont les pièges à éviter lors de l'inversion de l'ordre de chargement des classes d'une application Java EE en parent_dernier ?

Answer 1

Il ne devrait pas y en avoir.

Le site PARENT_LAST permet à votre application de distribuer des classes et des jars qui, autrement, entreraient en conflit avec ceux de WebSphere. Ce paramètre est utilisé lorsque ClassClassException se produit lorsque deux chargeurs de classe incompatibles différents chargent une classe qui se trouve dans WebSphere AS et dans votre application.

Les modes du chargeur de classes - PARENT_FIRST et PARENT_LAST - sont décrites dans Chargeurs de classes dans le centre d'information de WebSphere Application Server 8.0 .

Les gens ont tendance à regrouper les jars dans les applications, ce qui rend le déploiement plus long, la consommation de mémoire plus élevée et l'administration (des bibliothèques) plus difficile.

Il est évidemment plus facile pour les développeurs de tout garder au sein d'une application afin de ne pas avoir à décrire ce que l'administrateur doit mettre en place en ce qui concerne les bibliothèques partagées (ou les dépôts OSGi).

Je ne peux pas penser à un cas où PARENT_LAST est utile, sauf si l'on considère que la distribution de jars au sein d'une application est une bonne chose (je ne suis pas d'accord avec ce point).

Moins il y a de pots dans une application, mieux c'est :

1. l'application pourrait bénéficier d'une mise à jour de ses pots lorsqu'un problème est résolu via des bibliothèques partagées ou des dépôts OSGi, ce qui faciliterait sa maintenance.
2. les applications peuvent partager des bibliothèques, ce qui réduit les attentes en matière de mémoire et favorise la réutilisation (le déploiement est évidemment plus rapide).

Il existe probablement d'autres raisons de ne pas regrouper les bocaux au sein d'une application, qui diminueraient encore l'efficacité de l'application. PARENT_LAST le paramètre de configuration.

S'en tenir à PARENT_FIRST jusqu'à ce qu'ils vous disent qu'ils ont une raison de changer, et quand cela arrive, vous leur montrez la réponse ;-)

Answer 2

De Comprendre le kit de développement logiciel IBM (SDK) pour Java > Chargement des classes :

[Le modèle de délégation] empêche le code provenant de sources moins fiables de remplacer classes de l'API de base fiables en prenant le même nom qu'une partie de l'API de base. DE BASE.

Donc, PARENT_LAST semble exister pour les cas où une application doit surcharger une classe de base en raison d'incompatibilités de versions, mais cela signifie que cela pourrait également affaiblir la sécurité.