|
|This sounds trickier than just using our own classloader in the relevant
|places (we're talking about 3-4 places).
|
remember kids,
Low Tech == Good Tech (c) 2001, The JBoss Group
PL and lT
marc
|regards,
| Rickard
|
|>
|> -----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
|
|--
|Rickard Öberg
|
|Email: [EMAIL PROTECTED]
|
