Hi,
a little clarification regarding the lib/ext issue ...
> * NOTE-ALSO: If using any JDK 1.2+ or higher, you must
> also check your
> /lib/ext or extensions directory for copies of the
> above files, since they
> are 'magically' included in the beginning of your
> classpath. To get rid of
... not exactly. They are loaded by a separate
classloader, the extension classloader, which
sits inbetween the bootstrap classloader and the
classpath classloader. This is why they can't be
seen in the classpath -- they really aren't there.
This also has a dangerous implication: classes
loaded in the extension classloader can't see
classes loaded in the classpath classloader --
so if an extension class tries to instantiate
(or even load) a class that isn't found by the
extension or bootstrap classloader, it fails.
Even if the class is in the classpath. See
http://java.sun.com/docs/books/tutorial/ext/basics/load.html
for a clear, and very concise, explanation of
this mechanism.
> files in your extensions directory, you must delete
> them or move them out
> of the directory - simply renaming them will *not*
> work (maybe: rename the
> extension to not be .jar, but I haven't tested this).
That does work.
> Scott Boag added: "Go to the JDK 1.2+'s lib\ext
> directory. Remove
> crimson.jar, and any other jar
> that may have JAXP interfaces.
Or, if you really need those jars, a lot of the time
you can get away with removing the JAXP stuff from
them (as long as it's reachable in some other jar)
to get rid of versioning problems.
> lib\ext is a "magic" directory that loads
> all the jars in there in front of the classpath. So
> you don't see them,
> and the *only* solution is physical removal.
Not quite ... you can also set the system property
java.ext.dirs to something else at startup with the
-D switch. By default it is this lib/ext directory,
but if you set it to some other directory (e.g. your
own, or a non-existent one), then extensions are
under your control.
> Users who are upset about this as I am should write a
> note to Sun asking
> them to fix the lib\ext mechanism. This is totally
> broken."
Nah, it's just not being used right. The extension
idea is not without merit, particularly for more
stable-versioned libs (e.g. Java3D or such), that are
really meant to be extensions to the Java platform.
It just needs to be used carefully -- and in my view
NOT used for code that is still undergoing development
and frequent change, especially shared APIs. You often
need to deal with this however, especially in servlet
environments, so you need to be familiar with the
problem.
(My own lib/ext is religiously kept empty though! :)
Hope that's useful,
- Gulli
---
Gunnlaugur Thor Briem
Dimon Software, Inc.
"Hmm ... think it might be a classloader problem?"
