[jboss-cvs] JBossAS SVN: r73976 - projects/docs/trunk/AS_4/Server_Configuration_Guide/zh-CN.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Mon Jun 2 22:43:19 EDT 2008


Author: xhuang at jboss.com
Date: 2008-06-02 22:43:19 -0400 (Mon, 02 Jun 2008)
New Revision: 73976

Modified:
   projects/docs/trunk/AS_4/Server_Configuration_Guide/zh-CN/Clustering_Guide_HTTP.po
Log:
update

Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/zh-CN/Clustering_Guide_HTTP.po
===================================================================
--- projects/docs/trunk/AS_4/Server_Configuration_Guide/zh-CN/Clustering_Guide_HTTP.po	2008-06-02 22:09:23 UTC (rev 73975)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/zh-CN/Clustering_Guide_HTTP.po	2008-06-03 02:43:19 UTC (rev 73976)
@@ -9,13 +9,13 @@
 "Project-Id-Version: Clustering_Guide_HTTP\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-05-19 03:42+0000\n"
-"PO-Revision-Date: 2008-06-02 16:03+1000\n"
+"PO-Revision-Date: 2008-06-03 12:42+1000\n"
 "Last-Translator: Xi HUANG <xhuang at redhat.com>\n"
-"Language-Team:  <en at li.org>\n"
+"Language-Team: Chinese Simplified <kde-i18n-doc at lists.kde.org>\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"X-Generator: KBabel 1.11.4\n"
+"X-Generator: KAider 0.1\n"
 "Plural-Forms: nplurals=2; plural=n != 1;\n"
 
 #. Tag: title
@@ -1764,7 +1764,7 @@
 #: Clustering_Guide_HTTP.xml:372
 #, no-c-format
 msgid "Using deploy-hasingleton is very simple, but it does have two drawbacks:"
-msgstr ""
+msgstr "使用 deploy-hasingleton 非常简单,但它有两个缺点:"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:376
@@ -1773,7 +1773,7 @@
 "There is no hot-deployment feature for services in <literal>deploy-"
 "hasingleton</literal>. Redeploying a service that has been deployed to "
 "<literal>deploy-hasingleton</literal> requires a server restart."
-msgstr ""
+msgstr "<literal>deploy-hasingleton</literal> 里的服务不具有热部署功能。重部署 <literal>deploy-hasingleton</literal> 里的服务需要重启服务器。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:381
@@ -1784,13 +1784,13 @@
 "it will be providing services. Depending on how complex the deployment of "
 "your service is and what sorts of startup activities it engages in, this "
 "could take a while, during which time the service is not being provided."
-msgstr ""
+msgstr "如果主节点崩溃且另外一个节点成为主节点,单点登录服务需要完成整个部署过程后才能提供服务。根据你的服务的复杂程度以及所涉及的启动步骤,这可能需要一段时间,在此期间是不能提供单点登录服务的。"
 
 #. Tag: title
 #: Clustering_Guide_HTTP.xml:393
 #, no-c-format
 msgid "Mbean deployments using HASingletonController"
-msgstr ""
+msgstr "使用 HASingletonController 部署 MBean "
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:394
@@ -1805,7 +1805,7 @@
 "on your service telling it to begin providing service. If it determines it "
 "is no longer the master node, it invokes a method on your service telling it "
 "to stop providing service. Let's walk through an illustration."
-msgstr ""
+msgstr "如果你的服务是一个 MBean(非 ear、war 或 jar 形式的 J2EE 部署),你可以同时部署一个名为 HASingletonController 的服务来将其转换成 HA 单点登录服务。HASingletonController 的职责是和 HAPartition 服务一起监控群集系统并决定当前的主节点。如果决定了主节点,它会调用服务上的一个方法来告知它将开始提供服务。如果决定了该节点不再是主节点,它也会调用服务上的一个方法来告知它将停止提供服务。让我们来看一个例子。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:397
@@ -1815,7 +1815,7 @@
 "only thing special about it is it needs to expose in its MBean interface a "
 "method that can be called when it should begin providing service, and "
 "another that can be called when it should stop providing service:"
