sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sdx-users] Tomcat 5.5.12


From: Frédéric Glorieux
Subject: Re: [sdx-users] Tomcat 5.5.12
Date: Sat, 29 Oct 2005 11:32:20 +0200
User-agent: Thunderbird 1.4 (Windows/20050908)


> Au passage, Jetty fonctionne très bien et est plus léger :-)

Oui :o)
Je l'utilise beaucoup en dev.
Mais pour une livraison, avoir un administrateur tomcat est déjà si bien...

Un détail, j'ai essayé de passer à jetty 5 il y a quelques semaines (espérant un meilleur support de l'UTF-8), j'ai eu quelques problèmes justement de ce côté. Je remarque que cocoon trunk est toujours en jetty 4 ?

> Plus d'infos sur
> http://tomcat.apache.org/tomcat-5.0-doc/class-loader-howto.html

Excellente référence, en effet, merci beaucoup.

Merci beaucoup pour ce rappel.

Est-ce qu'il y a une raison pour laquelle ce n'est pas en défaut cocoon?

Parce que ce n'est pas le comportement standard d'un servlet. Dans certains environmments, le SecurityManager mis en place par le serveur d'application peut interdire à une appli web de créer un classloader.

Par ailleurs, le paranoid classloader peut conduire à des ClassCastException si certaines classes doivent être partagées entre l'appli web et son environnement (le serveur lui-même ou d'autres applis sur le même serveur). La solution est dans ce cas de retirer les classes communes de WEB-INF/lib et de les placer dans une zone commune (comme le répertoire shared dans Tomcat).

Je trouve assez logique que les lib locales priment et surchargent tomcat et la JVM. Mais peut-être qu'il y a d'autres logiques d'administration tomcat, comme par exemple considérer qu'un administrateur Tomcat mette à jour des libs centralisées et surcharge tout ce qu'il a dans ses webapp ?

La spécification servlet dit que le serveur d'application doit chercher dans WEB-INF d'abord *sauf* pour java.* et javax.*. Le souci, c'est que javax.* n'est pas seulement constitué par le JDK, mais aussi par des librairies tierces (notamment xml-apis.jar) dont on peut vouloir une version plus récente.

Et Tomcat fait une entorse à cette règle, puisqu'il ajoute à la recherche dans les classloader communs org.apache.xerces.* et org.apache.xalan.*, ce qui ignore effectivement les versions de Xalan et Xerces qui sont dans l'appli web!!!



Sylvain



--
Frédéric Glorieux (AJLSM, http://ajlsm.com)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]