We had the same problem. After some investigation, we narrowed it down to the url.openStream() method in the read(URL url, ClassLoader classLoader) method of the XMLEntityMappingsReader class.
On Windows, if url represents a file in a jar, the url.openStream() method locks this jar until process quits. It’s somewhat known issue with a workaround. I found a nice description of it here:
http://article.gmane.org/gmane.comp.jakarta.hivemind.user/2017
So, replacing the following two lines in the read(URL url, ClassLoader classLoader) method in the XMLEntityMappingsReader class
reader1 = new InputStreamReader(url.openStream(), "UTF-8");
reader2 = new InputStreamReader(url.openStream(), "UTF-8");
with these four lines:
URLConnection connection = url.openConnection();
connection.setUseCaches(false);
reader1 = new InputStreamReader(connection.getInputStream(), "UTF-8");
reader2 = new InputStreamReader(connection.getInputStream(), "UTF-8");
and rebuilding eclipselink.jar, solved the problem for us. Now, I don’t have to undeploy my project, stop glassfish, manually delete the JPA jar file, restart glassfish and redeploy my project every time I change something in the JPA layer.
I still have no idea why it was giving us FileNotFound exception though.
[Message sent by forum member 'imotov' (imotov)]
http://forums.java.net/jive/thread.jspa?messageID=303069