[jboss-cvs] JBossAS SVN: r83452 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR.

[jboss-cvs-commits at lists.jboss.org]

Author: gcintra
Date: 2009-01-27 00:42:31 -0500 (Tue, 27 Jan 2009)
New Revision: 83452

Modified:
   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_EJBs.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_EJBs.po	2009-01-27 05:27:39 UTC (rev 83451)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/pt-BR/Clustering_Guide_EJBs.po	2009-01-27 05:42:31 UTC (rev 83452)
@@ -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-27 13:32+1000\n"
+"PO-Revision-Date: 2009-01-27 15:40+1000\n"
 "Last-Translator: Glaucia Cintra <gcintra at redhat.com>\n"
 "Language-Team: Portuguese <en at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -679,7 +679,7 @@
 "configured properly to find your naming server. The RetryInterceptor will go "
 "through the following steps in attempting to determine the proper naming "
 "environment properties:"
-msgstr ""
+msgstr "Para recuperar o HA proxy, o RetryInterceptor faz uma busca em JNDI. Isto significa que ele cria internamente um novo InitialContext e faz uma busca no JNDI. Mas, para que esta busca seja bem sucedida, o InitialContext precisa ser configurado propriamente para encontrar seu servidor de nomeação. O RetryInterceptor passará pelos passos na tentativa de determinar propriedades de ambiente de nomeação adequados. "
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:133
@@ -690,7 +690,7 @@
 "to configuration has two downsides: first, it reduces portability by "
 "introducing JBoss-specific calls to the client code; and second, since a "
 "static field is used only a single configuration per JVM is possible."
-msgstr ""
+msgstr "Ele irá verificar seu próprio campo estático do retryEnv. Este campo pode ser configurado pelo código do cliente via uma chamada para o RetryInterceptor.setRetryEnv (Propriedades). Esta forma de configuração possui duas desvantagens: primeira, ele reduz a portabilidade ao introduzir as chamadas do JBoss-specific para o código do cliente e segunda, como é usado um campo estático, é possível somente uma única configuração por JVM."
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:138
@@ -706,6 +706,8 @@
 "naming properties are stored in a ThreadLocal and thus are only visible to "
 "the thread that originally created an InitialContext."
 msgstr ""
+"Se o campo retryEnv é nulo, ele irá procurar por qualquer propriedade de ambiente vinculada ao ThreadLcaol pela classe org.jboss.naming.NamingContextFactory. Para usar esta classe como sua fábrica de contexto de nomeação, em seu jndi.properties, configure a propriedade java.naming.factory.initial=org.jboss.naming.NamingContextFactory. A vantagem deste forma de uso do org.jboss."
+"naming.NamingContextFactory é simplesmente uma opção de configuração em seu arquivo de propriedades do jndi e porisso seu código de java não é afetado. A desvantagem é que as propriedades de nomeação são armazenadas em um ThreadLocal e porisso são visíveis somente para opções que criaram um InitialContext."
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:143
@@ -717,7 +719,7 @@
 "fall back on multicast discovery to find an HA-JNDI naming server. See the "
 "section on “ClusteredJNDI Services” for more on multicast discovery of HA-"
 "JNDI."
-msgstr ""
+msgstr "Se nenhuma das formas acima rendeu um conjunto de propriedades de ambiente de nomeação, utiliza-se um InitialContext. Se a tentativa de contatar um servidor de nomeação falhar, por padrão o InitialContext irá tentar retornar ao multicast discovery para encontrar um server de nomeação do HA-JNDI. Veja a seção em  “ClusteredJNDI Services” para obter mais informações sobre o multicast discovery do HA-JNDI."
 
 #. Tag: title
 #: Clustering_Guide_EJBs.xml:152
@@ -736,7 +738,7 @@
 "never return. For many client applications, this possibility is "
 "unacceptable. As a result, JBoss doesn't make the RetryInterceptor part of "
 "its default client interceptor stacks for clustered EJBs."
-msgstr ""
+msgstr "O RetryInterceptor é útil em muitos casos de uso, mas possui uma desvantagem, ele irá continuar tentando fazer a busca do HA proxy em JNDI até que encontre. Se por alguma razão ele não conseguir encontrar, este processo pode ser eterno, e portanto a chamada do EJB que disparou o RetryInterceptor nunca irá retornar. Para muitos aplicativos de cliente, esta possibilidade é inaceitável. Como resultado, o JBoss não faz do RetryInterceptor parte de sua pilha de interceptadores de cliente padrão para EJBs em cluster."
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:156
@@ -748,7 +750,7 @@
 "in JNDI. If this attempt fails, the EJB call will fail just as if no retry "
 "interceptor was used. Beginning with 4.0.4.CR2, the SingleRetryInterceptor "
 "is part of the default client interceptor stacks for clustered EJBs."
