It's not nice, but a possible way to do this might be by manipulating the
classpath.
For now, the jar with the jboss URLClassLoader is first, and when sun bring
out a fix you just switch the entry in the classpath. Not nice but pretty
common place.
-----Original Message-----
From: Jung , Dr. Christoph [mailto:[EMAIL PROTECTED]]
Sent: 13 February 2001 10:35
To: 'jBoss Developer'
Subject: AW: [jBoss-Dev] Re: [jBoss-User] File locking problems on
deploym ent
-----Ursprüngliche Nachricht-----
>Von: Rickard Öberg [mailto:[EMAIL PROTECTED]]
>Gesendet: Dienstag, 13. Februar 2001 09:36
>An: jBoss; jBoss Developer
>Betreff: [jBoss-Dev] Re: [jBoss-User] File locking problems on
>deployment
>To jboss-dev:
>I propose to copy/paste the URLClassLoader source, and fix it so that
>the cache is flushable, hence removing this silly problem.
I agree with you that the SUN source is less than sub-optimal (and this does
not only count for URLClassLoader). Would this make the "copying to
temporary jar" redundant (after undeploy, the file should be unlocked,
right)?
But since java.net.URLClassLoader is ubiquitous to the source, this would
require a lot of reference changes, doesn´t it? And going the way back when
SUN fixed this issue (ok, maybe we just have a minimal chance) would be,
again, a pain in the ass.
What is specific to URLClassLoader that is often needed and that is not
already specified in java.lang.ClassLoader? If it is not much (addUrl(URL)
maybe one of these things?), I would propose, to replace all URLClassLoader
references by java.lang.ClassLoader and to implement the lacking stuff by
some static abstract like a org.jboss.util.ClassLoaders(.addUrl(ClassLoader
loader, URL url)) to keep the knowledge about which detailed classloader
implementation we currently use local.
Just my EUR0.02 (which is unfortunately quite worthless at the moment ;-)
CGJ
