| 1 |
I am looking into if there were any changes with log4j between 1.2.12 |
| 2 |
and 1.2.13. The official Tomcat binary is compiled with 1.2.12, and we |
| 3 |
are compiling against 1.2.13. |
| 4 |
|
| 5 |
I am not even sure Tomcat is using it at all during compile, and has |
| 6 |
little to no need for it at runtime. Aside from custom apps. There could |
| 7 |
be a possibility of custom log4j apps needing to be ported from 1.2.12 |
| 8 |
to 1.2.13. I am trying to hunt down a change log or etc to find out what |
| 9 |
changed or etc. |
| 10 |
|
| 11 |
Another possibility. With Tomcat's classpath loader and all, and use of |
| 12 |
JULI now. It might be possible Tomcat is finding part of what it's |
| 13 |
looking at further up the chain like in the bootstrap classpath. Since |
| 14 |
it's finding part, it's running with that there, instead of looking for |
| 15 |
the rest or another similar version further down the classpath chain. |
| 16 |
|
| 17 |
Really no clue, really weird, and I am looking into. I did research |
| 18 |
extensively in the past with upstream as to what could cause the problem |
| 19 |
and a possible solution. However previous problem was more on the lines |
| 20 |
of crashing from memory, than from cnfe. |
| 21 |
|
| 22 |
-- |
| 23 |
Sincerely, |
| 24 |
William L. Thomson Jr. |
| 25 |
Obsidian-Studios, Inc. |
| 26 |
http://www.obsidian-studios.com |
| 27 |
|
| 28 |
-- |
| 29 |
gentoo-java@g.o mailing list |
Archives