[dubbo-website] branch asf-site updated: Automated deployment: Tue Dec 3 18:35:50 UTC 2019 78109c240cc2b70a52ca77bc6717a56048bbd9ff

[gi...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

github-bot pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git


The following commit(s) were added to refs/heads/asf-site by this push:
     new 0740c33  Automated deployment: Tue Dec  3 18:35:50 UTC 2019 78109c240cc2b70a52ca77bc6717a56048bbd9ff
0740c33 is described below

commit 0740c3321f4bdc03212e80a063af84b04c9db796
Author: lixiaojiee <li...@users.noreply.github.com>
AuthorDate: Tue Dec 3 18:35:50 2019 +0000

    Automated deployment: Tue Dec  3 18:35:50 UTC 2019 78109c240cc2b70a52ca77bc6717a56048bbd9ff
---
 zh-cn/docs/dev/SPI.html | 2 +-
 zh-cn/docs/dev/SPI.json | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/zh-cn/docs/dev/SPI.html b/zh-cn/docs/dev/SPI.html
index 2d350f3..76170a2 100644
--- a/zh-cn/docs/dev/SPI.html
+++ b/zh-cn/docs/dev/SPI.html
@@ -99,7 +99,7 @@
 <p>这里带来另一个问题，<code>ExtensionLoader</code> 要注入依赖扩展点时，如何决定要注入依赖扩展点的哪个实现。在这个示例中，即是在多个<code>WheelMaker</code> 的实现中要注入哪个。</p>
 <p>这个问题在下面一点 <a href="#%E6%89%A9%E5%B1%95%E7%82%B9%E8%87%AA%E9%80%82%E5%BA%94">扩展点自适应</a> 中说明。</p>
 <h3>扩展点自适应</h3>
-<p><code>ExtensionLoader</code> 注入的依赖扩展点是一个 <code>Adaptive</code> 实例，直到扩展点方法执行时才决定调用是一个扩展点实现。</p>
+<p><code>ExtensionLoader</code> 注入的依赖扩展点是一个 <code>Adaptive</code> 实例，直到扩展点方法执行时才决定调用是哪一个扩展点实现。</p>
 <p>Dubbo 使用 URL 对象（包含了Key-Value）传递配置信息。</p>
 <p>扩展点方法调用会有URL参数（或是参数有URL成员）</p>
 <p>这样依赖的扩展点也可以从URL拿到配置信息，所有的扩展点自己定好配置的Key后，配置信息从URL上从最外层传入。URL在配置传递上即是一条总线。</p>
diff --git a/zh-cn/docs/dev/SPI.json b/zh-cn/docs/dev/SPI.json
index 4b0fb8d..f7fdd60 100644
--- a/zh-cn/docs/dev/SPI.json
+++ b/zh-cn/docs/dev/SPI.json
@@ -1,6 +1,6 @@
 {
   "filename": "SPI.md",
-  "__html": "<h1>扩展点加载</h1>\n<h2>扩展点配置</h2>\n<h3>来源：</h3>\n<p>Dubbo 的扩展点加载从 JDK 标准的 SPI (Service Provider Interface) 扩展点发现机制加强而来。</p>\n<p>Dubbo 改进了 JDK 标准的 SPI 的以下问题：</p>\n<ul>\n<li>JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。</li>\n<li>如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 <code>getName()</code> 获取脚本类型的名称，但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和 ruby 对应不起来，当用户执行 ruby  脚本时，会报不支持 ruby，而不是真正失败的原因。</li>\n<li>增加了对扩展点 IoC 和 AOP [...]
+  "__html": "<h1>扩展点加载</h1>\n<h2>扩展点配置</h2>\n<h3>来源：</h3>\n<p>Dubbo 的扩展点加载从 JDK 标准的 SPI (Service Provider Interface) 扩展点发现机制加强而来。</p>\n<p>Dubbo 改进了 JDK 标准的 SPI 的以下问题：</p>\n<ul>\n<li>JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。</li>\n<li>如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 <code>getName()</code> 获取脚本类型的名称，但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和 ruby 对应不起来，当用户执行 ruby  脚本时，会报不支持 ruby，而不是真正失败的原因。</li>\n<li>增加了对扩展点 IoC 和 AOP [...]
   "link": "/zh-cn/docs/dev/SPI.html",
   "meta": {}
 }
\ No newline at end of file