系统从Tomcat迁移到Weblogic无法发布

系统管理员 2023-05-29 13:01 16阅读 0赞

有一个系统从开发环境部署到正式环境，开发环境用的是tomcat,正式环境用的是weblogic。部署一直不成功，启动失败。

首先会报这个警告：  
<The list of resource packages: gg.soa.org.apache.cxf.jaxrs.provider;org.apache.cxf.jaxrs.provider.atom;gg.soa.org.apache.cxf.rs.security.oauth2.provider;org.apache.cxf.jaxrs.provider;gg.soa.org.apache.cxf.rs.security.oauth2.services;gg.soa.org.apache.cxf.rs.security.oauth.services;org.apache.cxf.jaxrs.provider.json;org.codehaus.jackson.jaxrs;gg.soa.org.apache.cxf.jaxrs.ext.search;gg.soa.org.apache.cxf.jaxrs.provider.xmlbeans;gg.soa.org.apache.cxf.jaxrs.provider.json;gg.soa.org.apache.cxf.rs.security.oauth2.filters;org.apache.cxf.jaxrs.impl;org.apache.cxf.jaxrs.provider.aegis;com.alibaba.fastjson.support.jaxrs;org.apache.cxf.jaxrs.provider.xmlbeans;gg.soa.org.apache.cxf.jaxrs.provider.aegis;gg.soa.org.apache.cxf.jaxrs.provider.atom;gg.soa.org.apache.cxf.jaxrs.impl;gg.soa.org.apache.cxf.rs.security.oauth.filters>

然后会报下面的一些类找不到，不光是这些类，每次报的可能是不一样的。  
weblogic.application.ModuleException: java.lang.ClassNotFoundException: net.oauth.OAuthValidator  
weblogic.application.ModuleException: java.lang.ClassNotFoundException: org.apache.abdera.writer.Writer  
weblogic.application.ModuleException: java.lang.ClassNotFoundException: org.apache.cxf.aegis.type.AegisType  
weblogic.application.ModuleException: java.lang.ClassNotFoundException: org.apache.abdera.i18n.iri.IRI

调整1，根据 这个信息找到相应的解决方案，发现按照方案调整之后没有取得效果。  
调整2，tomcat下的包都悉数放到了weblogic，觉得是jar包冲突引起的，或者是类加载顺序以前的，在D:\\program\\jdk1.8.0\_221现在，找到src.zip,找到java.util.jar.JarFile，在这一个方法上面加上打印语句，可以打印出来jar包的调用情况。  
public JarFile(File file, boolean verify, int mode) throws IOException \{  
super(file, mode);  
System.out.println(“JarFile-----:”+file.getName());  
this.verify = verify;  
\}  
编译好累之后，替换D:\\program\\jdk1.8.0\_221\\jre\\lib\\rt.jar。  
打印出加载顺序之后，打印出2千多条信息，导入数据库后去重，同一个包按第一次加载为准，看不出来什么问题。

调整3，再次回归问题，先把类找不到的问题解决，abdera-core-1.1.3.jar abdera-core-1.1.3.jar，cxf-rt-databinding-aegis-2.5.3.jar，oauth.net.jar先下载这四个包。类找不到的问题解决了，有产生了新的问题：  
org.glassfish.jersey.server.model.ModelValidationException: Validation of the application resource model has failed during application initialization.  
\[\[WARNING\] Parameter 1 of type java.util.Map<? extends java.lang.Enum<?>, java.lang.String> from public void org.apache.cxf.jaxrs.provider.RequestDispatcherProvider.setEnumResources(java.util.Map<? extends java.lang.Enum<?>, java.lang.String>) is not resolvable to a concrete type.; source=‘public void org.apache.cxf.jaxrs.provider.RequestDispatcherProvider.setEnumResources(java.util.Map)’, \[WARNING\] Parameter 1 of type java.lang.Class<?>\[\] from public void gg.soa.org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class<?>\[\]) is not resolvable to a concrete type.; source=‘public void gg.soa.org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class\[\])’, \[WARNING\] Parameter 1 of type java.lang.Class<?>\[\] from public void org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class<?>\[\]) is not resolvable to a concrete type.; source=‘public void org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class\[\])’, \[WARNING\] Parameter 1 of type java.util.Map<java.lang.Class<?>, gg.soa.org.apache.cxf.jaxrs.provider.atom.AtomElementReader<?, ?>> from public void gg.soa.org.apache.cxf.jaxrs.provider.atom.AtomPojoProvider.setAtomClassReaders(java.util.Map<java.lang.Class<?>, gg.soa.org.apache.cxf.jaxrs.provider.atom.AtomElementReader<?, ?>>) is not resolvable to a concrete type.; source='public void gg.soa.org.apache.cxf.jaxrs.provider.atom.Atom…f.rs.security.oauth.services.AuthorizationRequestService.authorizeDecisionForm() and public javax.ws.rs.core.Response gg.soa.org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService.authorizeDecisionForm(javax.ws.rs.core.MultivaluedMap) at matching path pattern /decision.; source=‘org.glassfish.jersey.server.model.RuntimeResource@d5cec09’, \[HINT\] A resource model has ambiguous (sub-)resource method for HTTP method GET and output mime-types as defined by @Produces annotation at Java methods public javax.ws.rs.core.Response gg.soa.org.apache.cxf.rs.security.oauth.services.AuthorizationRequestService.authorizeDecision() and public javax.ws.rs.core.Response gg.soa.org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService.authorizeDecision() at matching path pattern /decision.; source=‘org.glassfish.jersey.server.model.RuntimeResource@d5cec09’\]  
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:555)  
at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:184)  
at org.glassfish.jersey.server.ApplicationHandler$3.call(ApplicationHandler.java:350)  
at org.glassfish.jersey.server.ApplicationHandler$3.call(ApplicationHandler.java:347)  
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)  
Truncated. see log file for complete stacktrace

metalink的解释：  
In the client application did not see the oauth related configuration, you can download the cxf316 source, modify org.apache.cxf.rs.security.oauth2.services.AuthorizationService this class path settings, such as the original @Path (“authorize” ) Modified to @Path (“authorize2”) as a temporary workaround

有org.apache.cxf.rs.security.oauth2.services.AuthorizationService和org.apache.cxf.rs.security.oauth2.services.RedirectionBasedGrantService.authorizeDecisionForm这两对类都有补丁冲突，即相同的路径会有两个实现，这样在实际的调用中服务器将无法确定应该调用哪个方法来提供服务。所以服务器会抛出致命的异常。而TOMCAT应该没有全局扫描机制，最初推测CXF可能使用按需加载，因此不会发生冲突。

调整4：把org.apache.cxf.rs.security.oauth2.services.AuthorizationService 注解的Path改了一下，再次启动，终于OK。