Hey
"Jung , Dr. Christoph" wrote:
> >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)?
Yes and no. Depends. If the file connection is cached while it's
deployed, then the tmp-copy is still needed. If the connection is closed
on each usage, then it would be possible to skip the tmp-copy.
I would definitely recommend using the tmp-copy technique though, since
it is much safer.
> 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.
Yes, it would be very painful. Doing search/replace on URLClassLoader to
FixedClassLoader will probably take, well maybe a minute. Noone probably
has the time to do that soo....
;-)
> 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.
UCL does security properly, treats the Class-Path header properly, and
some other stuff. It is needed.
Although I guess we could just copy/paste the relevant parts from UCL to
get that. But no need to abstract this. Search/replace is just fine.
regards,
Rickard
--
Rickard Öberg
Email: [EMAIL PROTECTED]
