java SPI 与cooma（dubbo 微容器改良品）--1

java 的spi（Service provider interface）主要是为了框架的扩展和组件替换而产生的，与当今流行的IOC概念类似。

    java spi的实现：

. .ServiceLoader< >

A simple service-provider loading facility.

A service is a well-known set of interfaces and (usually abstract) classes. Aservice provider is a specific implementation of a service. The classes in a provider typically implement the interfaces and subclass the classes defined in the service itself. Service providers can be installed in an implementation of the Java platform in the form of extensions, that is, jar files placed into any of the usual extension directories. Providers can also be made available by adding them to the application's class path or by some other platform-specific means.

For the purpose of loading, a service is represented by a single type, that is, a single interface or abstract class. (A concrete class can be used, but this is not recommended.) A provider of a given service contains one or more concrete classes that extend this service type with data and code specific to the provider. The provider class is typically not the entire provider itself but rather a proxy which contains enough information to decide whether the provider is able to satisfy a particular request together with code that can create the actual provider on demand. The details of provider classes tend to be highly service-specific; no single class or interface could possibly unify them, so no such type is defined here. The only requirement enforced by this facility is that provider classes must have a zero-argument constructor so that they can be instantiated during loading.

The file's name is the fully-qualified of the service's type. The file contains a list of fully-qualified binary names of concrete provider classes, one per line. Space and tab characters surrounding each name, as well as blank lines, are ignored. The comment character is '#' ('\u0023', NUMBER SIGN); on each line all characters following the first comment character are ignored. The file must be encoded in UTF-8.

If a particular concrete provider class is named in more than one configuration file, or is named in the same configuration file more than once, then the duplicates are ignored. The configuration file naming a particular provider need not be in the same jar file or other distribution unit as the provider itself. The provider must be accessible from the same class loader that was initially queried to locate the configuration file; note that this is not necessarily the class loader from which the file was actually loaded.

Providers are located and instantiated lazily, that is, on demand. A service loader maintains a cache of the providers that have been loaded so far. Each invocation of the method returns an iterator that first yields all of the elements of the cache, in instantiation order, and then lazily locates and instantiates any remaining providers, adding each one to the cache in turn. The cache can be cleared via the method.

Service loaders always execute in the security context of the caller. Trusted system code should typically invoke the methods in this class, and the methods of the iterators which they return, from within a privileged security context.

Instances of this class are not safe for use by multiple concurrent threads.

Unless otherwise specified, passing a null argument to any method in this class will cause a to be thrown.

Example Suppose we have a service typecom.example.CodecSet which is intended to represent sets of encoder/decoder pairs for some protocol. In this case it is an abstract class with two abstract methods:

public abstract Encoder getEncoder(String encodingName); public abstract Decoder getDecoder(String encodingName);

Each method returns an appropriate object or null if the provider does not support the given encoding. Typical providers support more than one encoding.

If com.example.impl.StandardCodecs is an implementation of the CodecSet service then its jar file also contains a file named

META-INF/services/com.example.CodecSet

This file contains the single line:

com.example.impl.StandardCodecs    # Standard codecs

The CodecSet class creates and saves a single service instance at initialization:

private static ServiceLoader
     
       codecSetLoader     = ServiceLoader.load(CodecSet.class);
     

To locate an encoder for a given encoding name it defines a static factory method which iterates through the known and available providers, returning only when it has located a suitable encoder or has run out of providers.

public static Encoder getEncoder(String encodingName) {     for (CodecSet cp : codecSetLoader) {         Encoder enc = cp.getEncoder(encodingName);         if (enc != null)             return enc;     }     return null; }

A getDecoder method is defined similarly.

Usage Note If the class path of a class loader that is used for provider loading includes remote network URLs then those URLs will be dereferenced in the process of searching for provider-configuration files.

This activity is normal, although it may cause puzzling entries to be created in web-server logs. If a web server is not configured correctly, however, then this activity may cause the provider-loading algorithm to fail spuriously.

A web server should return an HTTP 404 (Not Found) response when a requested resource does not exist. Sometimes, however, web servers are erroneously configured to return an HTTP 200 (OK) response along with a helpful HTML error page in such cases. This will cause a to be thrown when this class attempts to parse the HTML page as a provider-configuration file. The best solution to this problem is to fix the misconfigured web server to return the correct response code (HTTP 404) along with the HTML error page.

Type Parameters:

<S> The type of the service to be loaded by this loader

Since:

1.6

Author:

Mark Reinhold

  根据实现文档，写了demo：

一个接口：

package com.doctor.spi.service;/** * @author sdcuike * *         Created on 2016年7月24日 下午10:21:37 */public interface Car {    void run();}

二个实现：

package com.doctor.spi.service.impl;import com.doctor.spi.service.Car;/** * @author sdcuike * *         Created on 2016年7月24日 下午10:22:28 */public class RacingCar implements Car {    @Override    public void run() {        System.out.println("RacingCar Running...");    }}

package com.doctor.spi.service.impl;import com.doctor.spi.service.Car;/** *  * @author sdcuike * *         Created on 2016年7月24日 下午10:23:11 */public class SportCar implements Car {    @Override    public void run() {        System.out.println("SportCar Running...");    }}

按照要求，在文件：META-INF\services\com.doctor.spi.service.Car 有以下内容：

com.doctor.spi.service.impl.RacingCarcom.doctor.spi.service.impl.SportCar

即：接口的实现类信息。

运行main方法：

package com.doctor.spi;import java.util.ServiceLoader;import com.doctor.spi.service.Car;/** * @author sdcuike * *         Created on 2016年7月24日 下午10:20:45 */public class SPIDemo {    public static void main(String[] args) {        ServiceLoader
    
      serviceLoader = ServiceLoader.load(Car.class);        serviceLoader.forEach(SPIDemo::runCar);    }    static void runCar(Car car) {        System.out.println(car);        car.run();    }}
    

运行的结果：

com.doctor.spi.service.impl.RacingCar@1fb3ebebRacingCar Running...com.doctor.spi.service.impl.SportCar@548c4f57SportCar Running...

只要按照约定配置，把接口的实现类配置到目的文件内，就可以“注入"它们。

看一下实现类：189行：

private static final String PREFIX = "META-INF/services/";

读取的配置文件必须在该目录下，好像maven和哲学一样，约定大于配置。

实现类的实例化：370行和380行：

c = Class.forName(cn, false, loader);

S p = service.cast(c.newInstance());                providers.put(cn, p);

? . . .newInstance() throws ,  要求接口实现类必须有默认构造函数（即不带参数的构造函数），这样才不会出现错误。

java 给了一个很好的IOC的实现原型，让我们可以对框架进行扩展与组件的替换相对容易很多，但java 自带的spi实现

不是那么的灵活，比如spring ioc容易的依赖注入可以根据类型或者by name 注入，为了更接近spring ioc的概念，dubbo自己在java spi的实现机制原型下，结合dubbo本身独有的扩展功能需求，实现了自己的微容器。

但dubbo的微容器结合了功能之外的很多东西，比如RPC。所以，阿里系就出现了个

https://github.com/alibaba/cooma

待续。。。。

参考：