[jboss-cvs] JBossAS SVN: r104036 - projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/es-ES.

Fri Apr 16 02:29:40 EDT 2010

Author: agarcia at jboss.com
Date: 2010-04-16 02:29:39 -0400 (Fri, 16 Apr 2010)
New Revision: 104036

Modified:
   projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/es-ES/resolved.po
Log:
in progress

Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/es-ES/resolved.po
===================================================================

--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/es-ES/resolved.po	2010-04-16 05:46:48 UTC (rev 104035)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/es-ES/resolved.po	2010-04-16 06:29:39 UTC (rev 104036)
@@ -10,7 +10,7 @@
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Last-Translator: Angela Garcia <agarcia at redhat.com>\n"
-"PO-Revision-Date: 2010-04-07 16:10+1000\n"
+"PO-Revision-Date: 2010-04-16 16:28+1000\n"
 "Project-Id-Version: resolved\n"
 "Language-Team:  <en at li.org>\n"
 "X-Generator: KBabel 1.11.4\n"
@@ -13649,7 +13649,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 "Con el fin de recuperar el proxy HA, el RetryInterceptor realiza una búsqueda en JNDI. Esto significa que internamente crea un nuevo InitialContext y realiza una búsqueda JNDI. Pero para que esa búsqueda tenga éxito es necesario configurar apropiadamente el InitialContext para que encuentre su servidor de nombres. El RetryInterceptor llevará a cabo los siguientes pasos al tratar de determinar las propiedades del entorno de nombrado apropiadas: "
 
 #. Tag: para
 #: resolved.xml:4296
@@ -13660,7 +13660,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 "Verificará su propio campo estático retryEnv. El código del cliente puede configurar este campo por medio de una llamada al RetryInterceptor.setRetryEnv(Properties). Este enfoque a la configuración tiene dos inconvenientes: primero reduce lo portátil introduciendo llamadas especificas de JBoss al código del cliente y segundo ya que se utiliza un campo estático entonces solo es posible una sola configuración por MVJ. "
 
 #. Tag: para
 #: resolved.xml:4301
@@ -13676,6 +13676,9 @@
 "naming properties are stored in a ThreadLocal and thus are only visible to "
 "the thread that originally created an InitialContext."
 msgstr ""
+"Si el campo retryEnv es nulo entonces verificará cualquier propiedad de entorno vinculada a ThreadLocal por medio de la clase org.jboss.naming.NamingContextFactory. Para utilizar esta clase como su fábrica de contexto de nombrado, configure la propiedad java.naming.factory.initial=org.jboss.naming."
+"NamingContextFactory en su jndi.properties. La ventaja de este enfoque es que el uso de org.jboss."
+"naming.NamingContextFactory es simplemente una opción de la configuración en su archivo jndi.properties y por lo tanto su código Java no se ve afectado. El inconveniente es que las propiedades de nombrado se almacenan en un ThreadLocal y por lo tanto solo son visibles para el hilo que originalmente creó un InitialContext."
 
 #. Tag: para
 #: resolved.xml:4306
@@ -13687,7 +13690,7 @@
 "fall back on multicast discovery to find an HA-JNDI naming server. See the "
 "section on &#x201C;ClusteredJNDI Services&#x201D; for more on multicast "
 "discovery of HA-JNDI."
-msgstr ""
+msgstr "Si ninguno de los enfoques anteriores produce un grupo de propiedades de entorno de nombrado entonces se utiliza un InitialContext predeterminado. Si no tiene éxito contactando a un servidor de nombres entonces por defecto el InitialContext tratará de retroceder al descubrimiento multicast para encontrar un servidor de nombrado HA-JNDI. Consulte la sección sobre &#x201C;Servicios ClusteredJNDI&#x201D; para obtener mayor información sobre el descubrimiento multicast de HA-JNDI."
 
 #. Tag: title
 #: resolved.xml:4315
