As mentioned above, the web application class loader diverges from the default Java 2 delegation model (in accordance with the recommendations in the Servlet Specification, version 2.3, section 9.7.2 Web Application Classloader). When a request to load a class from the web application's WebappX class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking. There are exceptions. Classes which are part of the JRE base classes cannot be overriden. For some classes (such as the XML parser components in J2SE 1.4+), the J2SE 1.4 endorsed feature can be used. Last, any JAR containing servlet API classes will be ignored by the classloader. All other class loaders in Tomcat 6 follow the usual delegation pattern.

ranophoenix wrote:
Às vezes utilizo isso na prática. Algumas versões de biblioteca ficam no lib (comum a todos os projetos), porém de repente algum projeto precisa de uma versão diferente da biblioteca, daí nesse projeto vai a versão que ele precisa pra funcionar. Pelo que entendi lendo o capítulo do livro isso não seria possível, ou pelo menos seria muito arriscado, mas na prática (pelo menos nos containers Web que conheço) não é assim que funciona. O Classloader da aplicação sempre irá procurar a classe nos repositórios locais, com algumas exceções como na citação acima, e somente depois delegará para os outros classloaders.

Paulo Silveira wrote:

ranophoenix wrote:
Às vezes utilizo isso na prática. Algumas versões de biblioteca ficam no lib (comum a todos os projetos), porém de repente algum projeto precisa de uma versão diferente da biblioteca, daí nesse projeto vai a versão que ele precisa pra funcionar. Pelo que entendi lendo o capítulo do livro isso não seria possível, ou pelo menos seria muito arriscado, mas na prática (pelo menos nos containers Web que conheço) não é assim que funciona. O Classloader da aplicação sempre irá procurar a classe nos repositórios locais, com algumas exceções como na citação acima, e somente depois delegará para os outros classloaders.

Ola

Voce tem razao: a maioria dos containers "novos" ja vao fazer corretamente o uso de diretorios common, shared, etc. Na minha epoca o tomcat usava o modelo tradicional, sem tentar fazer um "flat", que so comecou a partir do 3.3:
http://mail-archives.apache.org/mod_mbox/cocoon-dev/200009.mbox/<39CFF2AA.8D474DD7@eng.sun.com>

Infelizmente o problema com a variavel de ambiente CLASSPATH é independente do container e de qual versao do container. Sem duvida é bom deixar isso claro, e talvez entao so deixar o exemplo da variavel de ambiente, ja que os containers atuais devem todos estar aginda da maneira "correta" (valeria pesquisar). O que acha? Mesmo que todos estejam ok, é bom deixar o alerta.

Fico muito agradecido por um comentario tao detalhado e oportuno como este!

Paulo Silveira wrote:
Nao se esqueca que o titulo do livro possui a palavra design, nao só arquitetura, e damos bastante atencao a isso tambem. Bem que "GUJ 10 anos" tambem seria bom .

Pessoal, fica aqui tambem o agradecimento a todos que tem enviado email pro autores@arquiteturajava.com.br com as correções, sugestões e idéias para outros tópicos. O feedback tem sido grande.

Drico wrote:Olá Paulo, Sérgio e demais autores.

Primeiramente gostaria de parabenizá-los pela iniciativa. É sempre bom ver que existem pessoas dispostas e principalmente interessadas a ajudar a comunidade.

Não sou nenhum expert da língua portuguesa, muito menos um chato que reclama de tudo, mas, como vocês pediram por sugestões e críticas, me achei no direito de lhes informar que seria interessante dar uma boa revisão no texto, pois existem alguns errinhos de concordância e de pontuação em algumas frases. Nada de grave, mas como é um livro que com certeza será de grande valia para a comunidade, acredito que seja algo que mereça ser revisto.

Até mais e continuem com o bom trabalho!