这是近期工作中遇到的一个问题，cxf在glassfish下timeout设置出现问题，进而引发的关于classloader, JAX-WS的一些小故事，很惊讶的发现cxf在这种情况下根本没有办法运行于glassfish平台。
关键字：glassfish, cxf, classloader, JAX-WS, metro。
首先看问题的发生，我们有一个webservice的客户端，使用cxf开发，原来运行于weblogic，目前准备移植到glassfish。异常测试中发现timeout设置不再有效，在glassfish平台上timeout时间似乎是无限？测试中试过等待10分钟也没有timeout，socket一直连着，客户端一直在等应答。
于是准备增加timeout的设置到cxf中，下面是cxf的timeout的典型设置：
Client client = ClientProxy.getClient(this.port);
HTTPConduit http = (HTTPConduit) client.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(30 * 1000);
httpClientPolicy.setReceiveTimeout(60 * 1000);
http.setClient(httpClientPolicy);
这段代码在weblogic中是正常工作的，但是在glassfish上就出现问题，“Client client = ClientProxy.getClient(this.port);” 这行会抛出一个异常ClassCastException：
javax.xml.ws.soap.SOAPFaultException: com.sun.xml.ws.client.sei.SEIStub cannot be cast to org.apache.cxf.frontend.ClientProxy
google了一下发现这个问题的出现已经在cxf的issue列表中， CXF-2237：
https://issues.apache.org/jira/browse/CXF-2237
从这个网址得到的信息：
1. That error would mean that the Sun JAX-WS implementation is being picked up instead of the CXF version.
2. Classpath issue picking up wrong JAX-WS implementation.
原因似乎很清晰了，但是没有给出解决方法，继续google发现类似的问题在jboss平台也有发现，cxf有给出解决方法。
于是郁闷了，找了找资料，发现问题可能和JAX-WS有关：
1. JAX-WS 是用于web service的java api，定义在JSR 224.
2. sun提供了JAX-WS的一个实现Metro，包含在glassfish中。
3. sun的实现后来加入了jdk6(不过package和Metro不同)
4. apache cxf 是另外一个JAX-WS实现
从上面的异常看，"com.sun.xml.ws.client.sei.SEIStub cannot be cast to org.apache.cxf.frontend.ClientProxy", 像是从"sun impl" -> "cxf impl"的转换出问题，也就是说runtime时实际运行的是sun的JAX-WS实现，而不是cxf的实现。这个和CXF-2237的描述是一致的，因此问题基本定位出来了：glassfish中cxf的实现没有被装载成功。
随即查找了一下关于JAX-WS 实现装载的资料，application是可以通过Provider SPI来选择不同的JAX-WS实现的，在JSR 224: JAX-WS 2.x 中的chapter 6.2.1 有选择Provider implementation的规则：
1. If a resource with the name of META-INF/services/javax.xml.ws.spi.Provider exists, then its first line, if present, is used as the UTF-8 encoded name of the implementation class.
意思是说查找名为META-INF/services/javax.xml.ws.spi.Provider的资源，如果存在，那么它的第一行，就是实现类的名字。
我们试着打开cxf的jar文件，发现的确有上述文件，内容只有一行：org.apache.cxf.jaxws.spi.ProviderImpl。然后查找了一下glassfish的jar文件，在glassfish安装目录下的lib\webservice-rt.jar中找到了JAX-WS的实现，同样有META-INF/services/javax.xml.ws.spi.Provider文件，内容为： com.sun.xml.ws.spi.ProviderImpl.
2. If the ${java.home}/lib/jaxws.properties file exists and it is readable by the java.util.Properties.load(InputStream) method and it contains an entry whose key
is javax.xml.ws.spi.Provider, then the value of that entry is used as the name of the implementation class.
类似的，通过${java.home}/lib/jaxws.properties 文件来设置。
3. If a system property with the name javax.xml.ws.spi.Provider is defined, then its value is used as the name of the implementation class.
通过系统属性javax.xml.ws.spi.Provider来设置。
4. Finally, a default implementation class name is used.
最后，默认实现，即使就是jdk中的sun的实现，猜测是Metro的某个版本
从上述规则来看，明显当前是遵循了第一个规则，从资源META-INF/services/javax.xml.ws.spi.Provider中读取实现类。而且虽然application中有cxf.jar的存在并且有名为META-INF/services/javax.xml.ws.spi.Provider的资源，但是因为application的classloader在装载资源时，按照标准的classloader机制，会首先代理给parent classloader，因此最后实际是system classloader首先尝试装载资源，glassfish下lib\webservice-rt.jar是属于system classpath，glashfish的system classloader会查找到并装载webservice-rt.jar中的META-INF/services/javax.xml.ws.spi.Provider。这样application中的classloader就没有机会装载cxf的META-INF/services/javax.xml.ws.spi.Provider，而是直接使用glassfish system classloader装载好的javax.xml.ws.spi.Provider，自然就是Metro的实现。
现在关键的问题在于这个规则是第一顺序位，后面的2，3根本没有机会。因此想装载cxf的JAX-WS实现，就只有想办法改变classloader的装载机制，想办法让application中的classloader有机会装载到cxf的JAX-WS实现。
类似的class 装载的问题在cxf上就比较常见了，之前在weblogic上也经常遇到类似的，解决的思路就是改变classloader的默认装载机制，让application中的classloader自己去装载而不是代理给system classloader。
weblogic中对此有专门的设置prefer-application-packages，在weblogic-ejb-jar.xml或者weblogic-application.xml中加入：
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
</prefer-application-packages>
就可以指示weblogic，对于上述的package，优先实现application的classloader而不是使用system classloader，从而解决这个问题。
因为问题的解决思路就很明显了： 在glassfish中找到类似于prefer-application-packages的方法。
首先找到的是glassfish中的delegate设置，看delegate的介绍：
(optional) If true, the web module follows the standard class loader delegation model and delegates to its parent class loader first before looking in the local class loader. You must set this to true for a web application that accesses EJB components or that acts as a web service client or endpoint.
粗看正是我们想要的，再一看发现不行，delegate的使用是有限制的：
1. delegate只在sun-web.xml有，只能用于web app，不能用于普通的application
2. delegate是有限制的，对于"java.*"和"javax.*"的包不能生效的
随后的查找发现，非常遗憾，glassfish没有提供其他的类似机制，因此试图改变classloader的想法陷入绝境。
只好先考虑其他的方法，一个思路就是让glassfish的system classloader直接load到cxf，方法如下：
1.将cxf的lib包（或者只是META-INF/services/javax.xml.ws.spi.Provider文件）放到glassfish的system classpath下并在lib\webservice-rt.jar之前
2.删除lib\webservice-rt.jar
这个试过了，glassfish直接起不来
但这些都不是足够妥当，最后考虑到既然大家都是JAX-WS实现，而且sun的Metro也算做的不错，因此将错就错，考虑直接使用Metro好了。就当前遇到的timeout设置的问题，在Metro中是非常容易解决的：
Map<String, Object> requestContext = ((BindingProvider) service).getRequestContext();
requestContext.put("com.sun.xml.ws.connect.timeout", 30 * 1000);
requestContext.put("com.sun.xml.ws.request.timeout", 60 * 1000);
至此这次timeout的设置问题总算解决了，但是，依然没有办法解决glassfish的classloader问题，以后如果遇到类似的需要application优先装载特定类的情况，还是会遭遇同样的困境。这里比较奇怪的是，为什么glassfish会没有类似的设置，按说既然glassfish已经给出了delegate这个设置，说明glassfish已经意思到有这个需要并且也给出了部分解决方法，但是为什么对应于application确不给出任何解决方案呢？百思不得其解。
而从上面的描述也可以看出，如果不使用特殊的方法，正常情况下，applicatio是没有办法装载到cxf的JAX-WS实现的，实际在runtime时跑的是metor的实现。