tomcat在调用shared lib遇到的问题--gradle

最新推荐文章于 2024-10-12 16:50:09 发布

qq_36821448

最新推荐文章于 2024-10-12 16:50:09 发布

阅读量500

点赞数

CC 4.0 BY-SA版权

分类专栏：开发问题

本文链接：https://blog.youkuaiyun.com/qq_36821448/article/details/79731092

开发问题专栏收录该内容

5 篇文章

订阅专栏

在将项目从Eclipse部署到服务器的Tomcat时，出现报错。排查过程中发现，Gradle打包的WAR文件缺少部分依赖，并与Tomcat shared目录中的JAR包产生冲突。删除重复的JAR并理解Gradle中compile、providedCompile和runtime的区别，解决了问题。主要冲突源于spring-jms的重复打包。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

eclipse 在本地启动tomcat跑项目，完全没有问题，当打包部署服务器时，发现报错。

当时我们遇到的问题直接显示是

org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [DispatcherServlet] in context with path [/robot] threw exception [Request processing failed; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.transaction.PlatformTransactionManager] is defined] with root cause
 org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.transaction.PlatformTransactionManager] is defined
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:371)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:331)
        at org.springframework.transaction.interceptor.TransactionAspectSupport.determineTransactionManager(TransactionAspectSupport.java:370)
        at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:271)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207)
        at com.sun.proxy.$Proxy61.findOneDebtorNameAudio(Unknown Source)
        at com.squ.robot.service.impl.NameCutServiceImpl.dealWavFile(NameCutServiceImpl.java:127)
        at com.squ.robot.controller.WavCheckController.uploadFile(WavCheckController.java:34)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

各种找问题，查资料，网上大部分都是说JPA的使用问题，矛头指向@Transactional 的使用上，这里也mark一下吧，@Transactional 在jpa的使用中，对于update和delete必须声明；

后面不管怎么调试都不成功，然后发现本地可以，但是部署到测试的包上就不行，于是我就只能用最笨的方法，对比通过gradle命令打出来的war包和本地部署的tomcat下的webapps下的war是否有区别；

对比发现gradle打包的war中缺少很大部分的jar，然后发现这部分缺少的jar放在来服务器的tomcat的shared中，通过tomcat的conf中catalina.properties 加载，这里包含了tomcat的jar和class的加载顺序，省略1000字,mark一下；

然后发现shared里面的jar和部署war中有jar包的重叠，这就是产生问题的根本所在，于是就将所有重复的jar删除后，重新打包就ok了。

后续研究发现，报错的重复的jar主要是spring-jms引起的，也就是gradle打包的时候将

providedCompile('org.springframework:spring-jms:4.1.4.RELEASE')

错误的写成了

compile('org.springframework:spring-jms:4.1.4.RELEASE')

这样就导致了war包重复打了这些包，一步步导致了上面的问题。

知识点三：gradle中：compile，providedCompile，runtime 的区别：

仅在运行的时候需要，但是在编译时不需要依赖,就用runtime ；前提：apply plugin: 'java'；

如果你的jar包/依赖代码仅在编译的时候需要，但是在运行时不需要依赖,就用providedCompile ；前提：apply plugin: 'war'；

如果你的jar包/依赖代码在编译的时候需要依赖，在运行的时候也需要，那么就用compile ；前提：apply plugin: 'war'或者apply plugin: 'java'

mark 一下。