When I try to debug my enterprise application in netbeans 5.0, I get the following errormessage: Deploying application in domain failed; Could not rename C:\Sun\AppServer\domains\domain1\applications\j2ee-apps\entityautocomp to C:\Sun\AppServer\domains\domain1\applications\j2ee-apps\entityautocomp_old
; requested operation cannot be completed
Does anybody know how I can fix this problem ?
Thanks in advance,
kind regards
Your error message indicates there are some files under C:\Sun\AppServer\domains\domain1\applications\j2ee-apps\
were being locked by windows OS.
Were these files opened in another window? If yes, you should close those windows and try again. If not, it could be your application or the appserver code or netbeans (and it's bundled code) left some files opened.
Does your application use Struts? There is a known bug related to the Struts bundled in the netbeans code that causes locking and is now fixed in later version of Struts.
https://glassfish.dev.java.net/issues/show_bug.cgi?id=539
If you are not using Struts, and your application can reproduce this problem consistently, please provide the application and the steps to reproduce it and we will look into it.
If you couldn't provide the application but see the problem consistently, we could also send you a utility jar which will prints out information about which files are left open and by who during redeployment. This way, we will know what are files that need to be closed.
I'm having the same problem. I tried to use App Server 8.2 with Sun Studio 8 rather than 8.1 because of some issues with the server security policy in 8.1.
The same application I could deploy successfully multiple times on 8.1 does not work on 8.2. Every time I redeploy I get an error message that files are locked. I do not have any of these files opened in other windows.
Hi.
Naturally, many folks are able to redeploy without incident, so there seems to be something about your application that triggers this problem.
It would greatly simplify diagnosing this problem if you could provide us the ear or war file you are using that shows this problem. If we can reproduce the problem on our systems it will be much easier to resolve this. Feel free to e-mail me with a pointer to the file - or attach the file itself - if you are able to share the app with us.
- Tim
This problem is affecting us too.
It only seems to be a problem if struts is bundled in an EAR.
If it's deployed in a WAR, it's possible to redeploy, but put it inside an EAR and have a servlet also inside the EAR attempt to use it, then the files get locked.
It's enormously frustrating for developers on Windows platforms.
I've tried alot of things:
- Creating a URLConnection and calling setDefaultUseCaches(false) to prevent the whole system from caching URL connections. This works - and allows redeploys - but causes other problems in the system (like a JVM crash).
- Making the EAR an "open EAR" (directory) and deploying the directory. Seems to be the best option so far (although far less than ideal) as you can obviously change the directory location each time.
The application server still makes reference to struts.jar in the old deployments until a stop/restart occurs, but at least it allows for development.
- I've also applied the patch to Struts to have it setUseCaches(false) before using URLConnections, as alluded to in http://issues.apache.org/struts/browse/STR-2610
However this still has redeploy problems.
I'm not sure whether its an Appserver issue or a Struts issue. I think its a Struts bug - but can't spot exactly where in the source its coming from. Reason I haven't totally ruled-out it being an Appserver issue is because it only happens for EARs and not WARs.
Enormously annoying. If anybody else has a workaround (other than using directory deployments), I'd love to hear about it.
Hi, tourtech.
We agree that this sort of problem is very frustrating for developers using Windows.
Which release of Struts are you using now? 1.3.0 or later?
As you can tell from various postings here and in the GlassFish forum (http://forums.java.net/jive/forum.jspa?forumID=56&start=0) locked JARs on Windows is a recurring problem with more than one root cause. In some cases, which is true with earlier releases of Struts, third-party code opens a stream without closing it. Because Windows prohibits an open file from being renamed or deleted this causes some of the redeployment problems reported here and elsewhere.
When you say that "...this still has redeploy problems" does that mean that a JAR file remains locked?
If so, I can offer a (free, unsupported, but very useful) tool you can use to try to identify the code that is opening but not closing the JAR. If you want to try that, please read my blog entry here (http://blogs.sun.com/roller/page/quinn?entry=tool_for_diagnosing_failed_glassf ish) which contains a link to download the small JAR containing the tool and instructions for using it. The tool will provide a stack trace showing the stack at the time the JAR was opened. That will give you and us some idea of where to look further.
- Tim
Message was edited by:
tjquinn
Hi Tim
Appreciate your thoughts.
I've tried using the latest build of Struts from their maven repo, 1.3.5.
I've also tried backfitting the changes to ActionServlet to 1.2.9 and the bug show-up in both.
I found your findOpenJar utility the other day when trawling the web for pointers and I'll have a go at using it. I'd been using another 3rd party DOS utility, handle.exe, to show open file descriptors for each process, and yes, the struts-1.2.jar archive (and struts-core-1.3.5.jar for v1.3.5) were showing as open by SJSAS8.x and Glassfish even after undeploying.
Strangely enough though, the problem only seems to occur for EARs.
It's not a problem for WARs by themselves.
Which makes me wonder whether its the way AS/Glassfish handles resources for EARs. Or, whether its just a struts-based problem still, and AS just happens to be keeping these files open because struts hasn't finished with them.
I'll have a read-up now on your utility and let you know how I go.
I'm keen to nut this out because I've been looking at it for weeks, and its the last piece of the puzzle before I can move our developers from JBoss over to SJSAS/Glassfish..
Thanks again for your suggestions.
Tim,
I think I may have found the cause (or at least another cause) of the struts jarfile being locked.
Your utility was most helpful.
It appears to be a call to the method commons-chain:ConfigParser:parse(URL url)
from struts:ActionServlet:initChain()
..Opened by hashCode object 2487 from:
java.util.jar.JarFile.<init>(java\util\jar\JarFile.java:134)
java.util.jar.JarFile.<init>(java\util\jar\JarFile.java:70)
sun.net.www.protocol.jar.URLJarFile.<init>(sun\net\www\protocol\jar\URLJarFile.java:56)
sun.net.www.protocol.jar.URLJarFile.getJarFile(sun\net\www\protocol\jar\URLJarFile.java:41)
sun.net.www.protocol.jar.JarFileFactory.get(sun\net\www\protocol\jar\JarFileFactory.java:63)
sun.net.www.protocol.jar.JarURLConnection.connect(sun\net\www\protocol\jar\JarURLConnection.java:102)
sun.net.www.protocol.jar.JarURLConnection.getInputStream(sun\net\www\protocol\jar\JarURLConnection.java:124)
java.net.URL.openStream(java\net\URL.java:1007)
org.apache.commons.chain.config.ConfigParser.parse(org\apache\commons\chain\config\ConfigParser.java:195)
org.apache.struts.action.ActionServlet.initChain(org\apache\struts\action\ActionServlet.java:1632)
org.apache.struts.action.ActionServlet.init(org\apache\struts\action\ActionServlet.java:347)
javax.servlet.GenericServlet.init(javax\servlet\GenericServlet.java:241)
org.apache.catalina.core.StandardWrapper.loadServlet(org\apache\catalina\core\StandardWrapper.java:1133)
org.apache.catalina.core.StandardWrapper.load(org\apache\catalina\core\StandardWrapper.java:962)
org.apache.catalina.core.StandardContext.loadOnStartup(org\apache\catalina\core\StandardContext.java:4416)
org.apache.catalina.core.StandardContext.start(org\apache\catalina\core\StandardContext.java:4772)
com.sun.enterprise.web.WebModule.start(com\sun\enterprise\web\WebModule.java:292)
org.apache.catalina.core.ContainerBase.addChildInternal(org\apache\catalina\core\ContainerBase.java:833)
org.apache.catalina.core.ContainerBase.addChild(org\apache\catalina\core\ContainerBase.java:817)
The commons-chain method is attempting to open a stream from a URL (not a URLConnection), which is subject to the same problems of keeping fds open.
In Struts 1.3, they fixed their own references of this by changing url.openStream() with a URLConnection after first calling URLConnection.setUsesCaches(false) to prevent caching and file locks.
I think the same needs to happen in the commons-chain ConfigParser.java source.
What do you think?
Hi.
I just took a very quick look at the source for the commons/chain parse method you identified, and I think you may be right about the useCaches setting...plus it never hurts to actually close a stream that's been opened! Neither of the parse method implementations in ConfigParser does so and I don't think that's a side effect of the digester.parse method but I'm not sure.
It's gratifying that the findOpenJars tool helped.
I have not looked for an existing issue against Apache commons/chain about this. Would you be willing to open one and post a pointer to it here?
- Tim
Message was edited by:
tjquinn
any updates on this?
I found similar issue with Tomcat 5.5.20 using Struts 1.3.5, commons-digester-1.6.jar
When I undeploy my application, the commons-digester-1.6.jar in WEB-INF/lib will not be deleted and it also does not delete commons-validator-1.3.0.jar, and struts-core-1.3.5.jar. But when I deployed my application without commons-digester-1.6.jar I was able to undeploy without any problem.
I understand that you guys are talking about Sun Application Server 8.2 and I am talking about Tomcat....hope that's ok!