-msgstr ""
+msgstr "首先,我们有一个将成为 HA 单点登录服务的 MBean。唯一特殊的地方是它需要开放其 MBean 接口的一个方法,在开始提供服务时可以被调用,以及另外一个可以在停止服务时被调用的方法。"
 
 #. Tag: programlisting
 #: Clustering_Guide_HTTP.xml:400
@@ -1865,7 +1865,7 @@
 msgid ""
 "We used “startSingleton” and “stopSingleton” in the above example, but you "
 "could name the methods anything."
-msgstr ""
+msgstr "在这个例子里我们使用“startSingleton”和“stopSingleton”,不过你可以使用任何名字。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:405
@@ -1874,7 +1874,7 @@
 "Next, we deploy our service, along with an HASingletonController to control "
 "it, most likely packaged in a .sar file, with the following <literal>META-"
 "INF/jboss-service.xml</literal>:"
-msgstr ""
+msgstr "然后,我们部署这个服务,并用一个 HASingletonController 来控制它,我们通常会使用下面的 <literal>META-INF/jboss-service.xml</literal> 把它打包在一个 .sar 文件里:"
 
 #. Tag: programlisting
 #: Clustering_Guide_HTTP.xml:408
@@ -1942,7 +1942,7 @@
 #: Clustering_Guide_HTTP.xml:410
 #, no-c-format
 msgid "Voila! A clustered singleton service."
-msgstr ""
+msgstr "这就是群集的单点登录服务。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:412
@@ -1957,7 +1957,7 @@
 "deployed; it doesn't wait until the node becomes the master node. So, the "
 "service could be primed and ready to go, just waiting for the controller to "
 "implement startSingleton() at which point it can immediately provide service."
-msgstr ""
+msgstr "这个方法的显而易见的缺点是它只能用于 MBean。其优点是上面的例子可以置于 <literal>deploy</literal> 或 <literal>farm</literal> 里,因此可以进行热部署或 farm 部署。而且,如果这个服务示例具有复杂的、消耗时间的启动过程,它们都可以在 create() 或 start() 方法里实现。只要这个服务被部署,JBoss 就会调用 create() 和 start() 而不需等到它成为主节点。所以,这个服务时待发的,只要等到控制器执行 startSingleton() 它就可以立即提供服务。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:415
@@ -1967,7 +1967,7 @@
 "an interesting example of using an HASingletonController. Here is its "
 "deployment descriptor (extracted from the <literal>deploy/deploy-hasingleton-"
 "service.xml</literal> file):"
-msgstr ""
+msgstr "上面讨论的 jboss.ha:service=HASingletonDeployer 服务本身就是一个有趣的使用 HASingletonController 的例子。下面是它的部署描述符(其内容从 <literal>deploy/deploy-hasingleton-service.xml</literal> 文件提取):"
 
 #. Tag: programlisting
 #: Clustering_Guide_HTTP.xml:418
@@ -2030,12 +2030,14 @@
 "the location of the directory the <literal>MainDeployer</literal> should "
 "deploy/undeploy."
 msgstr ""
+"这里有些有趣的东西。首先,被控制的服务是 <literal>MainDeployer</literal> 服务,它是 JBoss 里的核心部署服务。也就是说,在编码时它并不是打算被 <literal>HASingletonController</literal> 控制的服务。但这仍然可以运行!其次,目标启动和停止的方法是“deploy”和“undeploy”。它们并不要求具有特定的名称,即使它们逻辑上的功能是“start”和“stop”。这里被调用的方法的功能更象是“do”和 “undo”。最后,请注意“<literal>TargetStart(Stop)MethodArgument</literal>”属性。你的单点登录服务的启动/停止方法可以带有参数,这里是 <literal>MainDeployer<"
+"/literal> 应该部署/卸载的目录的位置。"
 
 #. Tag: title
 #: Clustering_Guide_HTTP.xml:428
 #, no-c-format
 msgid "HASingleton deployments using a Barrier"
