On Mar 16, 2008, at 10:57 AM, Alan D. Cabrera wrote:
On Mar 16, 2008, at 10:45 AM, Dain Sundstrom wrote:
I believe I have finally fixed the Windows file lock problems.
After extensive debugging and inspection of heap dumps, I am
convinced the Windows file handling in the Sun VM is simply
broken. I tried a few of solutions, but the only one that works
reliably is to copy all jar files to a temp location before adding
them to a class loader. This is the approach Tomcat takes when you
enable antJARLocking in an application.
OpenEJB's AntiJarLocking is enabled only when running on Windows
and only when not in embedded (test) mode. When embedded
AntiJarLocking is simply not needed because jars are not deleted
which means there is no file locking problem. AntiJarLocking can
be explicitly controlled by setting the case-insensitive System
property "antiJarLocking". When running non-embedded the temp
files are stored in $openejb.base\temp, and in embedded mode they
are stored in $java.io.tmpdir/OpenEJB-temp-RANDOM (but you
shouldn't turn this on in embedded mode).
If you are on Windows, please give this a try. I think it is
critical to the success of this project to have flawless Windows
support.
Very interesting. I noticed that you placed this in the OpenEJB
classloader. I was wondering if it would be better placed in XBean
classloader so that other projects may benefit.
Yes, but I don't want to mess with xbean-classloader right now :)
While we're on the topic, why does OpenEJB have its own classloader?
Read the latest patch again. We don't have our own class loader. We
have a utility that copies all for the jar files to a temp directory,
and then we create a normal URLClassLoader using the cached URLs.
-dain