-msgstr ""
+msgstr "Na versão 4.0.4.RC1, foi introduzida uma nova variação do retry interceptor, o org.jboss.proxy.ejb.SingleRetryInterceptor. Esta versão funciona como o RetryInterceptor, mas faz somente uma única tentativa de busca no HA proxy em JNDI. Se esta tentativa falhar, a chamada do EJB irá falhar como se não houvesse usado nenhum retry interceptor. Iniciando com o 4.0.4.CR2, o SingleRetryInterceptor é parte da pilha de interceptador de cliente padrão para EJBs em cluster."
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:159
@@ -757,7 +759,7 @@
 "The downside of the SingleRetryInterceptor is that if the retry attempt is "
 "made during a portion of a cluster restart where no servers are available, "
 "the retry will fail and no further attempts will be made."
-msgstr ""
+msgstr "A desvantagem do SingleRetryInterceptor é que se a segunda tentativa é feita durante uma porção de uma reiniciação de cluster, onde não há nenhum servidor disponível, a tentativa irá falhar e não tentará mais."
 
 #. Tag: title
 #: Clustering_Guide_EJBs.xml:169
@@ -968,7 +970,7 @@
 "true, since replication involves serializing the bean, and preparing for and "
 "recovering from serialization is a common reason for implementing the "
 "callback methods."
-msgstr ""
+msgstr "<literal>replicationIsPassivation</literal> especifica se o cache deve considerar a replicação como equivalente à passivação e invoca qualquer retorno de chamada @PrePassivate e @PostActivate no bean. Por padrão, pois  a replicação envolve a serialização do bean, e a preparação e recuperação de uma serialização é uma razão comum para implementar os métodos de retorno de chamada."
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:209
@@ -1014,7 +1016,7 @@
 msgid ""
 "As with stateless beans, the @Clustered annotation can also be omitted and "
 "the clustering configuration applied in jboss.xml; see the example above."
-msgstr ""
+msgstr "Como o beans sem estado, a anotação do @Clustered também pode ser omitida e a configuração do cluster pode ser aplicada ao jboss.xml, veja o exemplo acima."
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:221
@@ -1026,7 +1028,7 @@
 "replicated. With EJB3, the mechanism is a little more formal; instead of "
 "just exposing a method with a known signature, an EJB3 SFSB must implement "
 "the org.jboss.ejb3.cache.Optimized interface:"
-msgstr ""
+msgstr "Como o EJB 2.0 em cluster SFSBs, o JBoss fornece um mecanismo onde uma implementação de um bean pode expor um método que o container possa invocar para verificar se um estado de bean é sujo após uma requisição e não precisa ser replicado. Com o EJB3, o mecanismo é um pouco mais formal. Ao invés de expor somente um método com uma assinatura conhecida, um EJB3 SFSB deve implementar a interface do org.jboss.ejb3.cache.Optimized:"
 
 #. Tag: programlisting
 #: Clustering_Guide_EJBs.xml:224
@@ -1260,7 +1262,7 @@
 "the JBoss Cache eviction mechanism to manage SFSB passivation. When beans "
 "are deployed, the EJB container will programatically add eviction regions to "
 "the cache, one region per bean type."
-msgstr ""
+msgstr "O cache é configurado para suportar remoção. O container do EJB3 SFSB usa o mecanismo de remoção do JBoss Cache para gerenciar a passivação do SFSB. Quano o beans é implementado, o container do EJB adicionará regiões de remoção programaticamente ao cache, uma região por tipo de bean. "
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:244
@@ -1277,5 +1279,5 @@
 "Each node in the cluster must have its own persistent store, otherwise as "
 "nodes independently passivate and activate clustered beans, they will "
 "corrupt each others data."
-msgstr ""
+msgstr "Um CacheLoader do JBoss Cache também é configurado, novamente para suportar a passivação do SFSB. Quando os beans são removidos do cache, o carregador de cache passiva-os à um armazenamento persistente, neste caso ao sistema de arquivo no $JBOSS_HOME/server/all/data/sfsb directory. JBoss Cache suporta uma variedade de implementações diferentes do CacheLoader que sabem como armazenar dados em tipos de armazenamentos persistentes diferentes. Veja a documentação do JBoss Cache para obter mais detalhes sobre isto. No entanto, se você mudar o CacheLoaderConfiguration, assegure-se que não está usando um armazenamento compartilhado (ex: um esquema único em um banco de dados compartilhado). Cada nó em cluster deve ter seu próprio armazenamento persistente, senão como os nós passivam e ativam os beans em cluster de forma independente, eles danificarão os dados uns dos outros."