[jboss-cvs] JBossAS SVN: r71989 - projects/docs/trunk/AS_4/Server_Configuration_Guide/es-ES.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Apr 10 22:19:59 EDT 2008
Author: agarcia at jboss.com
Date: 2008-04-10 22:19:58 -0400 (Thu, 10 Apr 2008)
New Revision: 71989
Modified:
projects/docs/trunk/AS_4/Server_Configuration_Guide/es-ES/J2EE_EJBs_On_JBOSS.po
Log:
JBoss PR
Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/es-ES/J2EE_EJBs_On_JBOSS.po
===================================================================
--- projects/docs/trunk/AS_4/Server_Configuration_Guide/es-ES/J2EE_EJBs_On_JBOSS.po 2008-04-11 01:29:39 UTC (rev 71988)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/es-ES/J2EE_EJBs_On_JBOSS.po 2008-04-11 02:19:58 UTC (rev 71989)
@@ -8,7 +8,7 @@
"Project-Id-Version: J2EE_EJBs_On_JBOSS\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2007-12-03 01:14+0000\n"
-"PO-Revision-Date: 2008-04-10 15:04+1000\n"
+"PO-Revision-Date: 2008-04-11 12:18+1000\n"
"Last-Translator: Angela Garcia\n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -3751,7 +3751,7 @@
"<literal>TXInterceptor</literal> and <literal>SecurityInterceptor</literal> "
"respectively."
msgstr ""
-"Una de las principales ventajas de un patrón de interceptor es la flexibilidad en el arreglo de interceptores. Otra ventaja es la distinción funcional clara entre diferentes interceptores. Por ejemplom la lógica para transacción y seguridad está claramente separada entre el <literal>TXInterceptor</literal> y el <literal>SecurityInterceptor</literal> "
+"Una de las principales ventajas de un patrón de interceptor es la flexibilidad en el arreglo de interceptores. Otra ventaja es la distinción funcional clara entre diferentes interceptores. Por ejemplo la lógica para transacción y seguridad está claramente separada entre el <literal>TXInterceptor</literal> y el <literal>SecurityInterceptor</literal> "
"respectivamente."
#. Tag: para
@@ -4677,7 +4677,7 @@
"the entry point for the CMP2 persistence engine. The "
"<literal>EntityPersistanceStore</literal> interface is shown below."
msgstr ""
-"De acuerdo con la especificación EJB 2.1, JBoss soporta dos semánticas de persistencua de bean de entidades: persistencia administrada por el contenedor (CMP por las sigles del inglés container managed persistence) y persistencia administrada por beans (BMP por las siglas del inglés bean managed persistence). La implementación CMP utiliza una implementación de la interfaz <literal>org."
+"De acuerdo con la especificación EJB 2.1, JBoss soporta dos semánticas de persistencia de bean de entidades: persistencia administrada por el contenedor (CMP por las sigles del inglés container managed persistence) y persistencia administrada por beans (BMP por las siglas del inglés bean managed persistence). La implementación CMP utiliza una implementación de la interfaz <literal>org."
"jboss.ejb.EntityPersistanceStore</literal>. Por defecto es <literal>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</literal> el cual es el punto de entrada para la máquina de persistencia CMP2. La interfaz "
"<literal>EntityPersistanceStore</literal> se muestra a continuación. "
@@ -5378,7 +5378,7 @@
"with caching, data integrity is a problem, so some form of application "
"server level locking is needed for entity beans to provide the transaction "
"isolation properties that you are used to with traditional databases."
-msgstr "Los beans de entidades son una buena manera de proporcionar una interfaz orientada a objetos para datos relacionales. Más alla de esto también pueden mejorar el desempeño quitándole un peso a la base de datos por medio del uso de cachés y el retraso de actualizaciones sólo hasta que sea completamente necesario para de esta manera maximizar la eficiencia de la base de datos. Sin embargo, con el caché la integridad de los datos es un problema así que es necesario tener alguna forma de bloqueo a nivel del servidor de la aplicación para los beans de entidades para poder proporcionar propiedades de ailsmiento de transacciones a las que usted está acostumbrado con las bases de datos tradicionales. "
+msgstr "Los beans de entidades son una buena manera de proporcionar una interfaz orientada a objetos para datos relacionales. Más alla de esto también pueden mejorar el desempeño quitándole un peso a la base de datos por medio del uso de cachés y el retraso de actualizaciones sólo hasta que sea completamente necesario para de esta manera maximizar la eficiencia de la base de datos. Sin embargo, con el caché la integridad de los datos es un problema así que es necesario tener alguna forma de bloqueo a nivel del servidor de la aplicación para los beans de entidades para poder proporcionar propiedades de aislamiento de transacciones a las que usted está acostumbrado con las bases de datos tradicionales. "
#. Tag: title
#: J2EE_EJBs_On_JBOSS.xml:1183
@@ -5394,7 +5394,7 @@
"a given entity bean in memory at one time. This applies for every cache "
"configuration and every type of <literal>commit-option</literal>. The "
"lifecycle for this instance is different for every commit-option though."
-msgstr "Con la configuración predeterminada de JBoss sólo hay una instancia activa en la memoria a la vez de un bean de entidad dado. Esto aplica para todas las configuraciones de caché y todo tipo de <literal>commit-option</literal>. El ciclo de vida para esta instanciaes diferente para toda commit-option. "
+msgstr "Con la configuración predeterminada de JBoss sólo hay una instancia activa en la memoria a la vez de un bean de entidad dado. Esto aplica para todas las configuraciones de caché y todo tipo de <literal>commit-option</literal>. El ciclo de vida para esta instancia es diferente para toda commit-option. "
#. Tag: para
#: J2EE_EJBs_On_JBOSS.xml:1189
@@ -5496,7 +5496,7 @@
"if any method at all is invoked on an entity bean within a transaction, no "
"other transaction can have access to this bean until the holding transaction "
"commits or is rolled back."
-msgstr "<emphasis role=\"bold\">Transaction Lock</emphasis>: Una transacción lock asegura que sólo una transacción a la vez tenga acceso a un bean de entidad dado. Esto asegura las propiedades ACID de las transacciones a nivel del servidor de aplicaciones. Ya que por defecto sólo hay una instancia activa de cualquier bean de entidad dado a la vez, JBoss debe proteger esta instancia de lecturas y escrituras sucias. Así que por defecto el comportamiento de bloqueo del bean de entidad bloqueará cualquier bean de entidad dentro de una transacción hasta que se complete. Esto quiere decir que si cualquier método es invocado en un bean de entidad dentro de una transacción ninguna otra transacción puede tener acceso a este bean hasta que se guradan los cambios de la transacción o hasta que se revierta la transacción."
+msgstr "<emphasis role=\"bold\">Transaction Lock</emphasis>: Una transacción lock asegura que sólo una transacción a la vez tenga acceso a un bean de entidad dado. Esto asegura las propiedades ACID de las transacciones a nivel del servidor de aplicaciones. Ya que por defecto sólo hay una instancia activa de cualquier bean de entidad dado a la vez, JBoss debe proteger esta instancia de lecturas y escrituras sucias. Así que por defecto el comportamiento de bloqueo del bean de entidad bloqueará cualquier bean de entidad dentro de una transacción hasta que se complete. Esto quiere decir que si cualquier método es invocado en un bean de entidad dentro de una transacción ninguna otra transacción puede tener acceso a este bean hasta que se guardan los cambios de la transacción o hasta que se revierta la transacción."
#. Tag: title
#: J2EE_EJBs_On_JBOSS.xml:1237
@@ -5624,8 +5624,8 @@
"specification are taken care of here as well as the JBoss specific commit-"
"option <emphasis>D</emphasis>."
msgstr ""
-"<emphasis role=\"bold\">EntitySynchronizationInterceptor</emphasis>: El papel de este interceptor es sincronizar el estado del caché con el almacenamiento subyacente. Esto lo ligra con las semánticas <literal>ejbLoad</literal> y "
-"<literal>ejbStore</literal> de la especificación EJB. En la presencia de una transacción esto se dispara por la demarcación de una transacción. Registra un callback con el monitor de transacciones subyacente por meio de las interfaces JTA. Si no hay una transacción la política es almacenar estado al retornar de una invocación. Aquí también nos encargamos de las políticas de sincronización <emphasis>A</"
+"<emphasis role=\"bold\">EntitySynchronizationInterceptor</emphasis>: El papel de este interceptor es sincronizar el estado del caché con el almacenamiento subyacente. Esto lo logra con las semánticas <literal>ejbLoad</literal> y "
+"<literal>ejbStore</literal> de la especificación EJB. En la presencia de una transacción esto se dispara por la demarcación de una transacción. Registra un callback con el monitor de transacciones subyacente por medio de las interfaces JTA. Si no hay una transacción la política es almacenar estado al retornar de una invocación. Aquí también nos encargamos de las políticas de sincronización <emphasis>A</"
"emphasis>, <emphasis>B</emphasis> y <emphasis>C</emphasis> de la especificación así como de la opción commit-"
" <emphasis>D</emphasis> específica de JBoss."
@@ -5676,7 +5676,7 @@
"not careful about ordering the access to them. Various techniques and "
"advanced configurations can be used to avoid deadlocking problems. They are "
"discussed later in this section."
-msgstr "La política de bloqueo predeterminada de JBoss es bloquear un bean de entidad cuando una invocación tiene lugar en el contexto de una transacción hasta que la transacción se completa. Debido a esto es muy fácil encontrar puntos muertos si tiene transacciones largas que acceden a muchos beans de entidad o si no tiene cuidado al ordenar el accedo a estos. Se pueden utilizar varias ténicas y configuraciones avanzadas para evitar problemas con puntos muertos. Estos se discuten más adelnate en esta sección. "
+msgstr "La política de bloqueo predeterminada de JBoss es bloquear un bean de entidad cuando una invocación tiene lugar en el contexto de una transacción hasta que la transacción se completa. Debido a esto es muy fácil encontrar puntos muertos si tiene transacciones largas que acceden a muchos beans de entidad o si no tiene cuidado al ordenar el accedo a estos. Se pueden utilizar varias ténicas y configuraciones avanzadas para evitar problemas con puntos muertos. Estos se discuten más adelante en esta sección. "
#. Tag: title
#: J2EE_EJBs_On_JBOSS.xml:1281
@@ -5696,7 +5696,7 @@
"graph may look like is given in <xref linkend=\"Deadlock_Detection-"
"An_example_blocked_transaction_table\"/>."
msgstr ""
-"Afortunadamente, JBoss tiene la habilidad para detectar puntos muertos. JBoss tiene una gráfica interna global de las transacciones en espera y qué transacciones están bloqueando. Cuando un hilo determina que no puede adquirir un bloqueo de bean de entidad, este determina que transacción tiene actualmente el bloqueo en el bean y se añade a si mismo a la gráfica de transacciones bloqueada. Puede encontrar un ejemplo de la gráfica en <xref linkend=\"Deadlock_Detection-"
+"Afortunadamente, JBoss tiene la habilidad para detectar puntos muertos. JBoss tiene una gráfica interna global de las transacciones en espera y qué transacciones están bloqueando. Cuando un hilo determina que no puede adquirir un bloqueo de bean de entidad, este determina que transacción tiene actualmente el bloqueo en el bean y se añade a si mismo a la gráfica de transacciones bloqueada. Puede encontrar un ejemplo de la gráfica en la <xref linkend=\"Deadlock_Detection-"
"An_example_blocked_transaction_table\"/>."
#. Tag: title
@@ -5752,7 +5752,7 @@
"deadlock and will throw an <literal>ApplicationDeadlockException</literal>. "
"This exception will cause a transaction rollback which will cause all locks "
"that transaction holds to be released."
-msgstr "Antes de que el hilo bloquee de hecho, trata de detectar si hay algún problema con puntos muertos. Esto lo logra atravesando la gráfica de transacciones bloquedas. Al atravesar la gráfica mantiene a la vista las transacciones que están bloqueadas. Si ve un nodo bloqueado más de una vez en la gráfica entonces sabe que hay un punto muerto y emite una <literal>ApplicationDeadlockException</literal>. Esta excepción hace revertir una transacción lo que hace que todos los bloqueos en esa transacción se liberen. "
+msgstr "Antes de que el hilo bloquee de hecho, trata de detectar si hay algún problema con puntos muertos. Esto lo logra atravesando la gráfica de transacciones bloqueadas. Al atravesar la gráfica mantiene a la vista las transacciones que están bloqueadas. Si ve un nodo bloqueado más de una vez en la gráfica entonces sabe que hay un punto muerto y emite una <literal>ApplicationDeadlockException</literal>. Esta excepción hace revertir una transacción lo que hace que todos los bloqueos en esa transacción se liberen. "
#. Tag: title
#: J2EE_EJBs_On_JBOSS.xml:1332
@@ -5886,7 +5886,7 @@
"threads that were waiting to acquire the transaction lock."
msgstr ""
"<emphasis role=\"bold\">MaxContenders</emphasis>: El número "
-"máximo de hilos que estaban esperando adquiri el bloqueo de transacción."
+"máximo de hilos que estaban esperando adquirir el bloqueo de transacción."
#. Tag: para
#: J2EE_EJBs_On_JBOSS.xml:1370
@@ -5960,7 +5960,7 @@
"always accessed in the same exact order. In most cases, user applications "
"are just too complicated to use this approach and more advanced "
"configurations are needed."
-msgstr "El ordenar el acceso a sus beans de entidad puede ayudar a disminuir la probabilidad de encontrarse con puntos muertos. Esto significa que debe asegurarse de que los beans de entidad en su sistema siempre son accedidos en el mismo orden. En la mayoría de los casos, las aplicaciones de los uusarios son simplemente muy complicadas para utilizar este enfoque y se necesitan configuraciones más avanzadas."
+msgstr "El ordenar el acceso a sus beans de entidad puede ayudar a disminuir la probabilidad de encontrarse con puntos muertos. Esto significa que debe asegurarse de que los beans de entidad en su sistema siempre son accedidos en el mismo orden. En la mayoría de los casos, las aplicaciones de los usuarios son simplemente muy complicadas para utilizar este enfoque y se necesitan configuraciones más avanzadas."
#. Tag: title
#: J2EE_EJBs_On_JBOSS.xml:1409
@@ -5977,7 +5977,7 @@
"transactionally locked. Using commit-option <emphasis>D</emphasis> with this "
"option is sometimes very useful when your read-only bean's data is "
"sometimes updated by an external source."
-msgstr "Los beans de entidad se pueden marcar como de sólo lectura. Cuando un bean se marca como de sólo lectura ninca toman parte en una transacción. Esto significa que nunca es bloqueado a nivel transaccional. Al utilizar la opción commit <emphasis>D</emphasis> con esta opción a veces es muy útil cuando sus datos de bean de sólo lectura son actualizados por una fuente externa. "
+msgstr "Los beans de entidad se pueden marcar como de sólo lectura. Cuando un bean se marca como de sólo lectura nunca toman parte en una transacción. Esto significa que nunca es bloqueado a nivel transaccional. Al utilizar la opción commit <emphasis>D</emphasis> con esta opción a veces es muy útil cuando sus datos de bean de sólo lectura son actualizados por una fuente externa. "
#. Tag: para
#: J2EE_EJBs_On_JBOSS.xml:1413
@@ -6043,7 +6043,7 @@
"declaring all getter methods and the <literal>anotherReadOnlyMethod</"
"literal> as read-only."
msgstr ""
-"Después de leer y comprender el comportamiento predeterminado de bloqueo de los beans de entidad probablemente se estará preguntando \"Para que bloquear el bean si no está modificando los datos?\" JBoss le permite definir qué métodos en su bean de entidad son de sólo lectura para que no bloquee el bean dentro de la transacción si sólo se llamas estos tipos de métodos. Puede definir estos métodos de sólo lectura dentro de un descriptor de despliegue <literal>jboss.xml</literal>. Se permiten comodines para los nombres de métodos. El siguiente es un ejemplo de declarar todos los métodos getter y el <literal>anotherReadOnlyMethod</"
+"Después de leer y comprender el comportamiento predeterminado de bloqueo de los beans de entidad probablemente se estará preguntando \"Para que bloquear el bean si no está modificando los datos?\" JBoss le permite definir qué métodos en su bean de entidad son de sólo lectura para que no bloquee el bean dentro de la transacción si sólo se llaman estos tipos de métodos. Puede definir estos métodos de sólo lectura dentro de un descriptor de despliegue <literal>jboss.xml</literal>. Se permiten comodines para los nombres de métodos. El siguiente es un ejemplo de declarar todos los métodos getter y el <literal>anotherReadOnlyMethod</"
"literal> como de sólo lectura. "
#. Tag: title
@@ -6142,7 +6142,7 @@
"way to go. The JBoss developers are currently exploring ways to allow commit-"
"option <emphasis>A</emphasis> as well (which would allow the use of caching "
"for this option)."
-msgstr "Esta opción suena muy bien pero tiene algunos inconvenientes en este momento. Primero el comportamiento de aislamiento transaccional de esta opción es equivalente a <literal>READ_COMMITTED</literal>. Este puede crear lecturas repetibles cuando no se quiere. En otras palabras, una transacción podría tener una copian de un bean antiguo. Segundo, esta opción de configuración actualmente requiere la opción commit <emphasis>B</emphasis> o <emphasis>C</emphasis>, las cuales pueden ser una fuga de rendimiento ya que un ejbLoad debe tener lugar al comienzo de la transacción. Pero si su aplicación actualmente requiere la opción commit <emphasis>B</emphasis> o <emphasis>C</emphasis> de cualquier manera entonces esta es el camino adecuado. Los desarrolladores de JBoss actualemente se encuentran explorando las maneras de permitir la opción commit <emphasis>A</emphasis> también (lo cual permitiría el uso de caché para esta opción). "
+msgstr "Esta opción suena muy bien pero tiene algunos inconvenientes en este momento. Primero el comportamiento de aislamiento transaccional de esta opción es equivalente a <literal>READ_COMMITTED</literal>. Este puede crear lecturas repetibles cuando no se quiere. En otras palabras, una transacción podría tener una copia de un bean antiguo. Segundo, esta opción de configuración actualmente requiere la opción commit <emphasis>B</emphasis> o <emphasis>C</emphasis>, las cuales pueden ser una fuga de rendimiento ya que un ejbLoad debe tener lugar al comienzo de la transacción. Pero si su aplicación actualmente requiere la opción commit <emphasis>B</emphasis> o <emphasis>C</emphasis> de cualquier manera entonces esta es el camino adecuado. Los desarrolladores de JBoss actualemente se encuentran explorando las maneras de permitir la opción commit <emphasis>A</emphasis> también (lo cual permitiría el uso de caché para esta opción). "
#. Tag: para
#: J2EE_EJBs_On_JBOSS.xml:1439
@@ -6241,7 +6241,7 @@
"explicitly implement the select for update invocation within the BMP's "
"<literal>ejbLoad</literal> method."
msgstr ""
-"Actalmente no hay una utilidad para bloqueo distribuido para los beans de entidad dentro del clúster. Esta funcionalidad ha sido delegada a la base de datos y debe ser soportada por el desarrollador de la aplicación. Para los bean de entidad en clústers se sugiere utilizar la opción commit <emphasis>B</emphasis> o <emphasis>C</"
+"Actualmente no hay una utilidad para bloqueo distribuido para los beans de entidad dentro del clúster. Esta funcionalidad ha sido delegada a la base de datos y debe ser soportada por el desarrollador de la aplicación. Para los bean de entidad en clústers se sugiere utilizar la opción commit <emphasis>B</emphasis> o <emphasis>C</"
"emphasis> en combinación con un mecanismo de bloqueo de filas. Para CMP hay una opción de configuración de bloqueo de filas. Esta opción utilizará un <literal>select "
"for update</literal> SQL cuando el bean se carga desde la base de datos. Con las opciones commit <emphasis>B</emphasis> o <emphasis>C</emphasis>, esto implementa un bloqueo transaccional que se puede utilizar a través del clúster. Para BMP debe implementar de manera explícita la invocación select for update dentro del método <literal>ejbLoad</literal> del BMP. "
@@ -6298,7 +6298,7 @@
"Make absolutely sure that your custom/complex primary key classes serialize "
"correctly. One common mistake is assuming that member variable "
"initializations will be executed when a primary key is unmarshalled."
-msgstr "Asegúrese por completo de que las clases de clave primaria custom/complex serilizan correctamente. Un error común es asumir que las inicializaciones variables de miembros serán ejecutadas cuando de desorganice una clave primaria. "
+msgstr "Asegúrese por completo de que las clases de clave primaria custom/complex serializan correctamente. Un error común es asumir que las inicializaciones variables de miembros serán ejecutadas cuando de desorganice una clave primaria. "
#. Tag: title
#: J2EE_EJBs_On_JBOSS.xml:1486
@@ -6360,7 +6360,7 @@
"the programming model. We will, instead, look at the configuration of the "
"timer service in JBoss so that you can understand how to make timers work "
"best in your environment"
-msgstr "El servicio temporizador J2EE tiene en cuenta cualquier objeto EJB para registrar un callback del temporizador en una hora designada en el futuro. Los eventos del temporizador se pueden utilizar para auditoría, reportar u otras tareas de limpieza que necesitan tener lugar en un momento dado en el futuro. Los eventos del temporizador deben ser persistentes y debe ejecutarse incluso cuando el servidor falla. El doficicar los temporizadores EJB es una parte estándar de la especificación J2EE así que no vamos a explorar el modelo de programación. En su lugar vamos a ver la configuración del servicio temporizador en JBoss para que pueda comprender cónmo hacer funcionar mejor los temporizadores en su entorno. "
+msgstr "El servicio temporizador J2EE tiene en cuenta cualquier objeto EJB para registrar un callback del temporizador en una hora designada en el futuro. Los eventos del temporizador se pueden utilizar para auditoría, reportar u otras tareas de limpieza que necesitan tener lugar en un momento dado en el futuro. Los eventos del temporizador deben ser persistentes y debe ejecutarse incluso cuando el servidor falla. El docificar los temporizadores EJB es una parte estándar de la especificación J2EE así que no vamos a explorar el modelo de programación. En su lugar vamos a ver la configuración del servicio temporizador en JBoss para que pueda comprender cómo hacer funcionar mejor los temporizadores en su entorno. "
#. Tag: para
#: J2EE_EJBs_On_JBOSS.xml:1508
@@ -6370,7 +6370,7 @@
"<literal>ejb-deployer.xml</literal> file. The primary MBean is the "
"<literal>EJBTimerService</literal> MBean."
msgstr ""
-"El servicio temporizador EJB es configurble por varios MBean relacionados en el archivo <literal>ejb-deployer.xml</literal> file. El MBean primario es el MBean "
+"El servicio temporizador EJB es configurable por varios MBean relacionados en el archivo <literal>ejb-deployer.xml</literal>. El MBean primario es el MBean "
"<literal>EJBTimerService</literal>. "
#. Tag: programlisting
@@ -6419,7 +6419,7 @@
"implementation, <literal>FixedDelayRetryPolicy</literal>, which will be "
"described later."
msgstr ""
-"<emphasis role=\"bold\">RetryPolicy</emphasis>: Este es eñl nombre del MBean que implementa la política de reintentar. El MBean debe soportar el <literal>org."
+"<emphasis role=\"bold\">RetryPolicy</emphasis>: Este es el nombre del MBean que implementa la política retry. El MBean debe soportar el <literal>org."
"jboss.ejb.txtimer.RetryPolicy interface</literal>. JBoss proporciona una implementación, <literal>FixedDelayRetryPolicy</literal>, la cual describiremos más adelante."
#. Tag: para
@@ -6461,7 +6461,7 @@
"literal> interface. JBoss provides the <literal>org.jboss.ejb.txtimer."
"TimedObjectInvokerImpl</literal> implementation."
msgstr ""
-"<emphasis role=\"bold\">TimedObjectInvokerClassname</emphasis>: Este es el nombre de una clase que proporciona la estrategia de invocación de método del tenporizador. Esta clase debe implementar la interfaz <literal>org.jboss.ejb.txtimer.TimedObjectInvoker</"
+"<emphasis role=\"bold\">TimedObjectInvokerClassname</emphasis>: Este es el nombre de una clase que proporciona la estrategia de invocación de método del temporizador. Esta clase debe implementar la interfaz <literal>org.jboss.ejb.txtimer.TimedObjectInvoker</"
"literal>. JBoss proporciona la implementación <literal>org.jboss.ejb.txtimer."
"TimedObjectInvokerImpl</literal>."
@@ -6501,7 +6501,7 @@
msgid ""
"<emphasis role=\"bold\">Delay</emphasis>: This is the delay (ms) before "
"retrying a failed timer execution. The default delay is 100ms."
-msgstr "<emphasis role=\"bold\">Delay</emphasis>: Este es el retraso (ms) antes de reintentar una ejecución fallida del temporizador. El restraso por defecto es 100ms."
+msgstr "<emphasis role=\"bold\">Delay</emphasis>: Este es el retraso (ms) antes de reintentar una ejecución fallida del temporizador. El retraso por defecto es 100ms."
#. Tag: para
#: J2EE_EJBs_On_JBOSS.xml:1551
@@ -6532,7 +6532,7 @@
msgid ""
"Most applications that use timers will want timers to be persisted. For that "
"the <literal>DatabasePersitencePolicy</literal> MBean should be used."
-msgstr "La mayoría de la saplicaciones que utilizan temporizadores querrán que estos sean persistidos, para lograr esto se debe utilizar el MBean <literal>DatabasePersitencePolicy</literal>."
+msgstr "La mayoría de las aplicaciones que utilizan temporizadores querrán que estos sean persistidos, para lograr esto se debe utilizar el MBean <literal>DatabasePersitencePolicy</literal>."
#. Tag: programlisting
#: J2EE_EJBs_On_JBOSS.xml:1558
More information about the jboss-cvs-commits
mailing list