-msgstr ""
+msgstr "使用 Barrier 部署 HASingleton"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:429
@@ -2045,7 +2047,7 @@
 "stopped whenever the content of deploy-hasingleton gets deployed/undeployed, "
 "(i.e., whenever the current node becomes the master), need only specify a "
 "dependency on the Barrier mbean:"
-msgstr ""
+msgstr "通常部署在 deploy 或 farm 里、每当 deploy-hasingleton 的内容部署/卸载时被启动/停止的服务(例如,每当当前的节点成为主节点时)只需要在 Barrier mbean 上指定一个依赖关系:"
 
 #. Tag: programlisting
 #: Clustering_Guide_HTTP.xml:431
@@ -2074,6 +2076,8 @@
 "and stopped in tandem with the Barrier. When the BarrierController is "
 "undeployed the Barrier is destroyed too."
 msgstr ""
+"这种方法是 BarrierController 和 jboss.ha:service=HASingletonDeployer MBean 一起被部署并侦听 JMX 通知。BarrierController 是一个相对简单的 MBean,它订阅并接收任何系统里的 JMX 通知。它使用接收的通知来控制动态创建的名为 Barrier 的 MBean 的生命周期。当 BBarrierController 被部署时,Barrier 被初始化、注册以及进入 CREATE 状态。之后,当收到符合的 JMX 通知时,BarrierController 启动和停止这个 Barrier。因此,其他服务只需要用普通的&lt;depends&gt; 标签来实现对 Barrier MBean 的依赖,且它们将和 Barrier "
+"一起被启动或停止。当 BarrierController 被卸载时,Barrier 也被销毁。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:437
@@ -2082,7 +2086,7 @@
 "This provides an alternative to the deploy-hasingleton approach in that we "
 "can use farming to distribute the service, while content in deploy-"
 "hasingleton must be copied manually on all nodes."
-msgstr ""
+msgstr "这提供了 deploy-hasingleton 方法之外的一个途径:我们可以用 farming 来分发服务,而 deploy-hasingleton 里的内容必须在所有节点上手工复制。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:440
@@ -2093,7 +2097,7 @@
 "on the master node. This is different with the deploy-hasingleton approach "
 "that will only deploy (instantiate/create/start) the contents of the deploy-"
 "hasingleton directory on one of the nodes."
-msgstr ""
+msgstr "从另外一方面来说,barrier-dependent 服务将在所有节点上被初始化/创建(也就是调用的任何 create() 方法),但仅仅在主节点上启动。这和 deploy-hasingleton 方法不同之处就是它只部署(初始化/创建/启动)其中一个节点上的 deploy-hasingleton 目录里的内容。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:444
@@ -2102,7 +2106,7 @@
 "So services depending on the barrier will need to make sure they do minimal "
 "or no work inside their create() step, rather they should use start() to do "
 "the work."
-msgstr ""
+msgstr "所以,依赖于 barrier 的服务将需要确保在 create() 步骤的内容最小或没有,它们应该使用 start() 来执行具体的工作。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:448
@@ -2114,13 +2118,13 @@
 "literal> to control services that need to be \"destroyed\" as part of their "
 "normal “undeploy” operation (like, for example, an <literal>EJBContainer</"
 "literal>) will not have the desired effect."
-msgstr ""
+msgstr "Barrier 控制依赖服务的启动/停止,但不控制它们的销毁,这只在 <literal>BarrierController</literal> 滋身被销毁/卸载时才发生。因此,使用 <literal>Barrier</literal> 来控制需要作为常规卸载操作(如 <literal>EJBContainer</literal>)一部分来销毁的服务将不会有所希望的效果。"
 
 #. Tag: title
 #: Clustering_Guide_HTTP.xml:457
 #, no-c-format
 msgid "Determining the master node"
