Wrapper类不要自动加载。

0.1.0的实现中，com.metaframe.cooma.ExtensionLoader#loadExtensionClasses方法会直接加载有拷贝构造函数的扩展点到com.metaframe.cooma.ExtensionLoader#cachedWrapperClasses中。

这个导致不能手动配置Wapper有哪些。

解决方法

getExtension方法，添加Wrapper list参数，显式指定需要的Wrapper

模型关系添加图示说明。

这样可以避免没有扩展点的Adaptive Instance的NPE

如果调整了ClassLoader，可以通过这种方式加载到新的扩展点

com.metaframe.cooma.ExtensionLoader#createExtension出错，则会每次getExtension都再执行createExtension，有性能问题！

处理方式和getAdaptiveExtension一样！

代码还有service这样的字眼，改成extension。

是用service，还是ExtensionLoader，或是其它还要再思考一下。

0.1.0的格式：

# Comment 1
impl1=com.foo.ext1.impl.Ext1Impl1 #Hello World
impl2=com.foo.ext1.impl.Ext1Impl2  # Comment 2
   impl3=com.foo.ext1.impl.Ext1Impl3 # with head space

使用name=impl-class，可以不用加载类文件即知道扩展的点的名字。

0.2.0中期望加上属性，格式：

# Comment 1
name=impl.class(attrib1=value1,attrib2=value2)

foo1=com.foo.Impl1(isProvider,order=3)
foo2=com.foo.Impl2(isConsumer,order=5)

有了这些属性，方法ExtensionLoader使用者，可以过滤，查到需要扩展，自动加载

去Logging适配。让实现先尽量简单！

直接使用SLF4J。

目前Wrapper在调用getExtesion方法时创建，所以不是单例的。

这和Extension的管理不一样。

• 没有缺省构造函数的加载被跳过
• 有warn日志说明

目前没有考虑实例的销毁，API也上没有。

如果多次初始化，对象持有重的资源，会有泄露问题

原来这个Ticket的内容是：

添加UT： 没有配置文件中没有扩展点名，从实现类的Extension注解上读取

这个是Dubbo中ExtensionLoader的实现策略，为了兼容。Cooma中没有必要了。

这个方法，目前对于返回带有Wrapper的实例的情况下，返回是错误的。

另外，从Dubbo中这个方法的使用Case来看（反查扩展名），场景可以通过使用方存过扩展名来解决。

要加上ut

getAdaptiveInstance、getDefaultExtension方法都可以指定Wrapper。
#12 中只实现了getExtension方法。

PS： 修改对应的文档

格式示例

impl1=com.foo.Impl1
*=com.foo.ManualAdaptive
+wrapper1=com.foo.Wrapper1

说明

• 前缀 * 表示 是 Adaptive Class。
  约定调整！不用实现类上加@Adaptive注解！
• 前缀 + 表示 是 Wrapper Class。
  约定调整！不再以是否有拷贝构造函数来判定是否是Extension Wrapper。

问题

注释有的是英文有的是中文。

英文注释质量不好。

解决方法

代码中使用中文的注释。先要准确的表达自己的意思。

文档写一份英文的。

可以用在OSGi等环境中

com.metaframe.cooma.ExtensionLoader#rethrowAsRuntime方法，统一加上new IllegalStateException。

这样有调用栈在异常中，方便排错。

目前方式是在接口上加@\Extension注解，否则ExtensionLoader调用出异常，拒绝税控。

如果不能方便修改接口类代码，这个就不方便了。

一般这不是问题，使用cooma管理的是自己的实现，可以改接口代码。

把获取Adaptive注释上配置的Key值的逻辑从Proxy InvocationHandler中移到createAdaptiveInstance中。

提高热操作（Proxy调用）的效率。

文档上、代码上修改

• ExtensionLoader类方法调用关系
• 是否线程安全（即是否可以并发）

Wrapper的使用方法由自动获得改成了指定。

相关的Issue #12 #46

应该在com.metaframe.cooma.ExtensionLoader#getAdaptiveExtension方法中，完全同步。

和com.metaframe.cooma.ExtensionLoader#getExtensionClasses处理方式一致。

getExtension有则返回扩展点，否则出异常。（异常中会给出可能的原因。）

这是大部分情况下使用需求

getDefaultExtension方法会返回null表示没有缺省扩展点。

两个方法的返回方式不一致。

统一throw IllegalStateException表示没有扩展点。

通过hasExtension方法来确认是否有此扩展点。

目前的实现中，没有用到Wrapper的名字。

Wrapper的配置方式和Extension一样，所以是有名字的。

本Issue是实现 #12 的前提。

修改代码及文档

• 扩展点/Extension Point/要扩展的接口
• 扩展/Extension/扩展点实现类
• 扩展实例/Extension Instance/扩展点实现类的实例

1. 获得扩展点
2. 自适应实例
3. 注入相关的扩展点
4. 扩展点的Wrapper

动态代码的部分，考虑使用Java代理来完成功能。
精简三库依赖

目前的实现是写死的：

private static final String SERVICES_DIRECTORY = "META-INF/extensions/";

可以使用-D选项来配置：

-Dcooma.extension.dir="META-INF/cooma/extensions/"

或是getExtensionLoader时设置，这样可以在一个进程中选择不同的目录。
比如dubbo库在 MF/dubbo ，napoli在 MF/napoli

也会需要配置 多个加载目录的需要，这样方便兼容老的Extension实现，不用修改Extension配置文件目录。