Fixed the bug. ClassFinder is leaking file locks. I coded around it
for now.
-dain
On Mar 16, 2008, at 11:23 AM, Karan Malhi wrote:
Dain,
Tried a Standalone ejb jar. It does not work i.e. look at the
following for
a file named good.jar
D:\temp>openejb deploy -u good.jar
Application deployed successfully at "good.jar"
App(id=D:\temp\openejb-3.1-SNAPSHOT\apps\good.jar)
EjbJar(id=good.jar, path=D:\temp\openejb-3.1-SNAPSHOT\apps
\good.jar)
Ejb(ejb-name=PenImpl, id=PenImpl)
Jndi(name=PenImplLocal)
D:\temp>openejb undeploy d:\temp\openejb-3.1-SNAPSHOT\apps\good.jar
Application was undeployed from the runtime server but could not be
deleted
from the file system and will have to be deleted by hand:
D:\temp>openejb deploy -u good.jar
Application already deployed at "D:\temp\openejb-3.1-SNAPSHOT\apps
\good.jar"
On Sun, Mar 16, 2008 at 1:45 PM, Dain Sundstrom <[EMAIL PROTECTED]> 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.
Thanks,
-dain
--
Karan Singh Malhi
