Thanks Yoav
I have solved my issue with this really helpfull explanation
Regards,
Eliezer E Chavez
Gcia. Sistemas Riesgo y Workflow
V.P. Administracion de Datos
Banco de Venezuela - Grupo Santander
Telf. +58-(212)-5012480
mail. [EMAIL PROTECTED]
"Shapira, Yoav"
<[EMAIL PROTECTED] Para: "Log4J Users List" <[EMAIL
PROTECTED]>
om> cc:
Asunto: RE: Problems with my
classpath?
03/26/2004 10:03 AM
Por favor, responda
a "Log4J Users
List"
Hi,
Not quite. I normally would let this go, but this is such an important
issue and we see so many problems related to it ;) Additions
interspersed.
>ClassNotFoundException means that you were trying to dynamically load a
>class at runtime using something like
>Class.forName("com.mycompany.MyClass") and the class couldn't be found.
That's one way to get it: another is if the container tries to load a
class and it's not found anywhere on the classpath.
>NoClassDefFoundError can be caused by a couple different things:
>
>1. An import in the class being loaded cannot be found
No, this is a ClassNotFoundException under nearly all circumstances.
(Used to be ALL circumstances, but with AOP and bytecode manipulation
now you can get really hairy corner cases).
>2. The class being loaded which existed at compile time is now not
found
>at runtime.
Not quite, and since this is the most common I'll clear it up: a class
matching the fully-qualified class name was found by the classloader,
but does not provide the same interface accessibility as the class by
the same name that was present at compile time. For example, the class
at runtime is missing a method that was present at compile time, or had
a public method changed to private. This is what happens, for example,
if you compile classes with the servlet 2.4 API and use a servlet 2.3
jar at runtime.
>A third possibility might be that there are multiple versions of log4j
>being loaded by different classloaders, but I'm not totally confident
that
>I can describe exactly how this results in a NoClassDefFoundError.
>
>If Log4j is actually in this user's classpath, then I would suspect the
>third case. Yoav, maybe you can explain that third case a bit better
for
>us?
Sure. And this is general, there's nothing here specific to log4j.
When you have multiple versions of the same libraries (fully-qualified
class names is what matters: jar names do not), the loading order
becomes relevant. For example, if he has an old copy in
$JAVA_HOME/jre/lib/ext (or any other directory designated as 'endorsed'
in the java command line), and a more recent copy in his webapp's
WEB-INF/lib folder, the older copy will get loaded first by J2EE
containers (and subsets therefore, e.g. servlet containers). Because he
compiled against the version in WEB-INF/lib, he gets a
NoClassDefFoundError at runtime, as the version he compiled against
doesn't match the version found at runtime.
This is evil in certain ways: for example, it might not be the user who
placed the copy in $JAVA_HOME/jre/lib/ext. It may have been a sysadmin,
another developer, another user, etc, and now it's forgotten.
The solution is not difficult: carefully scan the entire classpath for
multiple versions of the library that's throwing a NoClassDefFoundError.
Remove all copies except the one you want. Keep your classpath and
environment as clean as possible, no extra jars.
Sometimes there are complications, such as when users run on a container
that provides a shared classloading facility (JBoss, Tomcat, others).
It is nearly always in the user's best interest to not use this
facility, but instead stick to the specification and bundle all needed
libraries for his/her application in a WAR/EAR file. Alternatively, the
container should provide documentation regarding loading order and
classloader delegation.
I could go on further into the actual permanent generation meaning of
the NoClassDefFoundError (which is suboptimally named IMHO), but I'll
stop here ;)
Yoav Shapira
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary and/or privileged. This e-mail is intended only for the
individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else. If you are not the(an) intended
recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
***************AVISO LEGAL***************
Este mensaje es privado y confidencial, y està dirigido exclusivamente a su(s)
destinatario(s). Si usted ha recibido este mensaje por error, debe abstenerse de
distribuirlo, copiarlo o usarlo en cualquier sentido. Asimismo, le agradecemos
comunicarlo al remitente y borrar el mensaje y cualquier documento adjunto.
Cualquier opiniÃn contenida en este mensaje pertenece Ãnicamente al autor remitente
y no representa necesariamente la opiniÃn del Banco de Venezuela, a menos que ello se
seÃale en forma expresa.
Eventualmente, los correos electrÃnicos pueden ser interceptados o alterados, llegar
con demora o incompletos. Al respecto, el Banco de Venezuela no se hace responsable
por los errores, defectos u omisiones que pudieran afectar al mensaje original, con
motivo de su envÃo por correo electrÃnico.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
