Deployment failure on Tomcat 6.x. Could not cop

今天在网上部署项目的时候出现在了问题 tomcat一直部署不上 网上查了一下 原因记下来供大家查看

[plain] <span style="font-size:18px;">Deployment failure on Tomcat  6.x. Could not copy all resources to D:\Program Files\apache-tomcat-6.0.16\webapps\fuNan_conv. If a file is locked, you can wait until the lock times out to redeploy, or stop the server and redeploy, or manually remove the deployment at D:\Program Files\apache-tomcat-6.0.16\webapps\fuNan_conv   
</span> 
<span style="font-size:18px;">Deployment failure on Tomcat  6.x. Could not copy all resources to D:\Program Files\apache-tomcat-6.0.16\webapps\fuNan_conv. If a file is locked, you can wait until the lock times out to redeploy, or stop the server and redeploy, or manually remove the deployment at D:\Program Files\apache-tomcat-6.0.16\webapps\fuNan_conv 
</span>


解决方案一:

引用
[plain] <span style="font-size:18px;">tomcat服务并没有启动.上网搜索之后发现和大家范的是一个毛病,原来工程中我引了一个包,后来这个包被我给删除了,但是因为已经发布过这个工程了,所以classpath中就有这个包名了,这样发布的时候也会去找这个包但是已经不存在了,所以无copy,  
 
解决办法:在eclipse的工程中点击右健选择properties-->java build path中已经提示了xx.jar不存在,这样就把这个jar信息从Libraries中删除即可.  
 
重新发布应用,成功! 
</span> 
<span style="font-size:18px;">tomcat服务并没有启动.上网搜索之后发现和大家范的是一个毛病,原来工程中我引了一个包,后来这个包被我给删除了,但是因为已经发布过这个工程了,所以classpath中就有这个包名了,这样发布的时候也会去找这个包但是已经不存在了,所以无copy,

解决办法:在eclipse的工程中点击右健选择properties-->java build path中已经提示了xx.jar不存在,这样就把这个jar信息从Libraries中删除即可.

重新发布应用,成功!
</span>

方案二

引用
[plain] <span style="font-size:18px;">在项目的.classpath下面中的/lib/...都是我们发布项目中所用到的包。不知道何时谁随便加了几个包。就在.classpath下面生成了文件。所以在发布项目的时候始终发布不上去。一一对照.classpath中的包和WEB/INF  lib中的包。对照仔细了 
</span> 
<span style="font-size:18px;">在项目的.classpath下面中的/lib/...都是我们发布项目中所用到的包。不知道何时谁随便加了几个包。就在.classpath下面生成了文件。所以在发布项目的时候始终发布不上去。一一对照.classpath中的包和WEB/INF  lib中的包。对照仔细了
</span>
方案三

总之,可以看出myEclipse的工作目录出现了问题,
那就来绝招吧:更换workspace!
重新发布,ok

 摘自 那年那月那天

### Tomcat 7.x 部署失败解决方案 当遇到 Tomcat 7.x 的部署失败问题时,通常是因为文件被锁定或者资源无法复制而导致重新部署失败。以下是可能的原因以及对应的解决方法: #### 原因分析 1. **文件锁机制** 在某些操作系统上(尤其是 Windows),如果某个文件正在被使用,则该文件会被锁定,其他进程无法对其进行修改或删除操作[^1]。 2. **日志文件占用** 如果应用程序的日志文件未正确关闭,可能会导致这些文件在重新部署期间仍然处于打开状态,从而引发错误[^2]。 3. **临时文件残留** 当应用停止不完全时,可能导致工作目录下的 `.class` 文件或其他缓存文件未能及时清理,进而影响下一次启动过程[^3]。 4. **权限不足** 若服务器运行账户缺乏足够的访问权限来读取/写入特定路径中的文件夹和文件,也可能造成此类异常行为发生[^4]。 #### 解决方案 针对上述提到的各种可能性提供如下几种处理方式: - #### 修改 `unpackWARs` 和 `autoDeploy` 参数配置 调整位于 `$TOMCAT_HOME/conf/server.xml` 中的相关属性设置可以有效缓解部分情况下的冲突现象。例如将 `<Host>` 元素内的两个布尔型选项分别设为 false 可暂时禁用自动解压功能并阻止后台监控新包上传动作的发生。 ```xml <Host name="localhost" appBase="webapps" unpackWARs="false" autoDeploy="false"> ``` - #### 手动清除旧版本数据 对于那些已经损坏却尚未彻底移除干净的应用实例来说,建议先手动进入其对应存储位置(`$TOMCAT_HOME/webapps`)把整个项目连同衍生出来的子目录一并删掉再尝试重启服务端程序加载新的镜像副本. - #### 使用异步 IO 方式管理静态资源 更改默认实现类由 StandardWrapperLoader 替换成为 AsyncFileUploadHandler 这样做能够减少因为同步阻塞带来的负面影响同时也提高了整体吞吐量表现. ```java @MultipartConfig(fileSizeThreshold=1024*1024, maxFileSize=1024*1024*5, maxRequestSize=1024*1024*5*5) public class FileServlet extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException {} } ``` - #### 设置 JVM 启动参数优化垃圾回收策略 添加额外命令行开关 `-XX:+UseG1GC -XX:MaxGCPauseMillis=200`,通过采用 G1 收集器降低长时间暂停概率提高响应速度同时释放更多可用内存空间给当前线程组利用. ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值