Rickard �berg wrote: R�> Rickard �berg wrote: >> Hm.. wwwait a minute.. I know what it is :-( We copy jars on deploy so >> that we can undeploy and redeploy without getting file access problems. >> The copy in the tmp dir is not in the same place as the original jars, >> so the references break. >> >> Damn. Knew this would come some day. So, if we don't copy the references >> work, and if we copy the references break. >> >> Either: >> 1) Don't copy and try to do read-only ClassLoading from it >> 2) Copy, but check the jar and add the Class-Path manifest header >> references to the EJB classloader >> >> 2) is fairly simple and would work. However, if we could get around the >> need to copy to tmp that would be better. >> >> Comments? R�> Alright, you had your chance. Too late. I have now implemented 2). It is R�> in CVS. :-) :-) Yes, I am late. I have other solution, but now it must die. You are so fast... But are you sure, that it works? It has just thrown an exception on deployment in my test. And some critics: 1) The "tmp" dir is created on startup and remains empty, because the jars are copied to %TEMP% dir. Is it some other purpose for the "tmp" dir? 2) The copies of the jars are not deleted on shutdown. It looks like deleteOnExit() doesn't work. "Deletion will be attempted only for normal termination of the virtual machine, as defined by the Java Language Specification (12.9)" What does they mean? Something other than Ctrl+C? Explicit System.exit()? Now the %TEMP% dir is infinitely growing. Maybe, it would be better to copy jar to "tmp" dir and to empty it in a shutdown hook? In the case of abnormal termination of JVM users would be able to empty it manually. Best regards, Oleg