@@ -13706,7 +13709,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 "El RetryInterceptor es útil en muchos casos pero una de sus desventajas es que seguirá tratando de encontrar el proxy HA en JNDI hasta que tenga éxito. Si por alguna razón no tiene éxito entonces este proceso puede continuar indefinidamente y por lo tanto la llamada EJB que disparó el RetryInterceptor nunca retornará. Para muchas aplicaciones de clientes esta posibilidad es inaceptable. Como consecuencia, JBoss no hace que el RetryInterceptor sea parte de las pilas del interceptor de cliente predeterminado para EJBs en clústers. "
 
 #. Tag: para
 #: resolved.xml:4319
@@ -13718,7 +13721,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 "En el lanzamiento 4.0.4.RC1 se introdujo un nuevo interceptor de reintento: org.jboss.proxy.ejb.SingleRetryInterceptor. Esta versión funciona como el RetryInterceptor, pero hace un solo intento para volver a buscar el proxy HA en JNDI. Si este intenti falla entonces la llamada EJB fallará tal como si no se hubiese utilizado un interceptor de reintento. Desde 4.0.4.CR2, el SingleRetryInterceptor es parte de las pilas de interceptor cliente predeterminado para los EJBs en clústers."
 
 #. Tag: para
 #: resolved.xml:4322
@@ -13727,7 +13730,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 "El inconveniente del SingleRetryInterceptor es que si el re-intento se realiza durante una parte del re-inicio de un clúster en donde no hay servidores disponibles entonces el re-intento fallará y no se volverá a tratar más. "
 
 #. Tag: title
 #: resolved.xml:4332
@@ -13747,6 +13750,9 @@
 "<literal>DefaultPartition</literal>. Below is the definition of the "
 "<literal>@Cluster</literal> annotation."
 msgstr ""
+"Para poner en clúster un bean de sesión sin estado en EJB 3.0, todo lo que tiene que hacer es anotar la clase bean con la anotación <literal>@Clustered</literal>. Puede pasar esto en la política de balanceo de carga y partición del clúster como parámetros de la anotación. La política de balanceo de carga es <literal>org.jboss.ha."
+"framework.interfaces.RandomRobin</literal> y el clúster predeterminado es "
+"<literal>DefaultPartition</literal>. A continuación encontrará la definición de la anotación <literal>@Cluster</literal>."
 
 #. Tag: programlisting
 #: resolved.xml:4339
@@ -13855,6 +13861,9 @@
 "bean to specify caching behavior. Below is the definition of the "
 "@CacheConfig annotation:"
 msgstr ""
+"Para poner en clúster los beans de sesión con estado en EJB 3.0 es necesario que le ponga una etiqueta a la clase de implementación del bean con la anotación <literal>@Cluster</literal>, así como lo hicimos anteriormente con el bean de sesión sin estado EJB 3.0. La anotación @org.jboss."
+"ejb3.annotation.cache.tree.CacheConfig también se puede aplicar al bean para especificar el comportamiento del cachér. A continuación puede ver la definición de la anotación "
+"@CacheConfig:"
 
 #. Tag: programlisting
 #: resolved.xml:4356
@@ -13924,7 +13933,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 si el caché debe considerar una replicación como equivalente a una pasivación e invocar cualquier callback @PrePassivate y @PostActivate en el bean. Por defecto es verdadero ya que la replicación implica el serializar el bean y prepararse y recuperarse de la serialización es una razón común para implementar los métodos callback."
 
 #. Tag: para
 #: resolved.xml:4372
@@ -13973,6 +13982,7 @@
 #. Tag: para
 #: resolved.xml:4384
 #, no-c-format
+#, fuzzy
 msgid ""
 "As with EJB 2.0 clustered SFSBs, JBoss provides a mechanism whereby a bean "
 "implementation can expose a method the container can invoke to check whether "
@@ -13981,6 +13991,12 @@
 "just exposing a method with a known signature, an EJB3 SFSB must implement "
 "the org.jboss.ejb3.cache.Optimized interface:"
 msgstr ""
+"Así como con SFSBs en clústers EJB 2.0, JBoss provides a mechanism whereby a bean "
+"implementation can expose a method the container can invoke to check whether "
+"the bean's state is not dirty after a request and doesn't need to be "
+"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:"
 
 #. Tag: programlisting
 #: resolved.xml:4387


