I have changed DeploymentUtil.toTempFile(URL url) and
DeploymentUtil.readAll(URL
url) to use JarFile.getInputStream() instead of URL.openStream() when the
protocol is jar. But, the other code the uses URL.openStream() still
leaves locks on the jar files which prevent immediate deletion of temp
I see the following in Deployer.java
// todo jar url handling with Sun's VM on Windows leaves a lock
on the module file *preventing rebuilds*
// to address this we use a gross hack and copy the file to a
temporary directory
// the lock on the file will prevent
On Jan 23, 2008, at 5:23 AM, Vamsavardhana Reddy wrote:
I see the following in Deployer.java
// todo jar url handling with Sun's VM on Windows leaves
a lock on the module file preventing rebuilds
// to address this we use a gross hack and copy the file
to a
Kevan,
I am testing this with an ear file. So, the EARConfiBuilder should be
reading this file. I guess it is the same with other builders as well. The
JarFileClassLoader has the following comment
* Note: This implementation currently does not work reliably on windows,
since the jar URL
On Jan 23, 2008, at 10:02 AM, Vamsavardhana Reddy wrote:
Kevan,
I am testing this with an ear file. So, the EARConfiBuilder should
be reading this file. I guess it is the same with other builders as
well. The JarFileClassLoader has the following comment
* Note: This implementation
I have found the culprit. It is the URLs that we use to read content from
an archive, for e.g., META-INF/application.xml from an ear file. The
deployer is creating a JarFile and closing the JarFile after the deployment
operation is completed. JarFile.close() closes all the InputStreams
obtained
