[jboss-cvs] JBossAS SVN: r83447 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Jan 26 22:57:42 EST 2009
Author: gcintra
Date: 2009-01-26 22:57:42 -0500 (Mon, 26 Jan 2009)
New Revision: 83447
Modified:
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_Clustered_Singleton_Services.po
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_EJBs.po
Log:
in progress
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_Clustered_Singleton_Services.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_Clustered_Singleton_Services.po 2009-01-27 03:22:59 UTC (rev 83446)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_Clustered_Singleton_Services.po 2009-01-27 03:57:42 UTC (rev 83447)
@@ -9,7 +9,7 @@
"Project-Id-Version: Clustering_Guide_Clustered_Singleton_Services\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-01-22 14:43+1000\n"
+"PO-Revision-Date: 2009-01-27 12:44+1000\n"
"Last-Translator: Glaucia Cintra <gcintra at redhat.com>\n"
"Language-Team: Portuguese <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -35,13 +35,13 @@
"restarted on the new master. Thus, other than a brief interval when one "
"master has stopped and another has yet to take over, the service is always "
"being provided by one but only one node."
-msgstr ""
+msgstr "Um serviço singleton em cluster (também conhecido como um singleton HA) é um serviço que é desenvolvido em nós múltiplos em um cluster, mas que oferece seu serviço em somente um dos nós. O nó executando o serviço singleton é geralmente chamado de nó master. Quando um master falha ou é fechado, outro master é selecionado dos nós restantes e o serviço é reiniciado no master novo. Além disso, ao invés de um intervalo breve, quando um master parou e outro ainda não tomou seu lugar, o serviço é sempre fornecido por um mas somente um nó. "
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:9
#, no-c-format
msgid "Topology after the Master Node fails"
-msgstr ""
+msgstr "Topologia após a falha do Nó Master"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:17
@@ -55,13 +55,13 @@
"different nodes in the cluster start and stop; based on those notifications "
"each node in the cluster can independently (but consistently) determine if "
"it is now the master node and needs to begin providing a service."
-msgstr ""
+msgstr "O JBoss Application Server (AS) fornece suporte para diversas estratégias para ajudá-lo a implementar os serviços singleton em cluster. Nesta seção, exploraremos as diferentes estratégias. Todas as estratégias são construídas sob o serviço de HAPartition descrito na apresentação. Estas estratégias confiam no <literal>HAPartition</literal> para fornecer notificações quando nós diferentes em cluster iniciam e param. Baseados nestas notificações, cada nó em cluster pode determinar, de forma independente porém consistente, se ele é o nó master e se necessita de um serviço. "
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:22
-#, fuzzy, no-c-format
+#, no-c-format
msgid "HASingletonDeployer service"
-msgstr "cliente.deployer-service.xml"
+msgstr "Serviço HASingletonDeployer "
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:23
@@ -82,6 +82,8 @@
"service when it stops being the master (typically at server shutdown) is to "
"undeploy the contents of <literal>deploy-hasingleton</literal>."
msgstr ""
+"A estratégia mais simples e mais usada para a implementação em um singleton HA é pegar uma implantação comum (war, ear, jar, aquilo que geralmente se coloca no deploy) e implantá-la no diretório <literal>$JBOSS_HOME/server/all/"
+"deploy-hasingleton</literal> ao invés de implantá-la no diretório <literal>deploy</literal>. O diretório <literal>deploy-hasingleton</literal> não fica em deploy ou farm, portanto seu conteúdo não é automaticamente implantado quando uma instância AS inicia. Ao invés disso, a implantação do conteúdo de seu diretório é realizado por um serviço especial, o MBean <literal>jboss.ha: service=HASingletonDeployer</literal> ( o qual é implementado através do arquivo deploy/deploy-hasingleton-service.xml.) O serviço HASingletonDeployer é por si só um HA Singleton, cuja tarefa quando se torna master é implementar o conteúdo do deploy-hasingleton e quando deixa de ser master (geralmente ao fechar o servidor) é cancelar a implantação do conteúdo de <literal>deploy-hasingleton</literal>."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:26
@@ -92,13 +94,13 @@
"the master node cleanly shuts down, they will be cleanly undeployed as part "
"of shutdown. If the master node fails or is shut down, they will be deployed "
"on whatever node takes over as master."
-msgstr ""
+msgstr "Portanto, ao colocar suas implementações em <literal>deploy-hasingleton</literal>, você sabe que serão implementadas somente no nó master em cluster. Se o nó master simplesmente fechar, as implementações serão simplesmente canceladas também. Se o nó master falhar ou se for fechado, ele será implementado em qualquer nó que substitua o master. "
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:29
#, no-c-format
msgid "Using deploy-hasingleton is very simple, but it does have two drawbacks:"
-msgstr ""
+msgstr "Usar o deploy-hasingleton é muito simples, mas possui dois defeitos:"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:33
@@ -108,6 +110,9 @@
"hasingleton</literal>. Redeploying a service that has been deployed to "
"<literal>deploy-hasingleton</literal> requires a server restart."
msgstr ""
+"Não existe um recurso hot-deployment para serviços em <literal>deploy-"
+"hasingleton</literal>. É necessário que reinicie o servidor para implementar um serviço novamente que já foi implementado no <literal>deploy-"
+"hasingleton</literal>. "
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:38
@@ -118,13 +123,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 "Se um nó master falhar e outro nó substituí-lo, seu serviço de singleton precisa passar por todo o processo de implementação antes que forneça os serviços. Dependendo da complexidade da implementação do seu serviço, e dos tipos de atividades de inicialização existam, pode levar um tempo considerável sem o serviço. "
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:50
#, no-c-format
msgid "Mbean deployments using HASingletonController"
-msgstr ""
+msgstr "Implementações do MBean usando o HASingletonController"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:51
@@ -139,7 +144,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 "Se seu serviço é um Mbean (ou seja, não uma implementação J2EE como um ear ou war ou jar), você pode implantá-lo junto com um serviço chamado HASingletonController para que ele mude para o HA singleton. É o trabalho do HASingletonController junto ao serviço HAPartition para monitorar o cluster e determinar se ele é o nó master para seu serviço. Se ele determinar que se tornou o nó master, ele invoca um método em seu serviço, informando-o a iniciar o serviço fornecido. Se ele determinar que não é mais o nó master, ele invoca o método em seu serviço, informando-o para parar de fornecer o serviço. Vamos às ilustrações:"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:54
@@ -149,7 +154,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 "Primeiro, temos um serviço MBean que queremos para fazer um HA Singleton. A única coisa especial sobre isso é que ele precisa expor um método em sua interface do MBean, que pode ser chamado quando precisar iniciar o fornecimento do serviço e outro que pode ser chamado quando precisar parar o fornecimento do mesmo:"
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:57
@@ -199,7 +204,7 @@
msgid ""
"We used “startSingleton” and “stopSingleton” in the above example, but you "
"could name the methods anything."
-msgstr ""
+msgstr "Nós usamos o “startSingleton” e “stopSingleton” no exemplo acima, mas você pode nomear da forma que desejar. "
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:62
@@ -209,6 +214,8 @@
"it, most likely packaged in a .sar file, with the following <literal>META-"
"INF/jboss-service.xml</literal>:"
msgstr ""
+"Depois, nós implementamos nossos serviços, junto com um HASingletonController para controlá-lo, provavelmente empacotado em um arquivo .sar, com o seguinte <literal>META-"
+"INF/jboss-service.xml</literal>:"
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:65
@@ -291,7 +298,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 "O único problema é que ele funciona somente para o MBeans. As vantagens são que os exemplos acima podem ser colocados n o <literal>deploy</literal> ou <literal>farm</literal> e porisso pode ser implementado imediatamente e em farm. Da mesma forma, se nosso serviço de exemplo possui requerimentos de inicialização que tomam muito tempo ou complexos, eles podem ser implementados nos métodos create() ou start(). O JBoss irá invocar o create() e start() assim que o serviço seja implementado. Ele não espera até que o nó se torne um nó master. Portanto, o serviço pode ficar preparado, esperando somente que o controller implemente o startSingleton(), para fornecer o serviço imediatamente. "
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:72
@@ -302,6 +309,8 @@
"deployment descriptor (extracted from the <literal>deploy/deploy-hasingleton-"
"service.xml</literal> file):"
msgstr ""
+"O serviço jboss.ha:service=HASingletonDeployer discutido acima é por si só um exemplo interessante do uso de um HASingletonController. Segue aqui seu descritor de implementação (extraído do arquivo <literal>deploy/deploy-hasingleton-"
+"service.xml</literal>):"
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:75
@@ -363,13 +372,13 @@
"singleton service's start/stop methods can take an argument, in this case "
"the location of the directory the <literal>MainDeployer</literal> should "
"deploy/undeploy."
-msgstr ""
+msgstr "Alguns ítens interessantes aqui. Primeiro, o serviço que está sendo controlado é o serviço <literal>MainDeployer</literal>, o qual é o serviço central da implementação no JBoss. Ou seja, é um serviço que não foi escrito com a intenção de ser controlado por um <literal>HASingletonController</literal>. Mas ainda funciona! Em segundo lugar, o métodos do alvo start e stop são \"deploy\" e \"undeploy\". Nennum requerimento que elese tenham um nome específico, ou até mesmo que tenham uma funcionalidade \"start\" e \"stop\" lógica. Aqui a funcionalidade dos métodos invocados é mais como um \"faça\" e \"desfaça\". E finalmente, note os atributos do “<literal>TargetStart(Stop)MethodArgument</literal>”. Seus métodos start/stop do serviço singleton podem tomar um argumento, neste caso o local do diretório que o <literal>MainDeployer</literal> deve fazer o deploy/undeploy. "
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:85
#, no-c-format
msgid "HASingleton deployments using a Barrier"
-msgstr ""
+msgstr "Implementações HASingleton usando um Barrier"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:86
@@ -379,7 +388,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 "Serviços implementados geralmente dentro do deploy ou farm que queiram ser iniciados ou interrompidos com o start/stop quando o conteúdo do deploy-hasingleton receber a ordem deploy/undeploy, (ou seja, sempre que um nó atual se tornar master), precisa especificar somente uma dependência no mbean do Barrier:"
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:88
@@ -407,7 +416,7 @@
"Barrier MBean using the usual <depends> tag, and they will be started "
"and stopped in tandem with the Barrier. When the BarrierController is "
"undeployed the Barrier is destroyed too."
-msgstr ""
+msgstr "A forma que ele funciona é que o BarrierController é implementado junto com o jboss.ha:service=HASingletonDeployer MBean e espera pelas notificações do JMX a partir dele. Um BarrierController é um MBean relativamente simples que pode se inscrever para receber qualquer notificação do JMX no sistema. Ele usa as notificações recebidas para controlar o ciclo de vida de um Mbean criado de forma dinâmica, chamado Barrier. O Barrier é instanciado, registrado e colocado no estado CREATE quando o Barrier Controller é implementado. Depois disso, o BarrierController inicia e interrompe o Barrier quando coincide com as notificações do JMX recebidas. Assim, outros serviços precisam depender somente do Barrier MBean, usando a aba comum <depende> e eles serão iniciados e interrompidos em tandem com o Barrier. Quando a implementação do BarrierController é cancelada com o undeploy o Barrier é destruído também. "
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:94
@@ -416,7 +425,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 "Isto fornece uma alternativa para o deploy-hasingleton, onde podemos usar o farming para distribuir o serviço, enquanto o conteúdo no deploy-singleton deve ser copiado manualmente em todos os nós. "
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:97
@@ -427,7 +436,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 "Por um outro lado, o serviço barrier-dependent será instanciado/criado (ou seja qualquer método create() invocado) em todos os nós, mas será iniciado somente no nó master. Isto é diferente com o deploy-hasingleton que implementará (instanciar/criar/iniciar) o conteúdo do diretório deploy-hasingleton em um dos nós. "
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:101
@@ -436,7 +445,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 "Portanto serviços que dependem no barrier, precisam assegurar que farão o mínimo de trabalho possível em seu passo create(), e devem utilizar o start() para tal."
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:104
@@ -455,12 +464,16 @@
"normal “undeploy” operation (like, for example, an <literal>EJBContainer</"
"literal>) will not have the desired effect."
msgstr ""
+"O Barrier controla o start/stop dos serviços dependentes, mas não controla a destruição dos mesmos, a qual acontece quando o <literal>BarrierController</"
+"literal> destroy/cancela a implementação de si mesmo. Assim, usando o <literal>Barrier</"
+"literal> para controlar serviços que precisam ser \"destruídos\" como parte de sua operação de undeploy comum (como por exemplo, um <literal>EJBContainer</"
+"literal>) não obterá o efeito desejado."
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:114
#, no-c-format
msgid "Determining the master node"
-msgstr ""
+msgstr "Determinando o nó master"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:115
@@ -470,7 +483,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 "As diversas estratégias de gerenciamento do singleton em cluster, dependem do fato de que cada nó em cluster pode reagir independente das mudanças no grupo de cluster e decidir de forma correta se é o \"nó master\" ou não. Como isto é feito?"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:118
@@ -486,6 +499,8 @@
"literal> mbean. Every member of the cluster will have the same view, with "
"the members in the same order."
msgstr ""
+"Antes do JBoss AS 4.2.0, a metodologia para isto era fixa e simples. Para cada membro do cluster, o mbean do HAPartition mantém um atributo chamado CurrentView, o qual é basicamente uma lista ordenada de membros atuais do cluster. Como os nós se juntam e deixam o cluster, o JGroups assegura que cada membro sobrevivente do cluster recebe uma visão atualizada. Você poderá ver a visualização atual, visitando o console do JMX e procurando pelo atributo CurrentView no mbean do <literal>jboss:service=DefaultPartition</"
+"literal>. Todos os membros do cluster terão a mesma visualização, com os membros na mesma ordem."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:121
@@ -496,7 +511,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 "Digamos, por exemplo, que temos um cluster de 4 nós, nós A até D, e a visualização atual pode ser expressada como {A,B,C,D}. Ou seja, a ordem dos nós na visualização refletirá a ordem no qual eles estão reunidos no cluster (apesar que este não é o caso e não deva ser entendido como tal). "
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:124
@@ -510,6 +525,9 @@
"<literal>HAPartition</literal> service knows that the view with respect to "
"the Foo service is {A, C, D} (no B)."
msgstr ""
+"Prosseguindo em nosso exemplo, digamos que existe um serviço singleton (ou seja, um <literal>HASingletonController</literal>) chamado Foo que é implementado ao redor do cluster, exceto, por qualquer razão, no B. O serviço <literal>HAPartition</"
+"literal> mantém no cluster um registro dos serviços que foram implementados e onde, em ordem de visualização. Portanto, em todos os nós em cluster, o serviço <literal>HAPartition</"
+"literal> sabe que a visualização a respeito do serviço Foo é {A, C, D} (e não B)."
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:128
@@ -524,6 +542,8 @@
"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 ""
+"Quando houver uma mudança na topologia do cluster do serviço Foo, o serviço <literal>HAPartition</"
+"literal> invoca uma chamada de retorno no Foo, notificando-o da nova topologia. Portanto, por exemplo, quando o Foo iniciar em D, o serviço Foo rodando em A, C e D receberam uma chamada de retorno informando-os da nova visualização para Foo {A, C, D}. Esta chamada fornece informações suficientes à cada nó para que decidam independentemente se são master ou não. O serviço Foo em cada nó faz isto ao verificar se são o primeiro membro da visualização, se forem, serão o master, se não forem não serão master. Simples assim. "
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:132
@@ -534,5 +554,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 "Caso o A falhe ou feche, o Foo em C e D receberá uma chamada com uma nova visualização para o Foo {C, D}. O C se tornaria então o master. Se o A for reniciado, o A, C e D recebem a chamada com uma nova visualização do Foo {C,D,A}. O C ficaria como master, não existe nada mágico no A que o torne master novamente, só porque já foi master antes. "
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_EJBs.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_EJBs.po 2009-01-27 03:22:59 UTC (rev 83446)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_EJBs.po 2009-01-27 03:57:42 UTC (rev 83447)
@@ -9,7 +9,7 @@
"Project-Id-Version: Clustering_Guide_EJBs\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-01-22 14:45+1000\n"
+"PO-Revision-Date: 2009-01-27 13:32+1000\n"
"Last-Translator: Glaucia Cintra <gcintra at redhat.com>\n"
"Language-Team: Portuguese <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -119,7 +119,7 @@
#. Tag: para
#: Clustering_Guide_EJBs.xml:21
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"The <literal><clustered>True</clustered></literal> element is "
"really just an alias for the <literal><configuration-name>Clustered "
@@ -128,11 +128,11 @@
msgstr ""
"O elemento <literal><clustered>True</clustered></literal> é na "
"verdade, somente um outro nome para o elemento <literal><configuration-"
-"name>ClusteredStateless SessionBean</configuration-name></literal>."
+"name>ClusteredStateless SessionBean</configuration-name></literal> no arquivo conf/standard-jboss.xml."
#. Tag: para
#: Clustering_Guide_EJBs.xml:26
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"In the bean configuration, only the <clustered> element is mandatory. "
"It indicates that the bean needs to support clustering features. The <"
@@ -140,12 +140,11 @@
"attributes are indicated in the sample configuration above. Below is a "
"description of the attributes in the <cluster-config> element.."
msgstr ""
-"Na configuração do bean, somente o elemento <literal><clustered></"
-"literal> é obrigatório. Ele indica que o bean funciona em um cluster. O "
-"elemento <literal><cluster-config></literal> é alternativo e os "
+"Na configuração do bean, somente o elemento <clustered> é obrigatório. Ele indica que o bean funciona em um cluster. O "
+"elemento <cluster-config> é opcional e os "
"valores padrão de sua função estão indicados no exemplo de configuração "
-"acima. Abaixo segue uma descrição das funções do elemento <literal><"
-"cluster-config></literal>"
+"acima. Abaixo segue uma descrição das funções do elemento <"
+"cluster-config>."
#. Tag: para
#: Clustering_Guide_EJBs.xml:29
@@ -398,7 +397,7 @@
msgid ""
"The <literal>HASessionState</literal> service MBean is defined in the "
"<code>all/deploy/cluster-service.xml</code> file."
-msgstr ""
+msgstr "O serviço MBean do <literal>HASessionState</literal> está definido no arquivo <code>all/deploy/cluster-service.xml</code>."
#. Tag: programlisting
#: Clustering_Guide_EJBs.xml:90
@@ -452,15 +451,12 @@
#. Tag: para
#: Clustering_Guide_EJBs.xml:95
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"<emphasis role=\"bold\">ClusterPartition</emphasis> is a required attribute "
"to inject the HAPartition service that HA-JNDI uses for intra-cluster "
"communication."
-msgstr ""
-"<emphasis role=\"bold\">PartitionName</emphasis>é uma função alternativa "
-"para especificar o nome de um cluster. Seu valor padrão é "
-"<literal>DefaultPartition</literal>.."
+msgstr "<emphasis role=\"bold\">ClusterPartition</emphasis>é uma função requisitada para injetar o serviço HAPartition, que usa para a comunicação intra-cluster."
#. Tag: para
#: Clustering_Guide_EJBs.xml:100
@@ -503,13 +499,13 @@
#. Tag: title
#: Clustering_Guide_EJBs.xml:117
-#, fuzzy, no-c-format
+#, no-c-format
msgid "Handling Cluster Restart"
-msgstr "Manipular a Reinicialização do Cluster"
+msgstr "Manipulando a Reinicialização do Cluster"
#. Tag: para
#: Clustering_Guide_EJBs.xml:118
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"We have covered the HA smart client architecture in the section called "
"“Client-side interceptor architecture”. The default HA smart proxy client "
@@ -519,8 +515,7 @@
"from this. The proxy needs to look up a fresh set of targets out of JNDI/"
"HAJNDI when the nodes are restarted."
msgstr ""
-"Tratamos da arquitetura de cliente smart HA em <xref linkend=\"clustering-"
-"intro-arch-proxy\"/>. O cliente smart proxy do HA padrão, pode acontecer "
+"Tratamos da arquitetura de cliente smart HA na seção chamada “Client-side interceptor architecture”. O cliente smart proxy do HA padrão, pode acontecer "
"somente no caso de um nó em cluster existir. Se o Cluster se fechar "
"completamente, o proxy se tornará órfão e não perderá a informação sobre a "
"disponibilidade dos nós em cluster. Não existe uma maneira do proxy se "
@@ -529,7 +524,7 @@
#. Tag: para
#: Clustering_Guide_EJBs.xml:121
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"The 3.2.7+/4.0.2+ releases contain a RetryInterceptor that can be added to "
"the proxy client side interceptor stack to allow for a transparent recovery "
@@ -537,12 +532,10 @@
"binding that includes the RetryInterceptor. Below is an example jboss.xml "
"configuration."
msgstr ""
-"O 3.2.7+/4.0.2+ possui um <literal>RetryInterceptor</literal> que pode ser "
+"As versões 3.2.7+/4.0.2+ possuem um RetryInterceptor que pode ser "
"adicionado à pilha de interceptador do cliente proxy para considerar uma "
"recuperação transparente de uma falha de reinício. Para habilitá-lo para um "
-"EJB, instale um <literal>invoker-proxy-binding</literal> que inclui o "
-"<literal>RetryInterceptor</literal>. Segue abaixo um exemplo de configuração "
-"<literal>jboss.xml</literal>."
+"EJB, instale um invoker-proxy-binding, que inclui o RetryInterceptor. Segue abaixo um exemplo de configuração jboss.xml."
#. Tag: programlisting
#: Clustering_Guide_EJBs.xml:124
@@ -730,7 +723,7 @@
#: Clustering_Guide_EJBs.xml:152
#, no-c-format
msgid "SingleRetryInterceptor"
-msgstr ""
+msgstr "SingleRetryInterceptor"
#. Tag: para
#: Clustering_Guide_EJBs.xml:153
@@ -774,7 +767,7 @@
#. Tag: para
#: Clustering_Guide_EJBs.xml:170
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"To cluster a stateless session bean in EJB 3.0, all you need to do is to "
"annotate the bean class withe the <literal>@Clustered</literal> annotation. "
@@ -786,10 +779,10 @@
msgstr ""
"Para realizar o cluster de um bean de sessão sem estado em EJB 3.0, tudo que "
"você precisa fazer é anotar a classe do bean com as anotações "
-"<literal>@Cluster</literal>. Você poderá passar pela política de "
+"<literal>@Clustered</literal>. Você poderá passar pela política de "
"balanceamento de carga e partição do cluster como parâmetros para a "
"anotação. A política de balanceamento de carga padrão é <literal>org.jboss."
-"ha.framework.interfaces.RandomRobin</literal>. Segue abaixo a definição da "
+"ha.framework.interfaces.RandomRobin</literal> e o cluster padrão é <literal>DefaultPartition</literal>. Segue abaixo a definição da "
"anotação <literal>@Cluster</literal>."
#. Tag: programlisting
@@ -846,7 +839,7 @@
msgid ""
"The <literal>@Clustered</literal> annotation can also be omitted and the "
"clustering configuration applied in jboss.xml:"
-msgstr ""
+msgstr "A anotação do <literal>@Clustered</literal> pode também ser omitida e a configuração do cluster pode ser aplicada no jboss.xml:"
#. Tag: programlisting
#: Clustering_Guide_EJBs.xml:182
@@ -892,7 +885,7 @@
#. Tag: para
#: Clustering_Guide_EJBs.xml:188
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"To cluster stateful session beans in EJB 3.0, you need to tag the bean "
"implementation class with the <literal>@Cluster</literal> annotation, just "
@@ -904,7 +897,8 @@
"Para fazer um cluster de um bean de sessão sem estado em EJB 3.0, você "
"precisará marcar a classe de implementação do bean com a anotação "
"<literal>@Cluster</literal>, exatamente como fizemos anteriormente com o "
-"bean de sessão sem estado EJB 3.0. "
+"bean de sessão sem estado EJB 3.0. A anotação do @org.jboss."
+"ejb3.annotation.cache.tree.CacheConfig pode também ser aplicada ao bean para especificar o comportamento do cache. Abaixo segue a definição da anotação do @CacheConfig:"
#. Tag: programlisting
#: Clustering_Guide_EJBs.xml:193
@@ -936,7 +930,7 @@
msgid ""
"<literal>name</literal> specifies the object name of the JBoss Cache Mbean "
"that should be used for caching the bean (see below for more on this Mbean)."
-msgstr ""
+msgstr "<literal>name</literal> specifica o nome do objeto do JBoss Cache Mbean, que deve ser usado para fazer o cache no bean (veja abaixo para mais informações sobre este MBean)."
#. Tag: para
#: Clustering_Guide_EJBs.xml:198
@@ -945,7 +939,7 @@
"<literal>maxSize</literal> specifies the maximum number of beans that can "
"cached before the cache should start passivating beans, using an LRU "
"algorithm."
-msgstr ""
+msgstr "<literal>maxSize</literal> specifica o número máximo de beans que podem ser colocados em cache antes que o cache deva começar a passivar os beans, usando um algorítmo LRU."
#. Tag: para
#: Clustering_Guide_EJBs.xml:200
@@ -954,7 +948,7 @@
"<literal>idleTimeoutSeconds</literal> specifies the max period of time a "
"bean can go unused before the cache should passivate it (irregardless of "
"whether maxSize beans are cached.)"
-msgstr ""
+msgstr "<literal>idleTimeoutSeconds</literal> specifica a quantia máximas de vezes que um bean pode ficar sem ser usado antes que o cahce o passive (não importando se os maxSize beans estão em cache)."
#. Tag: para
#: Clustering_Guide_EJBs.xml:202
@@ -962,7 +956,7 @@
msgid ""
"<literal>removalTimeoutSeconds</literal> specifies the max period of time a "
"bean can go unused before the cache should remove it altogether."
-msgstr ""
+msgstr "<literal>removalTimeoutSeconds</literal> specifica a quantia máxima de vezes que um bean pode ficar sem ser usado antes que um cache o remova."
#. Tag: para
#: Clustering_Guide_EJBs.xml:204
@@ -978,13 +972,13 @@
#. Tag: para
#: Clustering_Guide_EJBs.xml:209
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"Here is an example of a clustered EJB 3.0 stateful session bean "
"implementation."
msgstr ""
"Veja aqui um exemplo da implementação de um bean de sessão sem estado de um "
-"EJB 3.0 em cluster. "
+"EJB 3.0 em cluster. "
#. Tag: programlisting
#: Clustering_Guide_EJBs.xml:216
@@ -1249,20 +1243,14 @@
#. Tag: para
#: Clustering_Guide_EJBs.xml:235
-#, fuzzy, no-c-format
+#, no-c-format
msgid ""
"The configuration attributes in this MBean are essentially the same as the "
"attributes in the standard JBoss Cache <literal>TreeCache</literal> MBean "
"discussed in <xref linkend=\"jbosscache.chapt\"/>. Again, we omitted the "
"JGroups configurations in the <literal>ClusterConfig</literal> attribute "
"(see more in <xref linkend=\"jbosscache-jgroups\"/>). Two noteworthy items:"
-msgstr ""
-"As funções da configuração em MBean <literal>PassivationTreeCache</literal> "
-"são literalmente iguais às funções no modelo MBean de JBoss Cache "
-"<literal>TreeCache</literal> discutidos em <xref linkend=\"jbosscache.chapt"
-"\"/>. Novamente, omitimos as configurações JGroups na função "
-"<literal>ClusterConfig</literal> (veja mais em <xref linkend=\"jbosscache-"
-"jgroups\"/>)."
+msgstr "As funções da configuração neste MBean são literalmente iguais às funções no modelo MBean de JBoss Cache <literal>TreeCache</literal> discutidos em <xref linkend=\"jbosscache.chapt\"/>. Novamente, omitimos as configurações JGroups na função <literal>ClusterConfig</literal> (veja mais em <xref linkend=\"jbosscache-jgroups\"/>). Dois itens importantes:"
#. Tag: para
#: Clustering_Guide_EJBs.xml:240
More information about the jboss-cvs-commits
mailing list