最近在使用motan把业务服务发布成RPC之后，同时还支持restful的调用方式，相当于支持两种协议的发布。当程序直接通过MAIN入口启动，客户端发起restful调用，解析一切正常。但当打包成独立运行的JAR，请求的返回解析就会失败。初步定位以JAR方式运行，WS相关服务类加载被另外第三方替换。
这个文件里面正常内容是这样的：
org.jboss.resteasy.plugins.providers.DataSourceProvider
org.jboss.resteasy.plugins.providers.DocumentProvider
org.jboss.resteasy.plugins.providers.DefaultTextPlain
org.jboss.resteasy.plugins.providers.StringTextStar
org.jboss.resteasy.plugins.providers.SourceProvider
org.jboss.resteasy.plugins.providers.InputStreamProvider
org.jboss.resteasy.plugins.providers.ReaderProvider
org.jboss.resteasy.plugins.providers.ByteArrayProvider
org.jboss.resteasy.plugins.providers.FormUrlEncodedProvider
org.jboss.resteasy.plugins.providers.JaxrsFormProvider
org.jboss.resteasy.plugins.providers.FileProvider
org.jboss.resteasy.plugins.providers.FileRangeWriter
org.jboss.resteasy.plugins.providers.StreamingOutputProvider
org.jboss.resteasy.plugins.providers.IIOImageProvider
org.jboss.resteasy.plugins.providers.SerializableProvider
org.jboss.resteasy.plugins.interceptors.CacheControlFeature
org.jboss.resteasy.plugins.interceptors.encoding.AcceptEncodingGZIPInterceptor
org.jboss.resteasy.plugins.interceptors.encoding.AcceptEncodingGZIPFilter
org.jboss.resteasy.plugins.interceptors.encoding.ClientContentEncodingAnnotationFeature
org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor
org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor
org.jboss.resteasy.plugins.interceptors.encoding.ServerContentEncodingAnnotationFeature
如果不正常，内容就是这样的：
com.alibaba.fastjson.support.jaxrs.FastJsonProvider
到这里，想必大家也找到原因了。javax.ws.rs.ext.Providers这个文件 是motan依赖的第三方包org.jboss.resteasy:jarxs-spi的spi定义文件与fastjson的同名文件产生了冲突。最终POM中显示隐性关联依赖的fastjson的javax.ws.rs.ext.Providers的内容替换了正确的文件，导致服务调用失败。至于如何解决，就是把motan-core依赖的fastjson排除掉，因为我的对象序列化是hession的，这个包也用不到。问题解决了，这对于我们在使用第三方包有一个启示，任何时候不能不加思索，拿来就用。一定要知根知底，洞悉内在的本质。回过头来，SPI到底是何方神圣？
SPI的全名为Service Provider Interface，该机制实际上是为接口寻找服务实现类。现在大部分公司的系统都是进行了模块的划分，系统抽象为多个模块，往往有很多不同的实现方案，比如日志模块的方案，xml解析模块、jdbc模块的方案等。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。于是就诞生了SPI这种服务发现机制。
java spi的具体使用如下 ：当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。 基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。
这是有一篇对SPI讲的比较透彻java-spi，大家可以学习一下。里面有JAVA内置的SPI的实现
CurrencyNameProvider: provides localized currency symbols for the Currency class.LocaleNameProvider: provides localized names for the Locale class.TimeZoneNameProvider: provides localized time zone names for the TimeZone class.DateFormatProvider: provides date and time formats for a specified locale.NumberFormatProvider: provides monetary, integer and percentage values for the NumberFormat class.Driver: as of version 4.0, the JDBC API supports the SPI pattern. Older versions uses the Class.forName() method to load drivers.PersistenceProvider: provides the implementation of the JPA API.JsonProvider: provides JSON processing objects.JsonbProvider: provides JSON binding objects.Extention: provides extensions for the CDI container.ConfigSourceProvider: provides a source for retrieving configuration properties.
以及我们如何实现一个自定义的SPI接口自定义实现代码。
最后，延伸一下。如果我们的JAR是通过springboot来打包的话，还会有这个问题吗？
解压springboot打的包，你会发现。springboot在外层添加了一层引导加载处理。这里不会存在javax.ws.rs.ext.Providers替换的问题，大家有时间也可以试试，欢迎大家一起讨论。