Hi
-----Ursprüngliche Nachricht-----
>Von: Rickard Öberg [mailto:[EMAIL PROTECTED]]
>Gesendet: Dienstag, 13. Februar 2001 13:03
>An: jBoss Developer
>Betreff: Re: AW: [jBoss-Dev] Re: [jBoss-User] File locking problems
>ondeploym ent
>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 thought on something like: when the classloader is garbage-collected (or
even
called a dedicated finalize() explicitely), the yet open file connections
are closed
>I would definitely recommend using the tmp-copy technique though, since
>it is much safer.
maybe.
>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....
>;-)
But you couldn´t do search and replace in external stuff, like Tomcat
sources, could you? Then you have to provide some URLClassLoader wrapper
around the FixedClassLoader (the usual parent solution) which makes search
and replace not soo trivial ... or do I miss here something.
Maybe this wrap-thing could avoid replacing the references anyway.
>UCL does security properly, treats the Class-Path header properly, and
>some other stuff. It is needed.
It is clear that we need the UCL code at least at classloader construction
time. The question was whether we shouldn´t pass the references as
"java.lang.ClassLoader"
afterwards (at least it would show us places where we heavily depend on
URLClassLoader and where not)?
>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.
IMHO not (see above), but I´m myopic anyway.
Best,
CGJ
