Tomcat 5.5:.jar 未在 .war 重建时释放
概要
我试图将 WAR 导出到我的 webapps 文件夹,但每次我更新 war 时,它都会删除 webapp 的所有内容,减去 /WEB-INF/lib/struts.jar
系统信息
- Windows 2K3
- Tomcat 5.5
- JRE 1.6.23
好的正在发生什么:
- 通过 Eclipse (Helios) 将项目导出为 .WAR 到 /webapps 目录
- Tomcat 看到 war 中的变化并尝试重建 webapp
- Tomcat删除 webapp 文件夹 (/webapps/public)
- (/webapps/public/WEB-INF/lib/struts.jar) 的内容被锁定,防止其被删除。
- Tomcat 放弃重建,除了 struts.jar 之外,文件夹中什么都没有,导致应用程序崩溃。
问题
- 有没有办法防止罐子被锁住?
- (或者)我应该使用更好的部署流程(并且可以快速掌握)?
在
元素上使用 antiResourceLocking="true"
和 antiJARLocking="true"
并没有解决问题。感谢任何帮助。
Synopsis
I am attempting to export a WAR to my webapps folder but everytiime I update the war it deletes all of the content of the webapp minus /WEB-INF/lib/struts.jar
System info
- Windows 2K3
- Tomcat 5.5
- JRE 1.6.23
Ok here is what is happening:
- Export project as .WAR via Eclipse (Helios) to /webapps directory
- Tomcat sees the change in the war and attempts to rebuild webapp
- Tomcat deletes contents of webapp folder (/webapps/public)
- (/webapps/public/WEB-INF/lib/struts.jar) is locked preventing it from being deleted.
- Tomcat gives up rebuild leaving me with nothing in the folder besides the struts.jar causing the application to break.
Question(s)
- Is there a way to keep the jar from being locked?
- (OR) a better deployment process I should be using (and can pick up quickly)?
Using antiResourceLocking="true"
and antiJARLocking="true"
on the <Context>
element did not solve the problem. Appreciate any help.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
将
unloadDelay
添加到您的上下文有帮助吗?哪个是:
来源: http://tomcat.apache.org/tomcat-5.5- doc/config/context.html
显然,有时 Web 应用程序正处于大型 GC 中/ClassLoader 尚未被垃圾收集,无法及时释放。尝试尝试超时,看看是否有帮助。
还有一些关于 Windows 平台上奇怪的文件锁定的轶事证据。
另外,假设您指的是开发(而不是生产)构建环境,请查看我的问题之一,展示我对 Tomcat / Eclipse 热部署环境的方法:
Tomcat 和 Eclipse 零周转部署
更新
这个有用的线程出现在同一问题的 Google 搜索中,并被引用由许多其他人:
http://blog .exis.com/colin/?s=I+Put+A+Spell+On+You
Does adding
unloadDelay
to your Context help?Which is the:
Source: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
Apparently sometimes the web app is in the middle of a large GC / the ClassLoader hasn’t been garbage collected and cannot release in time. Try experimenting with the timeout to see if that helps.
There is also some anecdotal evidence of strange file locking on Windows platforms.
Also, assuming you're referring to a development (not production) build environment, look at one of my questions, showing my approach to Tomcat / Eclipse hot deploy environments:
Tomcat and Eclipse Zero Turnaround Deployment
Update
This helpful thread comes up on a Google search of the same issue and is referred to by a number of others:
http://blog.exis.com/colin/?s=I+Put+A+Spell+On+You
我猜你的要求是快速部署和重建,因为 Eclipse 是你的 IDE。
正如您所发现的,将 war 文件导出到 webapps 文件夹并不是最佳选择。其他选项包括
a) 使用 sysdeo tomcat 插件 -- sysdeo 部署项目文件夹
b) 更新构建脚本以以分解格式部署。 -- 将 \build 文件夹部署为展开的应用程序
第一个选项是最简单的。第二种选择更干净。
[OFF TOPIC] 考虑切换到 tomcat 7
I guess your requirement is to deploy and rebuild quickly given eclipse is ur IDE.
As you have figured out exporting war file to webapps folder is not the best option. Few other options are
a) Use sysdeo tomcat plugin -- sysdeo deploys the project folder
b) Update build script to deploy in exploded format. -- deploy the \build folder as exploded application
First option is easiest. Second option is cleaner.
[OFF TOPIC] consider switching to tomcat 7
这个线程< /a> 相关吗?引用tiles-config.xml 中导致问题的DTD。
Could this thread be of relevance? Cites the DTD in the tiles-config.xml causing issues.
这可能不是最佳解决方案,但我之前在 Tomcat 6 上也遇到过类似的问题。当时我使用 Ant,所以我编写了一个 Ant 脚本,该脚本将在本地部署到 Tomcat,并在此过程中它将在必要时停止/启动 Tomcat(Tomcat 被部署为服务,因此我可以使用 NET STOP / NET START 命令)。这包括删除旧的扩展 WAR 文件夹。
我认为可能有更好的选择,但这对我有用。
This is probably not the optimal solution but I have had similar issues with Tomcat 6 before now. At the time I was using Ant, so I wrote an Ant script which would deploy to Tomcat locally and in the process it would stop / start Tomcat where necessary (Tomcat was deployed as a service so I could use NET STOP / NET START commands). This included deleting the old expanded WAR folder.
I think there probably are better options, but this worked for me.