-msgstr ""
+msgstr "决定主节点"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:458
@@ -2130,7 +2134,7 @@
 "that each node in the cluster can independently react to changes in cluster "
 "membership and correctly decide whether it is now the “master node”. How is "
 "this done?"
-msgstr ""
+msgstr "不同的群集单点登录管理策略都依赖于群集里的每个节点都可以独立地对群集成员资格的变动作出反应并正确地决定它是否是当前的主节点。这是怎么做到的呢?"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:461
@@ -2145,7 +2149,7 @@
 "CurrentView attribute in the <literal>jboss:service=DefaultPartition</"
 "literal> mbean. Every member of the cluster will have the same view, with "
 "the members in the same order."
-msgstr ""
+msgstr "在 JBoss AS 4.2.0 之前,实现的方法是固定和简单的。对于群集里的每个成员,HAPartition MBean 都维护一个名为 CurrentView 属性,它基本上是一个群集里当前节点的有序的列表。当节点加入或离开群集时,JGroups 会确保群集里的每个节点都获得更新的视图。你可以在 JMX 控制台里查看 <literal>jboss:service=DefaultPartition</literal> mbean 里的 CurrentView 属性来获得当前视图。群集里的每个成员都将具有包含相同顺序的成员的视图。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:464
@@ -2156,7 +2160,7 @@
 "the order of nodes in the view will reflect the order in which they joined "
 "the cluster (although this is not always the case, and should not be assumed "
 "to be the case.)"
-msgstr ""
+msgstr "例如,我们有一个具有 4 个节点的群集,从节点 A 到 D,当前视图可以表达成 {A, B, C, D}。通常,视图里的节点的顺序将反映它们加入群集的顺序(但并非总是如此)。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:467
@@ -2169,7 +2173,7 @@
 "are deployed where, in view order. So, on every node in the cluster, the "
 "<literal>HAPartition</literal> service knows that the view with respect to "
 "the Foo service is {A, C, D} (no B)."
-msgstr ""
+msgstr "让我们继续这个例子,如果有一个名为 Foo 的单点登录服务(也就是 <literal>HASingletonController</literal>)部署在群集里,假设在节点 B 上。<literal>HAPartition</literal> 服务维护一个关于群集里部署的服务的注册表。所以,对于群集里的每个节点,<literal>HAPartition</literal> 服务都知道和 Foo 服务相关的视图是 {A, C, D} (没有 B)。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:471
@@ -2183,7 +2187,7 @@
 "independently decide if it is now the master. The Foo service on each node "
 "does this by checking if they are the first member of the view – if they "
 "are, they are the master; if not, they're not. Simple as that."
-msgstr ""
+msgstr "每当 Foo 服务的群集拓扑结构发生变化时,<literal>HAPartition</literal> 服务都将调用 Foo 的一个回调方法,通知它新的拓扑结构。所以,例如,当 Foo 在 D 上启动时,运行在 A、C 和 D 上的 Foo 服务的回调方法都将被调用,通知它新的新的 Foo 视图是 {A, C, D}。回调方法给出了足够的信息,每个节点都可以独立地决定它是否是当前的主节点。每个节点上的 Foo 服务通过检查它们是否是视图里的第一个成员来实现这一点 - 如果是,它是主节点;如果不是,则它不是主节点。就是这么简单。"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:475
@@ -2194,5 +2198,5 @@
 "A, C and D would get a callback with a new view for Foo of {C, D, A}. C "
 "would remain the master – there's nothing magic about A that would cause it "
 "to become the master again just because it was before."
-msgstr ""
+msgstr "如果 A 崩溃或关闭了,C 和 D 上的 Foo 的回调方法将被调用,获取新的视图 {C, D}。C 将成为主节点。如果 A 重新启动,A、C 和 D 上的 Foo 的回调方法将被调用,获取新的视图 {C, D, A}。C 将仍是主节点 - 而不会因为 A 以前是主节点而重新成为主节点。"
 




More information about the jboss-cvs-commits mailing list