在Glassfish V3中使用CXF部署WAR [英] Deploying WAR with CXF in Glassfish V3

查看:154
本文介绍了在Glassfish V3中使用CXF部署WAR的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试在GF V3中部署一个具有CXF作为依赖关系的WAR,我得到以下异常:

I'm trying to deploy a WAR in GF V3 that has CXF as a dependency and I get the following exception:

[#|2011-02-08T07:34:15.736-0800|WARNING|oracle-glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=32;_ThreadName=http-thread-pool-8080-(2);|StandardWrapperValve[MyServlet]: PWC1406: Servlet.service() for servlet MyServlet threw exception
com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.api.pipe.TransportPipeFactory: Provider com.sun.enterprise.jbi.serviceengine.bridge.transport.JBITransportPipeFactory is specified in bundle://254.0:0/META-INF/services/com.sun.xml.ws.api.pipe.TransportPipeFactory but not found
        at com.sun.xml.ws.util.ServiceFinder.fail(ServiceFinder.java:241)
        at com.sun.xml.ws.util.ServiceFinder.access$100(ServiceFinder.java:141)
        at com.sun.xml.ws.util.ServiceFinder$LazyIterator.next(ServiceFinder.java:376)
        at com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:129)
        at com.sun.xml.ws.transport.DeferredTransportPipe.<init>(DeferredTransportPipe.java:82)
        at com.sun.xml.ws.api.pipe.ClientTubeAssemblerContext.createTransportTube(ClientTubeAssemblerContext.java:311)
        at com.sun.xml.ws.assembler.jaxws.TransportTubeFactory.createTube(TransportTubeFactory.java:62)
        at com.sun.xml.ws.assembler.TubeCreator.createTube(TubeCreator.java:77)
        at com.sun.xml.ws.assembler.TubelineAssemblerFactoryImpl$MetroTubelineAssembler.createClient(TubelineAssemblerFactoryImpl.java:121)
        at com.sun.xml.ws.client.Stub.createPipeline(Stub.java:224)
        at com.sun.xml.ws.client.Stub.<init>(Stub.java:201)
        at com.sun.xml.ws.client.Stub.<init>(Stub.java:174)
        at com.sun.xml.ws.client.sei.SEIStub.<init>(SEIStub.java:81)
        at com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:602)
        at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:344)
        at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:326)
        at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:308)
        at javax.xml.ws.Service.getPort(Service.java:99)
        at com.mycompany.myapp.webserviceclient.SomeWebserviceService.getSomeWebservicePort(SomeWebserviceService.java:58)

这个sorta告诉我,我的WAR\lib目录中有一个捆绑导致了问题,但当我扩展WAR并在META-INF \services上搜索时,我找不到任何东西这是异常中概述的内容。

This sorta indicates to me that there is a bundle in my WAR\lib directory that is causing problems, but when I expand the WAR and do a search on META-INF\services I do not find anything that is close what is outlined in the exception.

我最初有一个CXF,它是war \lib目录中的传递依赖,但我已经删除了它,但仍然遇到同样的错误。

I originally had CXF and it's transitive dependencies in the war\lib dir, but I've since removed that and still encounter the same error.

搜索谷歌时没有任何有用的东西,我在这里不知所措。

Nothing useful comes up when searching google and I'm at a loss here.

有谁知道这里会发生什么?

Does anyone know what might be going on here?

编辑#1

另一个症状是部署的Web服务的测试页面无法正常工作。

Another symptom of this is that the tester pages for deployed web services will not work properly.

推荐答案

我的glassfish3.1遇到了类似的问题。下面是一个堆栈跟踪

I had a similar problem with my glassfish3.1. Below is a stack trace

Caused by: com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.api.pipe.TransportPipeFactory: Provider com.sun.enterprise.jbi.serviceengine.bridge.transport.JBITransportPipeFactory is specified in bundle://96.0:0/META-INF/services/com.sun.xml.ws.api.pipe.TransportPipeFactory but not found
    at com.sun.xml.ws.util.ServiceFinder.fail(ServiceFinder.java:245)
    at com.sun.xml.ws.util.ServiceFinder.access$100(ServiceFinder.java:145)
    at com.sun.xml.ws.util.ServiceFinder$LazyIterator.next(ServiceFinder.java:380)
    at com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:133)
    at com.sun.xml.ws.transport.DeferredTransportPipe.<init>(DeferredTransportPipe.java:86)
    at com.sun.xml.ws.api.pipe.ClientTubeAssemblerContext.createTransportTube(ClientTubeAssemblerContext.java:315)
    at com.sun.xml.ws.assembler.jaxws.TransportTubeFactory.createTube(TransportTubeFactory.java:67)
    at com.sun.xml.ws.assembler.TubeCreator.createTube(TubeCreator.java:84)
    at com.sun.xml.ws.assembler.TubelineAssemblerFactoryImpl$MetroTubelineAssembler.createClient(TubelineAssemblerFactoryImpl.java:130)
    at com.sun.xml.ws.client.Stub.createPipeline(Stub.java:228)
    at com.sun.xml.ws.client.Stub.<init>(Stub.java:205)
    at com.sun.xml.ws.client.Stub.<init>(Stub.java:178)
    at com.sun.xml.ws.client.sei.SEIStub.<init>(SEIStub.java:85)
    at com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:608)
    at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:348)
    at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:330)
    at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:312)
    at javax.xml.ws.Service.getPort(Service.java:134)
    at org.glassfish.webservices.monitoring.WebServiceTesterServlet.initializePort(WebServiceTesterServlet.java:563)
    at org.glassfish.webservices.monitoring.WebServiceTesterServlet.doGet(WebServiceTesterServlet.java:169)
    at org.glassfish.webservices.monitoring.WebServiceTesterServlet.invoke(WebServiceTesterServlet.java:104)
    at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:114)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
    at com.sun.grizzly.http.servlet.ServletAdapter$FilterChainImpl.doFilter(ServletAdapter.java:1002)
    ... 20 more

这个问题可以追溯到两个不同模块中com.sun.xml.ws.api.pipe.TransportPipeFactory的冲突映射。

The problem was traced to the conflicting mappings for "com.sun.xml.ws.api.pipe.TransportPipeFactory" inside two different modules.

prompt> grep -rl com.sun.xml.ws.api.pipe.TransportPipeFactory /usr/local/glassfish-3.1/glassfish/domains/modules*

modules/webservices-osgi.jar
modules/sun-javaee-engine.jar

prompt> grep -rl com.sun.enterprise.jbi.serviceengine.bridge.transport.JBITransportPipeFactory /usr/local/glassfish-3.1/glassfish/domains/modules/*
modules/sun-javaee-engine.jar

显然,所需文件位于错误的jarsun-javaee-engine.jar中。

Clearly, the required file was sitting in the wrong jar "sun-javaee-engine.jar".

上面,sun-javaee-engine.jar由Java EE服务引擎模块加载。一旦我删除了模块(使用glassfish更新工具),一切都开始正常工作。

Above, "sun-javaee-engine.jar" is loaded by the "Java EE Service Engine Module". Once I removed the module (using glassfish update tool) everything started working fine.

编辑#1:
这是如何使用Unix命令行上的更新工具删除模块:

EDIT #1: Here is how to remove the module using the update tool on the Unix command line:

sudo ./pkg uninstall sun-javaee-engine

这篇关于在Glassfish V3中使用CXF部署WAR的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