[jboss-cvs] JBossAS SVN: r86246 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Mar 24 02:20:30 EDT 2009
Author: croe at redhat.com
Date: 2009-03-24 02:20:30 -0400 (Tue, 24 Mar 2009)
New Revision: 86246
Modified:
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Entity_EJBs.po
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_HTTP.po
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Intro.po
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Introduction.po
Log:
Proof reading in progress up to Clustering Guide Intro not completely inclusive yet
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Entity_EJBs.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Entity_EJBs.po 2009-03-24 03:06:43 UTC (rev 86245)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Entity_EJBs.po 2009-03-24 06:20:30 UTC (rev 86246)
@@ -8,7 +8,7 @@
"Project-Id-Version: Clustering_Guide_Entity_EJBs\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-01-15 03:24+0000\n"
-"PO-Revision-Date: 2009-02-09 09:55+1000\n"
+"PO-Revision-Date: 2009-03-24 09:23+1000\n"
"Last-Translator: Corina Roe <croe at redhat.com>\n"
"Language-Team: French <i18 at redhat.com>\n"
"MIME-Version: 1.0\n"
@@ -20,7 +20,7 @@
#: Clustering_Guide_Entity_EJBs.xml:5
#, no-c-format
msgid "Clustered Entity EJBs"
-msgstr "<literal>persistence.xml</literal>Entités EJB clusterisées"
+msgstr "Entités EJB clusterisées"
#. Tag: para
#: Clustering_Guide_Entity_EJBs.xml:6
@@ -29,7 +29,7 @@
"In a JBoss AS cluster, the entity bean instance caches need to be kept in "
"sync across all nodes. If an entity bean provides remote services, the "
"service methods need to be load balanced as well."
-msgstr "Dans un groupement JBoss AS, les caches d'instances d'entités Bean ont besoin de demeurer synchronisés à travers tous les noeuds. Si une entité Bean procure des services distants, les méthodes de service auront besoin d'être équilibrées également."
+msgstr "Dans un groupement JBoss AS, les caches d'instances d'entités bean ont besoin de demeurer synchronisés à travers tous les noeuds. Si une entité bean procure des services distants, les méthodes de service auront besoin d'être équilibrées également."
#. Tag: para
#: Clustering_Guide_Entity_EJBs.xml:8
@@ -38,7 +38,7 @@
"To use a clustered entity bean, the application does not need to do anything "
"special, except for looking up EJB 2.x remote bean references from the "
"clustered HA-JNDI."
-msgstr "Pour utiliser une entité Bean Clusterisée, l'application n'a pas besoin de faire quoi que ce soit de spécial, excepté chercher des références Bean éloignées EJB 2.x dans HA-JNDI clusterisé."
+msgstr "Pour utiliser une entité bean clusterisée, l'application n'a pas besoin de faire quoi que ce soit de spécial, excepté de chercher des références bean éloignées EJB 2.x dans HA-JNDI clusterisé."
#. Tag: title
#: Clustering_Guide_Entity_EJBs.xml:10
@@ -57,7 +57,7 @@
"bean clustering unless you fit into the sepecial case situation of read-"
"only, or one read-write node with read-only nodes synched with the cache "
"invalidation services."
-msgstr "Tout d'abord, il est bon de noter que la clustérisation des entités Bean 2.x n'est pas une bonne chose à faire. Cela expose des éléments qui sont généralement trop sophistiqués pour être utilisés en tant qu'objets distants vers des objets distants clusterisés et qui introduisent des problèmes de synchronisation qui ne sont pas négligeables. NE PAS utiliser la clusterisation des entités Bean EJB 2.x, à moins que vous vous retrouviez dans la situation particulière de noeuds lecture-seule, ou lecture-écriture, avec des noeuds lecture-seule synchronisés dans les services de validation cache."
+msgstr "Tout d'abord, il est bon de noter que la clustérisation des entités bean 2.x n'est pas une bonne chose à faire. Cela expose des éléments qui sont généralement trop sophistiqués pour être utilisés en tant qu'objets distants vers des objets distants clusterisés et qui introduisent des problèmes de synchronisation non négligeables. NE PAS utiliser la clusterisation des entités Bean EJB 2.x, à moins que vous vous retrouviez dans la situation particulière de noeuds lecture-seule, ou lecture-écriture, avec des noeuds lecture-seule synchronisés dans les services de validation cache."
#. Tag: para
#: Clustering_Guide_Entity_EJBs.xml:13
@@ -132,7 +132,7 @@
"The EJB 2.x entity beans are clustered for load balanced remote invocations. "
"All the bean instances are synchronized to have the same contents on all "
"nodes."
-msgstr "Les entités Bean EJB 2.x sont clusterisées pour les invocations à distance équilibrées. Toutes les instances Bean sont synchronisées de façon à posséder le même contenu sur tous les noeuds."
+msgstr "Les entités Bean EJB 2.x sont clusterisées pour les invocations à distance équilibrées. Toutes les instances bean sont synchronisées de façon à posséder le même contenu sur tous les noeuds."
#. Tag: para
#: Clustering_Guide_Entity_EJBs.xml:19
@@ -153,7 +153,7 @@
"<ulink url=\"http://dima.dhs.org/misc/readOnlyUpdates.html\"></ulink>. JBoss "
"may incorporate this pattern into later versions.)"
msgstr ""
-"Cependant, les entités Bean EJB 2.x ne possèdent pas un mécanisme de verrouillage distribué ou un cache distribué. Elles peuvent uniquement être synchronisées en utilisant le verrouillage au niveau-rangée de la base de données (voir <literal><row-lock></literal> dans les spécifications CMP ) ou bien en paramétrant les niveaux d'isolation de transactions du pilote JDBC pour qu'il soit <literal>TRANSACTION_SERIALIZABLE</literal>. En effet, il n'y a pas de mécanisme de verrouillage distribué supporté ou d'entités Bean cache distribuées utilisant l'option Commit (validation) \"B\" par défaut (Voir <literal>standardjboss.xml</literal> et les configurations de conteneur <literal>standardjboss."
+"Cependant, les entités Bean EJB 2.x ne possèdent pas un mécanisme de verrouillage distribué ou un cache distribué. Elles peuvent uniquement être synchronisées en utilisant le verrouillage au niveau-rangée de la base de données (voir <literal><row-lock></literal> dans les spécifications CMP ) ou bien en paramétrant les niveaux d'isolation de transactions du pilote JDBC pour qu'il soit <literal>TRANSACTION_SERIALIZABLE</literal>. En effet, il n'y a pas de mécanisme de verrouillage distribué supporté ou d'entités bean cache distribuées utilisant l'option Commit (validation) \"B\" par défaut (Voir <literal>standardjboss.xml</literal> et les configurations de conteneur <literal>standardjboss."
"xml</literal>). Il n'est pas conseillé d'utiliser l'option Commit \"A\" à moins que l'entité Bean soit en lecture-seule. (Il y a des modèles qui vous permettent d'utiliser l'option Commit \"A\" pour les Beans lecture-surtout. Vous pouvez également jeter un oeil sur le modèle Seppuku <ulink url=\"http://dima.dhs.org/misc/readOnlyUpdates.html\"></ulink>. JBoss incorporera peut-être ce modèle dans des versions à venir)."
#. Tag: para
@@ -181,7 +181,7 @@
"They do not provide remote services. Hence, the entity bean clustering "
"service in EJB 3.0 primarily deals with distributed caching and replication, "
"instead of load balancing."
-msgstr "Dans EJB 3.0, les entités beans servent principalement en tant que modèles de données de persistance. Ils ne procurent pas de services à distance. Ainsi, le service de clustérisation de l'entité Bean d'EJB 3.0 s'occupe principalement de la reproduction et du cache distribué, à la place de l'équilibrage des charges."
+msgstr "Dans EJB 3.0, les entités beans servent principalement en tant que modèles de données de persistance. Ils ne procurent pas de services à distance. Ainsi, le service de clustérisation de l'entité Bean d'EJB 3.0 s'occupe principalement de la reproduction et du cache distribué, au lieu de l'équilibrage des charges."
#. Tag: title
#: Clustering_Guide_Entity_EJBs.xml:45
@@ -215,7 +215,7 @@
msgid ""
"If you update an entity bean instance and save the changes to the database "
"via the entity manager the entity will updated in the cache."
-msgstr "Si vous mettez à jour une instance d'entité Bean, et que vous sauvegardez les changements dans la base de donnée par le gestionnaire d'entités, l'entité sera mise à jour dans le cache."
+msgstr "Si vous mettez à jour une instance d'entité bean, et que vous sauvegardez les changements dans la base de données par le gestionnaire d'entités, l'entité sera mise à jour dans le cache."
#. Tag: para
#: Clustering_Guide_Entity_EJBs.xml:57
@@ -386,7 +386,7 @@
"values of 5000 maxNodes and 1000 idle seconds are invalid for your "
"application(s), you can change the cache-wide defaults. You can also add "
"separate eviction regions for each of your entities; more on this below."
-msgstr "JBoss vous permet d'indiquer les délais de non activité aux entités cache. Les entités qui ne sont pas visitées pendant un certain temps, sont rejetées du cache, afin de préserver la mémoire. La configuration ci-dessus définit une région de configuration par défaut qui indique qu'au plus le cache comprendra 5000 noeuds, et qu'ensuite, les noeuds seront expulsés de la mémoire, avec les noeuds les moins utilisés récemment en dernier. Aussi, si un noeud n'a pas été visité pendant les dernières 1000 secondes, il sera expulsé de la mémoire. En général, un noeud du cache représente un élément caché (entité, collection ou résultat de recherche), quoi qu'il existe quelques autres noeuds qui sont utilisés dans des desseins internes. Si la valeur ci-dessus de 5000 maxNodes et de 1000 secondes sans activité, sont invalides pour votre application, vous pourrez changer les valeurs par défaut dans l'ensemble du cache. Vous pourrez également ajoute!
r des régions d'éviction séparées pour chacune de vos entités; voir ce qui suit à ce sujet ci-dessous."
+msgstr "JBoss vous permet d'indiquer les timeouts aux entités cache. Les entités auxquelles on n'a pas accédé depuis un certain temps, sont rejetées du cache, afin de préserver la mémoire. La configuration ci-dessus définit une région de configuration par défaut qui indique, qu'au plus, le cache comprendra 5000 noeuds, et qu'ensuite, les noeuds seront expulsés de la mémoire, avec les noeuds les moins utilisés récemment en dernier. Aussi, si un noeud n'a pas été visité pendant les dernières 1000 secondes, il sera expulsé de la mémoire. En général, un noeud du cache représente un élément caché (entité, collection ou résultat de recherche), quoiqu'il existe quelques autres noeuds qui sont utilisés dans des desseins internes. Si la valeur ci-dessus de 5000 maxNodes et de 1000 secondes sans activité, sont invalides pour votre application, vous pourrez changer les valeurs par défaut dans l'ensemble du cache. Vous pourrez également ajouter des régi!
ons d'éviction séparées pour chacune de vos entités; voir ce qui suit à ce sujet."
#. Tag: para
#: Clustering_Guide_Entity_EJBs.xml:80
@@ -414,7 +414,7 @@
"configures the caching options for hibernate via its optional "
"<literal>property</literal> elements. The following element in "
"<literal>persistence.xml</literal> defines that caching should be enabled:"
-msgstr "Vous déterminez vos classes d'entités Bean normalement. Les prochaines versions de JBoss EJB 3.0, vont supporter les entités d'annotation et leurs collections de relations en tant que cache , mais, pour l'instant, vous devez configurer le moteur hibernate sous-jacent directement. Penchez-vous sur le fichier <literal>persistence.xml</literal>, qui configure les options cache d'hibernate via ses éléments de <literal>propriété </literal> optionnels. L'élément suivant de <literal>persistence.xml</literal> informe que cache doit être activé."
+msgstr "Vous déterminez vos classes d'entités Bean normalement. Les prochaines versions de JBoss EJB 3.0 vont supporter les entités d'annotation et leurs collections de relations en tant que cache , mais, pour l'instant, vous devez configurer le moteur hibernate sous-jacent directement. Penchez-vous sur le fichier <literal>persistence.xml</literal>, qui configure les options cache d'hibernate via ses éléments de <literal>propriété </literal> optionnels. L'élément suivant de <literal>persistence.xml</literal> informe que cache doit être activé."
#. Tag: programlisting
#: Clustering_Guide_Entity_EJBs.xml:90
@@ -436,7 +436,7 @@
msgid ""
"The following property element defines the object name of the cache to be "
"used, i.e., the name of the TreeCache MBean shown above."
-msgstr "L'élément de propriété suivante détermine le nom d'objet du cache à utiliser, c\"est à dire le nom du MBean TreeCache exposé ci-dessus."
+msgstr "L'élément de propriété suivant détermine le nom d'objet du cache à utiliser, c\"est à dire le nom du MBean TreeCache exposé ci-dessus."
#. Tag: programlisting
#: Clustering_Guide_Entity_EJBs.xml:92
@@ -462,9 +462,8 @@
"properly grouped to allow the cache to properly manage classloading. <"
"property name=\"hibernate.cache.region_prefix\" value=\"myprefix\"/>"
msgstr ""
-"Finalement, vous devriez donner un (préfixe régional) à cette configuration. Cela garantit que tous les éléments cache associés à cette persistence.xml soient correctement groupés ensemble dans JBoss Cache. Le cache jboss.cache:"
-"service=EJB3EntityTreeCache est une ressource partagée, utilisée potentiellement par des unités persistantes multiples. Les éléments cachés de ce cache partagé, ont besoin d'être correctement groupés pour permettre au cache de gérer correctement le chargement des classes. <"
-"property name=\"hibernate.cache.region_prefix\" value=\"myprefix\"/>"
+"Finalement, vous devriez donner un (préfixe régional) à cette configuration. Cela garantit que tous les éléments cache associés à cette persistence.xml sont correctement groupés ensemble dans JBoss Cache. Le cache jboss.cache:"
+"service=EJB3EntityTreeCache est une ressource partagée, utilisée potentiellement par des unités persistantes multiples. Les éléments cachés de ce cache partagé, ont besoin d'être correctement groupés pour permettre au cache de gérer correctement le chargement des classes. <property name=\"hibernate.cache.region_prefix\" value=\"myprefix\"/>"
#. Tag: para
#: Clustering_Guide_Entity_EJBs.xml:97
@@ -477,7 +476,7 @@
"prefix. This is not a particularly friendly region prefix if you need to use "
"it to set up specialized eviction regions (see below), so specifying your "
"own region prefix is recommended."
-msgstr "Si vous ne fournissez pas de préfixe régional, JBoss va automatiquement vous en fournir un, en le construisant à partir du nom d'EAR (s'il existe) et le nom du JAR qui inclut la persistence.xml. AInsi, une persistence.xml présente dans foo.ear, bar.jar aura foo_ear,bar_jar†comme préfixe régional. Ce n'est pas un préfixe de région particulièrement facile si vous avez besoin de l'utiliser pour installer les régions d\"éviction (voir ci-dessous). Nous vous conseillons donc de déterminer votre propre préfixe régional."
+msgstr "Si vous ne fournissez pas de préfixe régional, JBoss va automatiquement vous en fournir un, en le construisant à partir du nom d'EAR (s'il existe) et le nom du JAR qui inclut la persistence.xml. Ainsi, une persistence.xml présente dans foo.ear, bar.jar aura foo_ear,bar_jar†comme préfixe régional. Ce n'est pas un préfixe de région particulièrement facile si vous avez besoin de l'utiliser pour installer les régions d\"éviction (voir ci-dessous). Nous vous conseillons donc de déterminer votre propre préfixe régional."
#. Tag: para
#: Clustering_Guide_Entity_EJBs.xml:105
@@ -523,8 +522,8 @@
"literal> entity bean <literal>/myprefix/com/mycompany/entities/Account</"
"literal>."
msgstr ""
-"Une règle progmatique consiste à effectuer le caching sur les objets qui ne changent que rarement, et qui sont lus fréquemment. Vous pourrez rafiner le cache pour chaque entité Bean dans le fichier de configuration <literal>ejb3-entity-"
-"cache-service.xml</literal>. Par exemple, vous pourrez spécifier la taille du cache. S'il y a trop d'objets dans le cache, le cache pourrait évicter les objets les plus anciens ( ou les objets les moins utilisés, en fonction de la configuration) pour faire de la place aux nouveaux objets. En assumant que le region_prefix précisé dans <literal>persistence.xml</literal> est myprefix, le nom par défaut de la région cache de l'entité Bean <literal>com.mycompany.entities.Account</"
+"Une règle progmatique consiste à effectuer le caching sur les objets qui ne changent que rarement, et qui sont lus fréquemment. Vous pourrez rafiner le cache pour chaque entité bean dans le fichier de configuration <literal>ejb3-entity-"
+"cache-service.xml</literal>. Par exemple, vous pourrez spécifier la taille du cache. S'il y a trop d'objets dans le cache, le cache pourrait évicter les objets les plus anciens ( ou les objets les moins utilisés, en fonction de la configuration) pour faire de la place aux nouveaux objets. En assumant que le region_prefix précisé dans <literal>persistence.xml</literal> est myprefix, le nom par défaut de la région cache de l'entité bean <literal>com.mycompany.entities.Account</"
"literal> <literal>/myprefix/com/mycompany/entities/Account</"
"literal>."
@@ -600,7 +599,7 @@
"that lets you specify the cache region where an entity is to be stored, "
"rather than having it be automatically be created from the fully-qualified "
"class name of the entity class."
-msgstr "Si vous ne précisez pas une région cache pour une classe d'entité Bean, toutes les instances de cette classe seront cachées dans la région <literal>/_default</literal> comme déterminée ci-dessus. L'annotation @Cache expose une attribut optionnel \"region\" qui vous laisse spécifier la région cache dans laquelle on peut stocker une entité qui vous laissera spécifier la région cache dans laquelle l'entité pourra être stockée, plutôt que de l'avoir automatiquement créée à partir d'un nom de classe complet de la classe de l'entité."
+msgstr "Si vous ne précisez pas une région cache pour une classe d'entité bean, toutes les instances de cette classe seront cachées dans la région <literal>/_default</literal> comme déterminée ci-dessus. L'annotation @Cache expose un attribut optionnel \"region\" qui vous laisse spécifier la région cache dans laquelle on peut stocker une entité, plutôt que de l'avoir automatiquement créée à partir d'un nom de classe complet de la classe de l'entité."
#. Tag: programlisting
#: Clustering_Guide_Entity_EJBs.xml:115
@@ -695,7 +694,7 @@
"collections of scalar values) of specified queries. Here we show a simple "
"example of annotating a bean with a named query, also providing the "
"Hibernate-specific hints that tells Hibernate to cache the query."
-msgstr "L'API EJB3 Query vous donne également les moyens de sauvegarder les résultats cache de second-niveau (c'est à dire, les clés primaires d'entités Bean, ou les collections de valeurs scalaires) de demandes précises. Nous allons vous montrer ci-dessous un simple exemple d'annotation d'un Bean qui comporte une demande associéé à une dénomination précise, tout en fournissant les indications particulières à Hibernate, qui instruit Hibernate de cacher la recherche."
+msgstr "L'API EJB3 Query vous donne également les moyens de sauvegarder les résultats cache de second-niveau (c'est à dire, les clés primaires d'entités bean, ou les collections de valeurs scalaires) de demandes précises. Nous allons vous montrer ci-dessous un simple exemple d'annotation d'un bean qui comporte une demande associéé à une dénomination précise, tout en fournissant les indications particulières à Hibernate, qui instruit Hibernate de cacher la recherche."
#. Tag: para
#: Clustering_Guide_Entity_EJBs.xml:126
@@ -715,7 +714,7 @@
msgid ""
"Next, you create a named query associated with an entity, and tell Hibernate "
"you want to cache the results of that query:"
-msgstr "Ensuite, nous allez créer une demande nommément désignée associée à une entité, et instruire Hibernate du fait que vous souhaitez cacher les résultats de cette demande :"
+msgstr "Ensuite, nous allez créer une demande associant un nom à une entité, et instruire Hibernate du fait que vous souhaitez cacher les résultats de cette demande :"
#. Tag: programlisting
#: Clustering_Guide_Entity_EJBs.xml:133
@@ -767,7 +766,7 @@
"can set up separate eviction handling for your query results. So, if the "
"region prefix were set to myprefix in persistence.xml, you could, for "
"example, create this sort of eviction handling:"
-msgstr "Par défaut, Hibernate stocke les résultats de recherche dans JBoss Cache dans une région nommé {region_prefix}/org/hibernate/cache/StandardQueryCache. Sur cette base, vous pourrez installer un système de gestion des évictions séparé pour les résultats de vos recherches. Ainsi, si le préfixe régional est paramétré myprefix dans persistence.xml, vous pourriez, par exemple, créer ce système de gestion des évictions :"
+msgstr "Par défaut, Hibernate stocke les résultats de recherche dans JBoss Cache dans une région nommée {region_prefix}/org/hibernate/cache/StandardQueryCache. Sur cette base, vous pourrez installer un système de gestion des évictions séparé pour les résultats de vos recherches. Ainsi, si le préfixe régional est paramétré à myprefix dans persistence.xml, vous pourriez, par exemple, créer ce système de gestion des évictions :"
#. Tag: programlisting
#: Clustering_Guide_Entity_EJBs.xml:142
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_HTTP.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_HTTP.po 2009-03-24 03:06:43 UTC (rev 86245)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_HTTP.po 2009-03-24 06:20:30 UTC (rev 86246)
@@ -8,7 +8,7 @@
"Project-Id-Version: Clustering_Guide_HTTP\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-01-15 03:45+0000\n"
-"PO-Revision-Date: 2009-02-09 10:29+1000\n"
+"PO-Revision-Date: 2009-03-24 11:04+1000\n"
"Last-Translator: Corina Roe <croe at redhat.com>\n"
"Language-Team: French <i18 at redhat.com>\n"
"MIME-Version: 1.0\n"
@@ -30,7 +30,7 @@
"web clients on other nodes of a cluster. Thus, in the event one of your node "
"crashes, another node in the cluster will be able to recover. Two distinct "
"functions must be performed:"
-msgstr "La réplication de session HTTP est utilisée pour répliquer l'état associé à vos clients Web sur des autres noeuds du cluster. Ainsi, si un de vos noeuds se plante, un autre sera en mesure de se rétablir dans le cluster. On doit effectuer deux fonctions séparées :"
+msgstr "La réplication de session HTTP est utilisée pour répliquer l'état associé à vos clients Web sur des autres noeuds du cluster. Ainsi, si un de vos noeuds est défaillant, un autre sera en mesure de se rétablir dans le cluster. On doit effectuer deux fonctions séparées :"
#. Tag: para
#: Clustering_Guide_HTTP.xml:11
@@ -42,7 +42,7 @@
#: Clustering_Guide_HTTP.xml:14
#, no-c-format
msgid "Load-balancing of incoming invocations"
-msgstr "Equilibrage des charges des invocations"
+msgstr "Equilibrage des charges des invocations à venir"
#. Tag: para
#: Clustering_Guide_HTTP.xml:17
@@ -53,7 +53,7 @@
"by default. Just configure your web application as distributable in its "
"<filename>web.xml</filename> (see below), deploy it, and its session state "
"is automtically replicated across all JBoss instances in the cluster."
-msgstr "JBoss s'occupe directement de la réplication des états. Quand vous exécutez JBoss dans la configuration <literal>all</literal>, on active par défaut la réplication des états de session. Vous avez juste besoin de configurer votre application Web en tant que distribuable dans son <filename>web.xml</filename> (voir ci-dessous), de le déployer, et son état de session sera automatiquement reproduit à travers toutes les instances JBoss du cluster."
+msgstr "JBoss s'occupe directement de la réplication des états. Quand vous exécutez JBoss dans la configuration <literal>all</literal>, on active par défaut la réplication des états de session. Vous avez juste besoin de configurer votre application Web en tant que distribuable dans son <filename>web.xml</filename> (voir ci-dessous), déployer, et son état de session sera automatiquement reproduit à travers toutes les instances JBoss du cluster."
#. Tag: para
#: Clustering_Guide_HTTP.xml:19
@@ -91,7 +91,7 @@
"not to replicate HTTP sessions because all critical state is stored in a "
"database. In other situations, losing a client session is not acceptable "
"and, in this case, session state replication is the price one has to pay."
-msgstr "Un équilibreur de charges suit les demandes HTTP, et, suivant la session à laquelle la demande est liée, il dirige la demande vers le noeud qui convient. On appelle cela l'équilibrage des charges à sticky sessions (affinités de sessions): une fois qu'une session est créée sur un noeud, toute future demande sera traitée par ce même noeud. Si vous utilisez un équilibreur de charges qui supporte les sticky sessions, sans configurer votre application Web pour la réplication des sessions, vous permet un bon équilibrage, tout en évitant le coût d'une réplication d'états de session : chaque demande sera toujours traitée par le même noeud. Dans le cas où un noeud meurt, l'état de toutes les sessions client liées à ce noeud (comme les paniers d'achat par exemple) sera perdu et les clients auront probablement besoin de se connecter à un autre noeud. Dans de nombreuses situations, il est acceptable de ne pas reproduire les sessions HTTP, car tout état !
critique est stocké dans une base de données. Dans d'autres situations, il n'est pas acceptable de perdre une session client, et, dans ce cas, la réplication des états de session est le prix à payer."
+msgstr "Un équilibreur de charges suit les demandes HTTP, et, suivant la session à laquelle la demande est liée, il dirige la demande vers le noeud qui convient. On appelle cela l'équilibrage des charges à sticky sessions (affinités de sessions): une fois qu'une session est créée sur un noeud, toute future demande sera traitée par ce même noeud. Si vous utilisez un équilibreur de charges qui supporte les sticky sessions, sans configurer votre application Web pour la réplication des sessions, cela vous permettra un bon équilibrage, tout en évitant le coût d'une réplication d'états de session : chaque demande sera toujours traitée par le même noeud. Dans le cas où un noeud meurt, l'état de toutes les sessions client liées à ce noeud (comme les paniers d'achat par exemple) sera perdu et les clients auront probablement besoin de se connecter à un autre noeud. Dans de nombreuses situations, il est acceptable de ne pas reproduire les sessions HTTP, car tou!
t état critique est stocké dans une base de données. Dans d'autres situations, il n'est pas acceptable de perdre une session client, et, dans ce cas, la réplication des états de session est le prix à payer."
#. Tag: title
#: Clustering_Guide_HTTP.xml:26
@@ -127,7 +127,7 @@
"specific configuration. As several versions of Apache exist, we advise you "
"to use version 2.0.x. We will consider, for the next sections, that you have "
"installed Apache in the <literal>APACHE_HOME</literal> directory."
-msgstr "Tout d'abord, veillez bien à installer Apache. Vous pouvez décharger Apache directement à partir du site Apache à partir de <literal>http://httpd.apache.org/</literal>. C'est une installation simple qui ne requiert aucune configuration particulière. Comme il existe plusieurs versions d'Apache, nous vous conseillons d'utiliser la version 2.0.x. Dans les prochaines sections, nous assumerons que vous avez installé Apache dans le répertoire <literal>APACHE_HOME</literal>."
+msgstr "Tout d'abord, veillez bien à installer Apache. Vous pouvez décharger Apache directement à partir du site Apache <literal>http://httpd.apache.org/</literal>. C'est une installation simple qui ne requiert aucune configuration particulière. Comme il existe plusieurs versions d'Apache, nous vous conseillons d'utiliser la version 2.0.x. Dans les prochaines sections, nous assumerons que vous avez installé Apache dans le répertoire <literal>APACHE_HOME</literal>."
#. Tag: para
#: Clustering_Guide_HTTP.xml:39
@@ -140,7 +140,7 @@
"www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/</literal>. Rename "
"the downloaded file to <literal>mod_jk.so</literal> and copy it under "
"<literal>APACHE_HOME/modules/</literal>."
-msgstr "Ensuite, décharger les binaires mod_jk. Il existe déjà plusieurs versions de mod_jk également. Nous vous conseillons fortement d'utiliser mod_jk 1.2.x, car mod j_k et mod j_k2 sont obsolètes, ne sont pas pris en charge, et ne sont pas en cours de développement au niveau de la communauté. Le binaire mod_jk 1.2.x peut être déchargé à partir de <literal>http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/</literal>. Renommer le fichier déchargé <literal>mod_jk.so</literal> et le copier sous <literal>APACHE_HOME/modules/</literal>."
+msgstr "Ensuite, décharger les binaires mod_jk. Il existe déjà plusieurs versions de mod_jk également. Nous vous conseillons fortement d'utiliser mod_jk 1.2.x, car mod j_k et mod j_k2 sont obsolètes, ne sont pas pris en charge, et ne sont pas développés actuellement par la communauté. Le binaire mod_jk 1.2.x peut être déchargé à partir de <literal>http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/</literal>. Renommer le fichier déchargé <literal>mod_jk.so</literal> et le copier sous <literal>APACHE_HOME/modules/</literal>."
#. Tag: title
#: Clustering_Guide_HTTP.xml:47
@@ -297,7 +297,7 @@
"loadbalancer for Java applications. If you only use mod_jk as a "
"loadbalancer, you can also forward all URLs (i.e., <literal>/*</literal>) to "
"mod_jk."
-msgstr "La directive <literal>LoadModule</literal> indique à Apache vers quels URL, il doit envoyer le module mod_jk (puis, aux conteneurs Servlet, à leur tour). Dans le fichier ci-dessus, toutes les demandes qui comprennent le chemin d'accés <literal>/application/*</literal> sont envoyées vers l'équilibreur des charges mod_jk. Ainsi, vous pouvez configurer Apache aux contenus statiques du serveur (ou contenus PHP) directement, et cantonner l'utilisation de l'équilibreur des charges aux applications Java. Si vous n'utilisez mod_jk qu'en tant qu'équilibreur des charges, vous pourrez alors rediriger tous les URL (c'est à dire <literal>/*</literal>) vers mod_jk."
+msgstr "La directive <literal>LoadModule</literal> indique à Apache vers quels URL il doit envoyer le module mod_jk (puis, aux conteneurs Servlet). Dans le fichier ci-dessus, toutes les demandes qui comprennent le chemin d'accés <literal>/application/*</literal> sont envoyées vers l'équilibreur des charges mod_jk. Ainsi, vous pouvez configurer Apache avec les contenus statiques du serveur (ou contenus PHP) directement, et cantonner l'utilisation de l'équilibreur des charges aux applications Java. Si vous n'utilisez mod_jk qu'en tant qu'équilibreur des charges, vous pourrez alors rediriger tous les URL (c'est à dire <literal>/*</literal>) vers mod_jk."
#. Tag: para
#: Clustering_Guide_HTTP.xml:68
@@ -310,7 +310,7 @@
"the <literal>APACHE_HOME/conf</literal> directory. The format of the file is "
"<literal>/url=worker_name</literal>. To get things started, paste the "
"following example into the file you created:"
-msgstr "En plus de la directive <literal>JkMount</literal>, vous pouvez également utiliser la directive <literal>JkMountFile</literal> pour spécifier un fichier de configuration des points de montage qui contiet un Tomcat multiple, redirigeant les mappages URL. Vous aurez juste besoin de créer un fichier <literal>uriworkermap.properties</literal> au sein du répertoire <literal>APACHE_HOME/conf</literal>. Le format du fichier est <literal>/url=worker_name</literal>. Pour commencer, coller l'exemple suivant dans le fichier que vous avez créé :"
+msgstr "En plus de la directive <literal>JkMount</literal>, vous pouvez également utiliser la directive <literal>JkMountFile</literal> pour spécifier un fichier de configuration des points de montage, qui contient un Tomcat multiple, redirigeant les mappages URL. Vous aurez juste besoin de créer un fichier <literal>uriworkermap.properties</literal> au sein du répertoire <literal>APACHE_HOME/conf</literal>. Le format du fichier est <literal>/url=worker_name</literal>. Pour commencer, coller l'exemple suivant dans le fichier que vous avez créé :"
#. Tag: programlisting
#: Clustering_Guide_HTTP.xml:74
@@ -369,9 +369,7 @@
"The configuration file contains one section for each target servlet "
"container and one global section. For a two nodes setup, the file could look "
"like this:"
-msgstr ""
-"Ensuite, vous aurez besoin de configurer <literal>conf/workers."
-"properties</literal>du fichier de travail mod_jk. Ce fichier spécifie où les différents conteneurs de servlets sont situés et comment les appels doivent être équilibrés entre eux. Le fichier de configuration contient une section pour chaque conteneur de servlet cible et une section globale. Dans le cas d'une installation à deux noeuds, le fichier devrait ressembler à ce qui suit :"
+msgstr "Ensuite, vous aurez besoin de configurer <literal>conf/workers.properties</literal>du fichier de travail mod_jk. Ce fichier spécifie où les différents conteneurs de servlets sont situés et comment les appels doivent être équilibrés entre eux. Le fichier de configuration contient une section pour chaque conteneur de servlet cible et une section globale. Dans le cas d'une installation à deux noeuds, le fichier devrait ressembler à ce qui suit :"
#. Tag: programlisting
#: Clustering_Guide_HTTP.xml:87
@@ -442,7 +440,7 @@
"Basically, the above file configures mod_jk to perform weighted round-robin "
"load balancing with sticky sessions between two servlet containers (JBoss "
"Tomcat) node1 and node2 listening on port 8009."
-msgstr "SImplement, le fichier ci-dessus configure mod_jk pour qu'il puisse effectuer l'équilibrage des charges de manière Weighted Round-Robin (en tourniquet) par sticky sessions entre deux conteneurs de servlets (JBoss Tomcat) node1 et node branchés sur le port 8009."
+msgstr "Simplement, le fichier ci-dessus configure mod_jk pour qu'il puisse effectuer l'équilibrage des charges de manière Weighted Round-Robin (en tourniquet) par sticky sessions entre deux conteneurs de servlets (JBoss Tomcat) node1 et node branchés sur le port 8009."
#. Tag: para
#: Clustering_Guide_HTTP.xml:91
@@ -454,7 +452,7 @@
"Servlet containers. For each worker, you must specify the host name (or IP "
"address) and the port number of the AJP13 connector running in the Servlet "
"container."
-msgstr "Dans le fichier <literal>works.properties</literal>, chaque noeud est défini par l'utilisation de la convention de dénomination <literal>worker.XXX</literal> pour laquelle <literal>XXX</literal> représente un nom arbitraire que vous pouvez choisir pour chaque conteneur de servlet cible. Pour chaque worker, vous devrez spécifier le nom de l'hôte (ou l'adresse IP) et le numéro de port du connecteur AJP13, qui est exécuté dans le conteneur du servlet."
+msgstr "Dans le fichier <literal>works.properties</literal>, chaque noeud est défini par l'utilisation de la convention de dénomination <literal>worker.XXX</literal> pour laquelle <literal>XXX</literal> représente un nom arbitraire que vous pouvez choisir pour chaque conteneur de servlet cible. Pour chaque worker, vous devrez spécifier le nom de l'hôte (ou l'adresse IP) et le numéro de port du connecteur AJP13 qui est exécuté dans le conteneur du servlet."
#. Tag: para
#: Clustering_Guide_HTTP.xml:96
@@ -479,7 +477,7 @@
"of the Servlet container. Please review <literal>http://jakarta.apache.org/"
"tomcat/connectors-doc/config/workers.html</literal> for comments on "
"<literal>cachesize</literal> for Apache 1.3.x."
-msgstr "L'attribut <literal>cachesize</literal> détermine la taille des thread pools associées au conteneur du servlet (c'est à dire le nombre de demandes concurrentes qu'il enverra au conteneur du servlet). Veillez bien à ce que ce nombre de dépasse pas le nombre de threads qui sont configurés sur le connecteur AJP13 du conteneur de servlet. Consulter à nouveau <literal>http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html</literal> pour voir les commentaires <literal>cachesize</literal> applicables à Apache 1.3.x."
+msgstr "L'attribut <literal>cachesize</literal> détermine la taille des thread pools associées au conteneur du servlet (c'est à dire le nombre de demandes concurrentes qu'il enverra au conteneur du servlet). Veillez bien à ce que ce nombre de dépasse pas le nombre de threads qui sont configurés sur le connecteur AJP13 du conteneur de servlet. Veuillez consulter <literal>http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html</literal> pour voir les commentaires <literal>cachesize</literal> applicables à Apache 1.3.x."
#. Tag: para
#: Clustering_Guide_HTTP.xml:104
@@ -506,7 +504,7 @@
"the client is always using the same server he reached on his first request. "
"To enable session stickiness, you need to set <literal>worker.loadbalancer."
"sticky_session</literal> to 1."
-msgstr "La propriété <literal>sticky_session</literal> spécifie le comportement du cluster pour les sessions HTTP. Si vous spécifiez <literal>worker.loadbalancer.sticky_session=0</literal>, chaque demande sera équilibrée entre node1 et node2, c'est à dire, que différentes demandes iront vers différents serveurs pour une même session. Mais quand un utilisateur ouvre une session sur un serveur, il est toujours nécessaire de renvoyer les demandes de cet utilisateur vers le même serveur, tant que ce serveur reste disponible. C'est ce qu'on appelle une sitcky session, car le client utilise toujours le même serveur que celui qu'il a atteint pour sa première demande. Pour activer sticky session, vous aurez besoin de paramétrer <literal>worker.loadbalancer.sticky_session</literal> à 1."
+msgstr "La propriété <literal>sticky_session</literal> spécifie le comportement du cluster pour les sessions HTTP. Si vous spécifiez <literal>worker.loadbalancer.sticky_session=0</literal>, chaque demande sera équilibrée entre node1 et node2, c'est à dire, que différentes demandes iront vers différents serveurs pour une même session. Mais quand un utilisateur ouvre une session sur un serveur, il est toujours nécessaire de renvoyer les demandes de cet utilisateur vers le même serveur, tant que ce serveur reste disponible. C'est ce qu'on appelle une sitcky session, car le client utilise toujours le même serveur que celui qu'il a atteint lors de sa première demande. Pour activer sticky session, vous aurez besoin de paramétrer <literal>worker.loadbalancer.sticky_session</literal> à 1."
#. Tag: para
#: Clustering_Guide_HTTP.xml:113
@@ -644,7 +642,7 @@
"The preceding discussion has been focused on using mod_jk as a load "
"balancer. The content of the remainder our discussion of clustering HTTP "
"services in JBoss AS applies no matter what load balancer is used."
-msgstr "La discussion précédente était orientée sur l'utilisation de mod_jk en tant qu'équilibreur de charges. Le reste de notre discussion sur les services de clusterisation HTTP dans JBoss AS s'applique dans n'importe quel cas, quel que soit l'équilibreur de charges utilisé."
+msgstr "La discussion précédente était orientée sur l'utilisation de mod_jk en tant qu'équilibreur de charges. Le reste de notre discussion sur les services de clusterisation HTTP dans JBoss AS porte sur n'importe quel cas, quel que soit l'équilibreur de charges utilisé."
#. Tag: para
#: Clustering_Guide_HTTP.xml:153
@@ -679,7 +677,7 @@
"was <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. "
"Prior to AS 4.0.4 CR2, the file was named <literal>deploy/tc5-cluster-"
"service.xml</literal>."
-msgstr "Avant AS 4.2.0, la location du fichier de configuration cache de sessions HTTP était <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. Avant, AS 4.0.4 CR2, le fichier s'intitulait <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. "
+msgstr "Avant AS 4.2.0, l'emplacement du fichier de configuration cache de sessions HTTP était <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. Avant, AS 4.0.4 CR2, le fichier s'intitulait <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. "
#. Tag: para
#: Clustering_Guide_HTTP.xml:160
@@ -773,7 +771,7 @@
"(covered below) needs the added features of the <literal>TreeCacheAop</"
"literal> (a.k.a. <literal>PojoCache</literal>) class."
msgstr ""
-"Notez que la valeur de l'attribut de code d'élément mbean est org.jboss.cache.aop.TreeCacheAop, ce qui est différent des autres MBeans JBoss Cache utilisés dans JBoss AS. C'est parce que la réplication de sessions HTTP granularity FIELD (couvert ci-dessous) a besoin des fonctionnalités supplémentaires la la classe <literal>TreeCacheAop</"
+"Notez que la valeur de l'attribut de code d'élément mbean est org.jboss.cache.aop.TreeCacheAop, ce qui est différent des autres MBeans JBoss Cache utilisés dans JBoss AS. C'est parce que la réplication de sessions HTTP granularité FIELD (couvert ci-dessous) a besoin des fonctionnalités supplémentaires la classe <literal>TreeCacheAop</"
"literal> (ou <literal>PojoCache</literal>)."
#. Tag: para
@@ -795,7 +793,7 @@
"BatchModeTransactionManagerLookup</literal>. It tells the cache NOT to "
"participate in JTA-specific transactions. Instead, the cache manages its own "
"transactions. Please do not change this."
-msgstr "<emphasis role=\"bold\">TransactionManagerLookupClass</emphasis> installe l'usine de gestion de transaction. La valeur par défaut est <literal>org.jboss.cache.BatchModeTransactionManagerLookup</literal>. Le cache est instruit de NE PAS participer aux transactions qui ne sont pas spécifiques-JTA. Le cache gère ses propres transactions à la place. Ne rien y changer."
+msgstr "<emphasis role=\"bold\">TransactionManagerLookupClass</emphasis> installe l'usine de gestion de transactions. La valeur par défaut est <literal>org.jboss.cache.BatchModeTransactionManagerLookup</literal>. Le cache est instruit de NE PAS participer aux transactions qui ne sont pas spécifiques-JTA. Le cache gère ses propres transactions à la place. Ne rien y changer."
#. Tag: para
#: Clustering_Guide_HTTP.xml:178
@@ -813,7 +811,7 @@
"Using synchronous replication makes sure changes are applied aroundthe "
"cluster before the web request completes. However, synchronous replication "
"is much slower."
-msgstr "<emphasis role=\"bold\">CacheMode</emphasis> contrôle la manière dont le cache est reproduit. Les valeurs valides sont <literal>REPL_SYNC</literal> et <literal>REPL_ASYNC</literal>. Quel que soit le cas de figure, le thread de demande en provenance du client, met à jour le cache local des contenus de sessions courantes, puis envoie un message vers les caches des autres membres du cluster, en les instruisant de procéder au même changement. Avec REPL_ASYNC (par défaut) le thread de demande retourne dès que le message mis à jour a été posté sur le réseau. Avec REPL_SYNC, le thread de la demande se bloque jusqu'à ce qu'il reçoive un message réponse de la part de tous les membres du cluster, l'informant que la mise à jour a été appliquée avec succès. L'utilisation de la réplication synchronisée garantit que les changements sont appliqués tout autour du cluster avant que la demande Web ne se termine. Cependant, le réplication synchronisée est bien!
plus lente."
+msgstr "<emphasis role=\"bold\">CacheMode</emphasis> contrôle la manière dont le cache est reproduit. Les valeurs valides sont <literal>REPL_SYNC</literal> et <literal>REPL_ASYNC</literal>. Quel que soit le cas de figure, le thread de demande en provenance du client met à jour le cache local des contenus de sessions courantes, puis envoie un message vers les caches des autres membres du cluster, en les instruisant de procéder au même changement. Avec REPL_ASYNC (par défaut) le thread de demande retourne dès que le message mis à jour a été posté sur le réseau. Avec REPL_SYNC, le thread de la demande se bloque jusqu'à ce qu'il reçoive un message réponse de la part de tous les membres du cluster, l'informant que la mise à jour a été appliquée avec succès. L'utilisation de la réplication synchronisée garantit que les changements sont appliqués tout autour du cluster avant que la demande Web ne se termine. Cependant, le réplication synchronisée est bien !
plus lente."
#. Tag: para
#: Clustering_Guide_HTTP.xml:182
@@ -864,7 +862,7 @@
"of milliseconds to wait for a response from all nodes in the cluster when a "
"synchronous replication message is sent out. The default value is 20000; "
"should be a few seconds longer than LockAcquisitionTimeout."
-msgstr "<emphasis role=\"bold\">SyncReplTimeout</emphasis> détermine le nombre maximum de millesecondes qu'il faut attendre avant d'obtenir une réponse de la part de tous les noeuds du cluster quand on envoie un message de réplication synchronisé. La valeur par défaut est de 20 000; et devrait correspondre à quelques secondes supplémentaires par rapport à LockAcquisitionTimeout."
+msgstr "<emphasis role=\"bold\">SyncReplTimeout</emphasis> détermine le nombre maximum de millesecondes avant d'obtenir une réponse de la part de tous les noeuds du cluster suite à l'envoi d'un message de réplication synchronisé. La valeur par défaut est de 20 000; et devrait correspondre à quelques secondes supplémentaires par rapport à LockAcquisitionTimeout."
#. Tag: title
#: Clustering_Guide_HTTP.xml:207
@@ -953,7 +951,7 @@
"literal> and in need of replication). It has 4 options:"
msgstr ""
"L'élément <literal>replication-trigger</literal> détermine ce qui déclenche une réplication de sessions (c'est à dire quand une session est considérée comme <literal>dirty</"
-"literal> (souillée) et requiert une réplication). Il comprend 4 options :"
+"literal> (souillée) et requiert une réplication). IQuatre options sont possibles :"
#. Tag: para
#: Clustering_Guide_HTTP.xml:218
@@ -996,7 +994,7 @@
"object is mutable, so it assumes it is an marks the attribute as dirty. This "
"setting avoids the downside of SET while reducing the performance impact of "
"SET_AND_GET. It is the default setting."
-msgstr "<emphasis role=\"bold\">SET_AND_NON_PRIMITIVE_GET</emphasis>: cette police ressemble à la politique SET_AND_GET, sauf que les opérations GET qui retournent des valeurs d'attributs de types primitifs, ne marquent pas l'attribut en tant que souillés (dirty). Les types de systèmes Primitifs (String, Interger, Long, etc.) sont immutables, donc il n'y a pas de raison de marquer un attribut d'un type 'souillé' uniquement parce qu'il a été lu. Si une opération GET retourne une valeur de type non primitif, le gestionnaire de session ne possède pas de moyen facile de savoir si un objet est mutable, donc il assume qu'il l'est et marque l'attribut en tant que 'souillé'. Cette configuration permet d'éviter le mauvais coté de SET tout en réduisant l'impact de la performance de SET_AND_GET. C'est la configuration par défaut."
+msgstr "<emphasis role=\"bold\">SET_AND_NON_PRIMITIVE_GET</emphasis>: cette police ressemble à la politique SET_AND_GET, sauf que les opérations GET qui retournent des valeurs d'attributs de types primitifs, ne marquent pas l'attribut en tant que souillé (dirty). Les types de systèmes Primitifs (String, Interger, Long, etc.) sont immutables, donc il n'y a pas de raison de marquer un attribut 'souillé' uniquement parce qu'il a été lu. Si une opération GET retourne une valeur de type non primitif, le gestionnaire de session ne possèdera pas de moyen facile pour savoir si un objet est mutable, donc il assumera qu'il l'est et marquera l'attribut en tant que 'souillé'. Cette configuration permet d'éviter le mauvais coté de SET tout en réduisant l'impact de la performance de SET_AND_GET. C'est la configuration par défaut."
#. Tag: para
#: Clustering_Guide_HTTP.xml:227
@@ -1017,7 +1015,7 @@
"without being replicated, as a safeguard its timestamp will be replicated no "
"matter what. So, ACCESS is only useful in special circumstances where the "
"above safeguard is considered inadequate."
-msgstr "<emphasis role=\"bold\">ACCESS</emphasis>: cette option amène la session à être marquée comme 'souillée' à chaque fois qu'on y accède. Comme une session est accédée pour chaque demande HTTP, elle sera repliquée à chaque demande. Le but d'ACCESS est d'assurer que les références temporelles de dernier accès soient bien synchronisées à travers le cluster. Comme avec les autres options de déclenchement-de-réplication, la référence temporelle n'est peut-être pas mise à jour dans d'autres noeuds du cluster, car par manque de réplication, la session d'autres noeuds risque d'expirer avant le noeud actif, si la demande HTTP ne retire pas ou ne modifie pas d'attributs de session. Quand l'option est déterminée, les références temporelles qui s'appliquent à la session, seront synchronisées à travers les noeuds du cluster. Notez que l'utilisation de cette option peut avoir un impact de performance significatif, donc l'utiliser avec soin. Avec les au!
tres options de déclenchement de réplication, si une session a duré 80% de son interval d'expiration sans avoir été répliquée, sa référence temporelle sera répliquée de toute façon, par précaution. Donc, ACCESS est seulement utile en cas de circonstances spéciales, quand cette précaution est considérée inadéquate."
+msgstr "<emphasis role=\"bold\">ACCESS</emphasis>: cette option amène la session à être marquée comme 'souillée' à chaque fois qu'on y accède. Comme on doit accéder à une session pour chaque demande HTTP, elle sera repliquée à chaque fois. Le but d'ACCESS est d'assurer que les références temporelles de dernier accès soient bien synchronisées à travers le cluster. Comme avec les autres options de déclenchement-de-réplication, la référence temporelle n'est peut-être pas mise à jour dans d'autres noeuds du cluster, car par manque de réplication, la session d'autres noeuds risque d'expirer avant le noeud actif, si la demande HTTP ne retire pas ou ne modifie pas d'attributs de session. Quand l'option est déterminée, les références temporelles qui s'appliquent à la session, seront synchronisées à travers les noeuds du cluster. Notez que l'utilisation de cette option peut avoir un impact de performance significatif, donc l'utiliser avec soin. Avec les!
autres options de déclenchement de réplication, si une session a duré 80% de son interval d'expiration sans avoir été répliquée, sa référence temporelle sera répliquée de toute façon par mesure de précaution. Donc, ACCESS est seulement utile en cas de circonstances spéciales, quand cette précaution est considérée inadéquate."
#. Tag: para
#: Clustering_Guide_HTTP.xml:230
@@ -1043,7 +1041,7 @@
"attributes are separately deserialized on the remote nodes, each Person "
"object will now have a reference to its own Address object; the Address "
"object will no longer be shared."
-msgstr "<emphasis role=\"bold\">ATTRIBUTE</emphasis>: la réplication s'applique uniquement aux attributs 'souillés' de la session, et à des données de session, comme la référence temporelle de dernier accès. Pour les sessions qui comportent de grands volumes de données, cette option peut augmenter la performance de réplication. Cependant, les attributs seront sérialisés séparément, de façon à ce que s'il existe des références partagées entre les objets stockés dans les attributs, ces références partagées pourraient être interrompues sur les noeuds distants. Ainsi, prenons un objet Person, stocké sous la clé \"husband\" et qui a une référence vers l'objet Address, tandis qu'un autre objet Person, stocké sous la clé \"wife\" a une référence vers ce même objet Address. Quand les attributs \"husband\" et \"wife\" sont désérialisés séparément sur les noeuds distants, chaque objet Person possédera maintenant une référence à son propre obje!
t Address, et l'objet Address ne sera donc plus partagé."
+msgstr "<emphasis role=\"bold\">ATTRIBUTE</emphasis>: la réplication s'applique uniquement aux attributs 'souillés' de la session, et à des données de session, comme la référence temporelle de dernier accès. Pour les sessions qui comportent de grands volumes de données, cette option peut augmenter la performance de réplication. Cependant, les attributs seront sérialisés séparément, de façon à ce que s'il existe des références partagées entre les objets stockés dans les attributs, ces références partagées pourraient être interrompues sur les noeuds distants. Ainsi, prenons un objet Person, stocké sous la clé \"husband\" et qui a une référence vers l'objet Address, tandis qu'un autre objet Person, stocké sous la clé \"wife\" a une référence vers ce même objet Address : quand les attributs \"husband\" et \"wife\" sont désérialisés séparément sur les noeuds distants, chaque objet Person possédera maintenant une référence à son propre obj!
et Address, et l'objet Address ne sera donc plus partagé."
#. Tag: para
#: Clustering_Guide_HTTP.xml:238
@@ -1064,7 +1062,7 @@
"references will be preserved across the cluster. Potentially most "
"performant, but requires changes to your application (this will be discussed "
"later)."
-msgstr "<emphasis role=\"bold\">FIELD</emphasis>: la réplication est uniquement pour les champs de données modifiés par les individus, qui se trouvent à l'intérieur des objets d'attributs de session. Les références d'objets partagés seront préservés à travers le groupement. Potentiellement plus performants, mais nécessite des changements au niveau de votre application (dont on discutera plus tard)."
+msgstr "<emphasis role=\"bold\">FIELD</emphasis>: la réplication est uniquement pour les champs de données modifiés par les individus qui se trouvent à l'intérieur des objets d'attributs de session. Les références d'objets partagés seront préservés à travers le groupement. Potentiellement plus performante, mais nécessite des changements au niveau de votre application (dont on discutera plus tard)."
#. Tag: para
#: Clustering_Guide_HTTP.xml:246
@@ -1104,7 +1102,7 @@
"whole cluster. To use FIELD-level replication, you have to first prepare (i."
"e., bytecode enhance) your Java class to allow the session cache to detect "
"when fields in cached objects have been changed and need to be replicated."
-msgstr "La réplication niveau FIELD (champ) ne réplique que les champs de données modifiées, au sein des objets stockés dans la session. Son utilisation pourrait potentiellement réduire dramatiquement le volume de données qui circule entre les noeuds clusterisés, et améliorer ainsi la performance de tout le cluster. Pour utiliser la réplication niveau-FIELD, vous devrez tout d'abord préparer (c'est à dire souligner le code à octets) votre classe Java pour permettre au cache de la session de détecter quand les champs ont été modifiés ou ont besoin d'être répliqués dans les objets cachés."
+msgstr "La réplication niveau FIELD (champ) ne réplique que les champs de données modifiées, au sein des objets stockés dans la session. Son utilisation pourrait potentiellement réduire dramatiquement le volume de données qui circule entre les noeuds clusterisés, et améliorer ainsi la performance de tout le cluster. Pour utiliser la réplication niveau-FIELD, vous devrez tout d'abord préparer (c'est à dire souligner le code à octets) votre classe Java pour permettre au cache de la session de détecter les moments où les champs ont eu besoin d'être répliqués ou ont eu besoin d'être modifiés dans les objets cachés."
#. Tag: para
#: Clustering_Guide_HTTP.xml:262
@@ -1140,7 +1138,7 @@
"subclasses will be automatically annotated as well. Similarly, you can "
"annotate an interface with InstanceofAopMarker and all of its implementing "
"classes will be annotated. For example:"
-msgstr "Si vous annotez une classe par IntanceAopMarker à la place, alors, toutes ses sous-classes seront automatiquement annotées également. De même, si vous annotez une interface par InstanceofAopMarker et toutes ses classes d'implémentation seront annotées. Ainsi :"
+msgstr "Si vous annotez une classe par IntanceAopMarker à la place, alors, toutes ses sous-classes seront automatiquement annotées également. De même, vous pouvez annoter une interface par InstanceofAopMarker et toutes ses classes d'implémentation seront annotées. Ainsi :"
#. Tag: programlisting
#: Clustering_Guide_HTTP.xml:271
@@ -1181,7 +1179,7 @@
"literal>. Jboss AS 4.2 requires JDK 5 at runtime, but some users may still "
"need to build their projects using JDK 1.4. In this case, annotating classes "
"can be done via JDK 1.4 style annotations embedded in JavaDocs. For example:"
-msgstr "Il n'y a pas besoin d'annoter <literal>Student</literal>. Ce sera annoté automatiquement parce que c'est une sous-classe de <literal>Person</literal>. JBoss AS 4.2 a besoin de JDK 5 en cours d'exécution, mais certains utilisateurs auront peut-être toujours besoin de construire leur projet en utilisant JDK 1.4. Dans ce cas, on peut annoter les classes par les annotations de style JDK 1.4, qui sont intégrées dans JavaDocs. Ainsi :"
+msgstr "Il n'y a pas besoin d'annoter <literal>Student</literal>. Ce sera annoté automatiquement parce que c'est une sous-classe de <literal>Person</literal>. JBoss AS 4.2 a besoin de JDK 5 en cours d'exécution, mais certains utilisateurs auront peut-être toujours besoin de construire leur projet en utilisant JDK 1.4. Dans ce cas, on peut annoter les classes par les annotations de style JDK 1.4, qui sont intégrées dans JavaDocs. Par exemple :"
#. Tag: programlisting
#: Clustering_Guide_HTTP.xml:278
@@ -1310,9 +1308,7 @@
"In the application's <literal>jboss-web.xml</literal> file, the "
"<literal>replication-granularity</literal> attribute must be <literal>FIELD</"
"literal>."
-msgstr ""
-"Dans le fichier de l'application <literal>jboss-web.xml</literal>, l'attribut <literal>replication-granularity</literal>doit être <literal>FIELD</"
-"literal>."
+msgstr "Dans le fichier de l'application <literal>jboss-web.xml</literal>, l'attribut <literal>replication-granularity</literal>doit être <literal>FIELD</literal>."
#. Tag: para
#: Clustering_Guide_HTTP.xml:315
@@ -1322,7 +1318,7 @@
"data classes. Notice that there is no need to call <literal>session."
"setAttribute()</literal> after you make changes to the data object, and all "
"changes to the fields are automatically replicated across the cluster."
-msgstr "Finalement, voyons un exemple sur la façon d'utiliser la réplication niveau-FIELD sur ces classes de données. Notez qu'il n'y a pas besoin d'appeler <literal>session.setAttribute()</literal> après que vos ayez fait des changements à l'objet de données, et tous les changements appliqués au champs sont automatiquement répliqués à travers le cluster."
+msgstr "Finalement, voyons un exemple sur la façon d'utiliser la réplication niveau-FIELD sur ces classes de données. Notez qu'il n'y a pas besoin d'appeler <literal>session.setAttribute()</literal> après avoir effectué des changements à l'objet de données, et que tous les changements appliqués au champs sont automatiquement répliqués à travers le cluster."
#. Tag: programlisting
#: Clustering_Guide_HTTP.xml:318
@@ -1373,7 +1369,7 @@
"Besides plain objects, you can also use regular Java collections of those "
"objects as session attributes. JBoss cache automatically figures out how to "
"handle those collections and replicate field changes in their member objects."
-msgstr "A côté des simples objets, vous pouvez également utiliser les collections simples Java de ces objets en tant qu'attributs de session. JBoss cache résout automatiquement la façon dont s'occuper de ces collections, et réplique les changements de champs dans les objets de leur membre."
+msgstr "A côté des simples objets, vous pouvez également utiliser les collections simples Java de ces objets en tant qu'attributs de session. JBoss cache résout automatiquement la façon dont s'occuper de ces collections, et réplique les changements de champs dans les objets de leurs membres."
#. Tag: title
#: Clustering_Guide_HTTP.xml:324
@@ -1389,9 +1385,7 @@
"cache:service=TomcatClusteringCache</literal> MBean and invoke the "
"<literal>printDetails</literal> operation. You should see output resembling "
"the following."
-msgstr ""
-"Quand vous aurez déployé et rendu accès à votre application, dirigez-vous vers le MBean <ulink url=\"http://wiki."
-"jboss.org/wiki/Wiki.jsp?page=Http_session_field_level_example\"></ulink> et invoquez l'opération <literal>printDetails</literal>. Vous devriez avoir une sortie sur ce modèle :"
+msgstr "Quand vous aurez déployé votre application et que vous y aurez accédé, dirigez-vous vers le MBean <ulink url=\"http://wiki.jboss.org/wiki/Wiki.jsp?page=Http_session_field_level_example\"></ulink> et invoquez l'opération <literal>printDetails</literal>. Vous devriez avoir une sortie sur ce modèle :"
#. Tag: programlisting
#: Clustering_Guide_HTTP.xml:328
@@ -1523,7 +1517,7 @@
"classes referenced below are a part of this package."
msgstr ""
"Ce nouveau concept de police de notification est défini dans le package Java <package>org.jboss."
-"web.tomcat.service.session.notification</package>, et toutes les classes référencées ci-dessous font partie de ce package."
+"web.tomcat.service.session.notification</package>, et toutes les classes référencées ci-dessous font partie de ce paquetage."
#. Tag: para
#: Clustering_Guide_HTTP.xml:354
@@ -1539,8 +1533,8 @@
"situations in which no <classname>HttpSessionListener</classname> and "
"<classname>HttpSessionAttributeListener</classname> notifications are sent."
msgstr ""
-"Malgré qu'il soit possible d'implémenter <classname>ClusteredSessionNotificationPolicy</classname> pour la personnalisation de cas spécifiques, JBoss fournit <classname>LegacyClusteredSessionNotificationPolicy</classname>, qui implémente le comportement dans d'anciennes versions JBoss (par défaut), et <classname>IgnoreUndeployLegacyClusteredSessionNotificationPolicy</"
-"classname>, qui implémente le même comportement, sauf pour les situations de non déploiement, pour lesquelles aucune notification <classname>HttpSessionListener</classname>ou "
+"Malgré qu'il soit possible d'implémenter <classname>ClusteredSessionNotificationPolicy</classname> pour la personnalisation de cas spécifiques, JBoss fournit <classname>LegacyClusteredSessionNotificationPolicy</classname> qui implémente le comportement dans d'anciennes versions JBoss (par défaut), et <classname>IgnoreUndeployLegacyClusteredSessionNotificationPolicy</"
+"classname> qui implémente le même comportement, sauf pour les situations de non déploiement, pour lesquelles aucune notification <classname>HttpSessionListener</classname>ou "
"<classname>HttpSessionAttributeListener</classname> ne sont envoyées."
#. Tag: para
@@ -1604,5 +1598,5 @@
msgstr ""
"L'élément session-notification-policy montré ci-dessus, ne fait pas partie de la desciption officielle de JBoss 4.2+ jboss-web.xml (see <ulink url=\"http://www."
"jboss.org/j2ee/dtd/jboss-web_4_2.dtd\">http://www.jboss.org/j2ee/dtd/jboss-"
-"web_4_2.dtd</ulink>). Cependant, la logique analytique s'occupera correctement de l'élément dans JBoss AS 4.2.4 et plus tard à nouveau dans 4.2. 0.GA_CP05 et 4.3.0.GA_CP03 et suivants."
+"web_4_2.dtd</ulink>). Cependant, la logique analytique s'occupera correctement de l'élément dans JBoss AS 4.2.4 et plus tard à nouveau dans 4.2. 0.GA_CP05 et 4.3.0.GA_CP03 et versions suivantes."
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Intro.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Intro.po 2009-03-24 03:06:43 UTC (rev 86245)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Intro.po 2009-03-24 06:20:30 UTC (rev 86246)
@@ -8,7 +8,7 @@
"Project-Id-Version: Clustering_Guide_Intro\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-01-15 03:24+0000\n"
-"PO-Revision-Date: 2009-02-16 13:46+1000\n"
+"PO-Revision-Date: 2009-03-24 12:08+1000\n"
"Last-Translator: Corina Roe <croe at redhat.com>\n"
"Language-Team: French <i18 at redhat.com>\n"
"MIME-Version: 1.0\n"
@@ -26,7 +26,7 @@
#: Clustering_Guide_Intro.xml:6
#, no-c-format
msgid "High Availability Enterprise Services via JBoss Clusters"
-msgstr "High Availability Enterprise Services via Clusters JBoss"
+msgstr "Services Enterprise à haute disponibilité via JBoss Clusters"
#. Tag: title
#: Clustering_Guide_Intro.xml:9
@@ -47,7 +47,7 @@
"Clustering is crucial for highly available enterprise applications, as it is "
"the clustering infrastructure that supports the redundancy needed for high "
"availability."
-msgstr "Clustering nous permet d'exécuter une application sur plusieurs serveurs parallèles (comme des noeuds de groupement) tout en procurant un affichage unique aux clients d'applications. La charge est distribuée à travers les différents serveurs, et même si l'un ou plusieurs des serveurs est défaillant, l'application est toujours accessible via les noeuds du groupement qui restent. Clustering est crucial aux applications d'entreprises dimensionnables, car vous pouvez améliorer la performance en ajoutant simplement plusieurs noeuds dans le groupement. Clustering est crucial pour les applications d'entreprise hautement disponibles, car c'est l'infrastructure de mise en grappe qui supporte le redondance dont on a besoin pour une plus grande disponibilité."
+msgstr "Clustering nous permet d'exécuter une application sur plusieurs serveurs parallèles (comme des noeuds de groupements) tout en procurant un affichage unique aux clients d'applications. La charge est distribuée à travers les différents serveurs, et même si l'un ou plusieurs des serveurs est défaillant, l'application sera toujours accessible via les noeuds du groupement restant. Clustering est crucial aux applications d'entreprises dimensionnables, car vous pouvez améliorer la performance en ajoutant simplement plusieurs noeuds dans le groupement. Clustering est crucial pour les applications d'entreprise 'hautement disponibles', car c'est l'infrastructure de mise en grappe qui supporte la redondance dont on a besoin pour les cas de 'haute disponibilité'."
#. Tag: para
#: Clustering_Guide_Intro.xml:14
@@ -97,7 +97,7 @@
"and name that matches the other cluster members. In summary, a JBoss cluster "
"is a set of AS server instances each of which is running an identically "
"configured and named JGroups Channel."
-msgstr "Un cluster est un ensemble de noeuds qui communiquent les uns avec les autres dans un but commun. Dans un cluster JBoss Application Server (connu également sous le nom de 'partition'), un noeud est une instance de JBoss Application Server. La communication entre les noeuds est gérée par la bibliothèque de communication en groupes de JGroups, à travers un canal JGroups Channel, qui fournit la fonctionnalité de base, c'est à dire, identifier qui se trouve dans le cluster, et échanger des messages entre les membres du cluster de façon fiable. Les canaux JGroups qui ont la même configuration et le même nom, ont la possibilité de se découvrir les uns les autres et de former un groupe ensemble. C'est pourquoi, exécuter simplement \"run -c all\" sur deux instances AS du même réseau suffit pour former un cluster - chaque AS démarre un canal (en fait, plusieurs canaux) avec la même configuration par défaut, puis, ils se découvrent les uns les autres de fa!
çon dynamique et forment un cluster. On peut ajouter des noeuds de façon dynamique, ou bien les retirer des clusters à n'importe quel moment, tout simplement en débutant ou en arrêtant un canal par une configuration et un nom qui correspondent à ceux des autres membres du cluster. En bref, un cluster JBoss est un ensemble d'instances de serveur AS, qui sont exécutées sur un canal JGroups sous un nom et une configuration en commun."
+msgstr "Un cluster est un ensemble de noeuds qui communiquent les uns avec les autres dans un but commun. Dans un cluster JBoss Application Server (connu également sous le nom de 'partition'), un noeud est une instance de JBoss Application Server. La communication entre les noeuds est gérée par la bibliothèque de communication en groupes de JGroups, à travers un canal JGroups Channel, qui fournit la fonctionnalité de base, qui consiste à identifier qui se trouve dans le cluster, et échanger des messages entre les membres du cluster de façon fiable. Les canaux JGroups qui ont la même configuration et le même nom, ont la possibilité de se découvrir les uns les autres et de former un groupe ensemble. C'est pourquoi, exécuter simplement \"run -c all\" sur deux instances AS du même réseau suffit à former un cluster - chaque AS démarre un canal (en fait, plusieurs canaux) avec la même configuration par défaut, puis, ils se découvrent les uns les autres de faÃ!
§on dynamique et forment un cluster. On peut ajouter des noeuds de façon dynamique, ou bien les retirer des clusters à n'importe quel moment, tout simplement en débutant ou en arrêtant un canal par une configuration et un nom correspondant à ceux des autres membres du cluster. En bref, un cluster JBoss est un ensemble d'instances de serveur AS, qui sont exécutées sur un canal JGroups sous un nom et une configuration en commun."
#. Tag: para
#: Clustering_Guide_Intro.xml:29
@@ -110,7 +110,7 @@
"as HAPartition. In order to differentiate these channels, each must have a "
"unique name, and its configuration must match its peers yet differ from the "
"other channels."
-msgstr "Sur la même instance AS, divers services peuvent créer leur propre canal. Dans 4.2.x AS par défaut, quatre services différents créent des canaux - le service de réplication de sessions Web, le service de réplication EJB3 SFSB, le service de mise en cache d'entité EJB3, et un service de clustering d'intérêt général, connu sous le nom de HAPartition. Pour pouvoir différencier ces canaux, ils doivent tous posséder un nom unique, et leur configuration doit correspondre à celle de ses homologues, tout en se distinguant des autres canaux."
+msgstr "Sur la même instance AS, divers services peuvent créer leur propre canal. Dans 4.2.x AS par défaut, quatre services différents créent des canaux - le service de réplication de sessions Web, le service de réplication EJB3 SFSB, le service de mise en cache d'entité EJB3, et un service de clustering d'intérêt général, connu sous le nom de HAPartition. Pour pouvoir différencier ces canaux, ils doivent tous posséder un nom unique, et leur configuration doit correspondre à celle de leurs homologues, tout en se distinguant des autres canaux."
#. Tag: para
#: Clustering_Guide_Intro.xml:32
@@ -176,7 +176,7 @@
"rest of this guide, including smart client-side clustered proxies, EJB 2 "
"SFSB replication and entity cache management, farming, HA-JNDI and HA "
"singletons."
-msgstr "HAPartition est un service d'intérêt général utilisé pour un ensemble de tâches dans AS clustering. Il s'agit principalement d'une abstraction construite sur un canal JGroups qui fournit un support pour créer/recevoir des invocations RPC sur/à partir d'un ou de plusieurs membres du cluster. HAPartition prend également en charge un registre indiquant quels services de clustering qui sont exécutés sur les membres du groupement. HAPartition forme la base de nombreux services de clustering dont nous allons parler dans ce guide, y compris les proxys clusterisés côté-client, la réplication EJB 2 SFSB, la gestion de cache d'entités, farming, singletons HA et HA-JNDI."
+msgstr "HAPartition est un service d'intérêt général utilisé pour un ensemble de tâches dans AS clustering. Il s'agit principalement d'une abstraction construite sur un canal JGroups qui fournit un support pour créer/recevoir des invocations RPC sur/à partir d'un ou de plusieurs membres du cluster. HAPartition prend également en charge un registre indiquant quels services de clustering sont exécutés sur les membres du groupement. HAPartition forme la base de nombreux services de clustering dont nous allons parler dans ce guide, y compris les proxys clusterisés côté-client, la réplication EJB 2 SFSB, la gestion de cache d'entités, farming, singletons HA et HA-JNDI."
#. Tag: para
#: Clustering_Guide_Intro.xml:57
@@ -187,7 +187,7 @@
"simply start JBoss servers with their default clustering settings on a local "
"network, you would get a default cluster named <literal>DefaultPartition</"
"literal> that includes all server instances as its nodes."
-msgstr "L'exemple suivant montre la définition MBean <literal>HAPartition</literal> distribué dans JBoss AS standard. Donc, si vous démarrez simplement les serveurs JBoss avec leurs paramètres par défaut sur un réseau local, vous devriez obtenir un cluster par défaut nommé <literal>DefaultPartition</literal> qui inclut toutes les instances du serveur comme ses noeuds."
+msgstr "L'exemple suivant montre la définition du MBean <literal>HAPartition</literal> distribué dans JBoss AS standard. Donc, si vous démarrez simplement les serveurs JBoss avec leurs paramètres par défaut sur un réseau local, vous devriez obtenir un cluster par défaut nommé <literal>DefaultPartition</literal> qui inclut toutes les instances du serveur en tant que noeuds."
#. Tag: programlisting
#: Clustering_Guide_Intro.xml:61
@@ -252,9 +252,7 @@
"nodes, and its configuration is discussed in <xref linkend=\"jbosscache-"
"jgroups\"/>. The following list shows the available configuration attributes "
"in the <literal>HAPartition</literal> MBean."
-msgstr ""
-"Ici, nous avons omis la configuration de protocole JGroups détaillée pour ce canal. JGroups gère la communication sous-jacente d'un homologue à un autre, entre les noeuds, et sa configuration est discutée dans <xref linkend=\"jbosscache-"
-"jgroups\"/>. La liste suivante montre les attributs de configuration disponibles dans le MBean <literal>HAPartition</literal>."
+msgstr "Ici, nous avons omis la configuration de protocole JGroups détaillée pour ce canal. JGroups gère la communication sous-jacente d'un homologue à un autre, entre les noeuds, et sa configuration est discutée dans <xref linkend=\"jbosscache-jgroups\"/>. La liste suivante montre les attributs de configuration disponibles dans le MBean <literal>HAPartition</literal>."
#. Tag: para
#: Clustering_Guide_Intro.xml:67
@@ -281,7 +279,7 @@
"<emphasis role=\"bold\">DeadlockDetection</emphasis> is an optional boolean "
"attribute that tells JGroups to run message deadlock detection algorithms "
"with every request. Its default value is <literal>false</literal>."
-msgstr "<emphasis role=\"bold\">DeadlockDetection</emphasis> est un attribut booléen optionnel qui indique à JGroups d'exécuter les algorithmes de détection d'interblocage de messages pour chaque demande. Sa valeur par défaut est <literal>false</literal>."
+msgstr "<emphasis role=\"bold\">DeadlockDetection</emphasis> est un attribut booléen optionnel qui ordonne à JGroups d'exécuter les algorithmes de détection d'interblocage de messages pour chaque demande. Sa valeur par défaut est <literal>false</literal>."
#. Tag: para
#: Clustering_Guide_Intro.xml:79
@@ -292,7 +290,7 @@
"(in milliseconds). State replication refers to the process of obtaining "
"initial application state from other already-running cluster members at "
"service startup. Its default value is <literal>30000</literal>."
-msgstr "<emphasis role=\"bold\">StateTransferTimeout</emphasis> est un attribut optionnel qui spécifie le délai de réplication des états à travers le cluster (en millesecondes). La réplication d'états se réfère au processus d'obtention d'états initiaux de la part d'autres membres du cluster en cours d'exécution au moment du démarrage du service. Sa valeur par défaut est de <literal>30000</literal>."
+msgstr "<emphasis role=\"bold\">StateTransferTimeout</emphasis> est un attribut optionnel qui spécifie le délai de réplication des états à travers le cluster (en millesecondes). La réplication d'états se réfère au processus d'obtention d'états initiaux de la part d'autres membres du cluster en cours d'exécution au moment du démarrage du service. Sa valeur par défaut est de <literal>30 000</literal>."
#. Tag: para
#: Clustering_Guide_Intro.xml:82
@@ -328,7 +326,7 @@
"CurrentView field."
msgstr ""
"Vous pouvez visualiser les informations sur le cluster en cours en pointant votre navigateur vers la console JMX de n'importe quelle instance JBoss du cluster (c'est à dire, <literal>http://"
-"hostname:8080/jmx-console/</literal>), puis cliquer sur le MBean <literal>jboss:service=DefaultPartition</literal> (changer le nom du MBean pour refléter votre nom de partition si vous utilise le commutateur -g startup). Une liste des adresses IP pour les membres actuels du cluster apparaîtra dans le champ CurrentView."
+"hostname:8080/jmx-console/</literal>), puis cliquez sur le MBean <literal>jboss:service=DefaultPartition</literal> (changez le nom du MBean pour refléter votre nom de partition si vous utilisez le commutateur -g startup). Une liste des adresses IP pour les membres actuels du cluster apparaîtra dans le champ CurrentView."
#. Tag: title
#: Clustering_Guide_Intro.xml:93
@@ -405,7 +403,7 @@
"object figures out how to find the appropriate server node, marshal call "
"parameters, un-marshall call results, and return the result to the caller "
"client."
-msgstr "La plupart des services distants fournis par le serveur d'applications JBoss, comprenant JNDI, EJB, JMS, RMI et JBoss Remoting, requièrent que le client obtienne (comme apr ex. pour rechercher ou décharger) un objet stub (ou proxy). L'objet stub est généré par le serveur et il implémente l'interface commerciale du service. Le client fait alors des appels méthode locale vers l'objet stub. Le stub dirige automatiquement l'appel à travers le réseau vers où il est invoqué pour des objets de service gérés dans le serveur. Dans un environnement de clustering, l'objet stub généré par le serveur inclut un intercepteur qui sait diriger des appels vers des noeuds multiples à travers le cluster. L'objet stub détermine comment trouver le noeud de serveur qui convient, les paramètres d'appels ordonnancés, les résultats d'appels non-ordonnancés, et retourne le résultat au client."
+msgstr "La plupart des services distants fournis par le serveur d'applications JBoss, comprenant JNDI, EJB, JMS, RMI et JBoss Remoting, requièrent que le client obtienne (comme par ex. pour rechercher ou décharger) un objet stub (ou proxy). L'objet stub est généré par le serveur et il implémente l'interface commerciale du service. Le client fait alors des appels méthode locale vers l'objet stub. Le stub dirige automatiquement l'appel à travers le réseau vers où il est invoqué pour des objets de service gérés dans le serveur. Dans un environnement de clustering, l'objet stub généré par le serveur inclut un intercepteur qui sait diriger des appels vers des noeuds multiples à travers le cluster. L'objet stub détermine comment trouver le noeud de serveur qui convient, ordonnancer les paramètres d'appels, désordonnancer les résultats d'appels, et retourner le résultat au client."
#. Tag: para
#: Clustering_Guide_Intro.xml:119
@@ -424,7 +422,7 @@
"clustering architecture is illustrated in <xref linkend=\"clustering-"
"InterceptorArch.fig\"/>."
msgstr ""
-"Les intercepteurs stub maintiennent une connaissance mise à jour du groupement. Par exemple, ils connaissent les adresses IP de tous les noeuds de serveurs disponibles, l'algorithme de distribution des charges à travers les noeuds (voir la section suivante), et comment faire échouer une demande si le noeud cible n'est pas disponible. Dans le cadre de la gestion de chaque demande de service, quand la topologie du cluster change, le noeud du serveur met à jour l'intercepteur du stub à la lumière des derniers changements opérés dans le cluster. Ainsi, si un noeud sort du cluster, chacun des intercepteurs stub du client est mis à jour avec la nouvelle configuration la prochaine fois qu'il se connecte à un noeud actif au sein du cluster. Toutes les manipulations faites par le stub de service sont transparentes dans l'application du client. L'architecture de clustering de l'intercepteur côté-client, est illustrée dans <xref linkend=\"clustering-"
+"Les intercepteurs stub maintiennent une connaissance courante du groupement. Par exemple, ils connaissent les adresses IP de tous les noeuds de serveurs disponibles, l'algorithme de distribution des charges à travers les noeuds (voir la section suivante), et comment faire échouer une demande si le noeud cible n'est pas disponible. Dans le cadre de la gestion de chaque demande de service, quand la topologie du cluster change, le noeud du serveur met à jour l'intercepteur du stub à la lumière des derniers changements opérés dans le cluster. Ainsi, si un noeud sort du cluster, chacun des intercepteurs stub du client sera mis à jour avec la nouvelle configuration la prochaine fois qu'il se connectera à un noeud actif au sein du cluster. Toutes les manipulations faites par le stub de service sont transparentes dans l'application du client. L'architecture de clustering de l'intercepteur côté-client, est illustrée dans <xref linkend=\"clustering-"
"InterceptorArch.fig\"/>."
#. Tag: title
@@ -469,7 +467,7 @@
"architecture is illustrated in <xref linkend=\"clustering-BalancerArch.fig\"/"
">."
msgstr ""
-"Les autres services JBoss, les services basés-HTTP en particulier, n'exigent pas du client de télédécharger quoi que ce soit. Le client (par ex., un navigateur Web) émet des requêtes et reçoit des réponses par câble directement en fonction de certains protocoles de communication ( comme le protocole HTTP). Dans ce cas, l'équilibreur des charges doit traiter toutes les demandes et les renvoyer vers les noeuds du serveur dans le cluster. Le client a juste besoin de savoir comment entrer en contact avec l'équilibreur des charges. Il ne possède aucune connaissance des instances JBoss AS en dehors de l'équilibreur des charges. L'équilibreur des charges fait logiquement partie du cluster, mais on y fait référence en tant qu'\"externe\" car il n'est pas exécuté dans le même processus que les instances JBoss As ou du client. Il peut être implémenté soit au niveau programme, soit au niveau du matériel. Il existe de nombreux distributeurs de matériel d'équil!
ibrage de charges, comme le module mod_jk Apache qui constitue un excellent exemple. Un équilibreur de charges externe implémente ses propres mécanismes pour comprendre la configuration du cluster et fournit ses propres politiques associées aux cas de défaillance ou d'équilibrage des charges. L'architecture de mise en grappe d'équilibreur de charges externe est illustrée dans <xref linkend=\"clustering-BalancerArch.fig\"/"
+"Les autres services JBoss, les services basés-HTTP en particulier, n'obligent pas le client à télédécharger quoi que ce soit. Le client (par ex., un navigateur Web) émet des requêtes et reçoit des réponses par câble directement en fonction de certains protocoles de communication ( comme le protocole HTTP). Dans ce cas, l'équilibreur des charges doit traiter toutes les demandes et les renvoyer vers les noeuds du serveur dans le cluster. Le client a juste besoin de savoir comment entrer en contact avec l'équilibreur des charges. Il ne possède aucune connaissance des instances JBoss AS en dehors de l'équilibreur des charges. L'équilibreur des charges fait logiquement partie du cluster, mais on y fait référence en tant qu'\"externe\" car il n'est pas exécuté dans le même processus que les instances JBoss As ou du client. Il peut être implémenté soit au niveau programme, soit au niveau du matériel. Il existe de nombreux distributeurs de matériel d'équi!
librage de charges, comme le module mod_jk Apache qui constitue un excellent exemple. Un équilibreur de charges externe implémente ses propres mécanismes pour comprendre la configuration du cluster et fournit ses propres politiques associées aux cas de défaillance ou d'équilibrage des charges. L'architecture de mise en grappe d'équilibreur de charges externe est illustrée dans <xref linkend=\"clustering-BalancerArch.fig\"/"
">."
#. Tag: title
@@ -486,7 +484,7 @@
"load balancer itself may be a single point of failure. It needs to be "
"monitored closely to ensure high availability of the entire cluster's "
"services."
-msgstr "Un problème potentiel lié à une architecture d'équilibreur des charges externe, c'est que l'équilibreur des charges lui même pourrait constituer un point de défaillance. Cela doit être surveillé de près pour garantir un haut niveau de disponibilité des services du cluster dans leur ensemble."
+msgstr "Un problème potentiel lié à une architecture d'équilibreur des charges externe, c'est que l'équilibreur des charges lui même pourrait constituer un point de défaillance. Cela doit être surveillé de près sir on veut garantir un haut niveau de disponibilité des services du cluster en général."
#. Tag: title
#: Clustering_Guide_Intro.xml:154
@@ -512,7 +510,7 @@
"client-side interceptor architecture is used. The client-side stub maintains "
"a list of all nodes providing the target service; the job of the load "
"balance policy is to pick a node from this list for each request."
-msgstr "Dans JBoss 4.2.2, les options d'équilibrage des charges suivantes sont disponibles quand l'architecture de l'intercepteur côté-client est utilisée. Le stub côté-client maintient une liste de tous les noeuds qui fournissent le service cible. Le rôle de la politique d'équilibrage des charges est de choisir un noeud dans cette liste, suite à chaque demande."
+msgstr "Dans JBoss 4.2.2, les options d'équilibrage des charges suivantes sont disponibles quand l'architecture de l'intercepteur côté-client est utilisée. Le stub côté-client maintient une liste de tous les noeuds qui fournissent le service cible. Le rôle de la politique d'équilibrage des charges est de choisir un noeud dans cette liste pour chaque demande."
#. Tag: para
#: Clustering_Guide_Intro.xml:165
@@ -552,7 +550,7 @@
"is an example of a policy that provides “session affinity†or “sticky "
"sessionsâ€, since the target node does not change once established."
msgstr ""
-"Premier Disponible (<literal>org.jboss.ha.framework.interfaces.FirstAvailable</"
+"First Available (Premier disponible) (<literal>org.jboss.ha.framework.interfaces.FirstAvailable</"
"literal>): un des noeuds cible disponible est choisi comme cible principale et est ensuite utilisé pour chaque appel. Ce membre élu est choisi au hasard dans la liste des membres du groupement. Quand la liste des noeuds cible change (quand une noeud démarre ou meurt), la politique devra choisir un nouveau noeud cible, à moins que le noeud actuellement choisi soit toujours disponible. Chaque stub côté-client choisit son propre noeud cible indépendamment des autres stubs, donc, si un client particulier décharge deux stubs à partir d'un même service cible (par ex EJB), chaque stub choisira sa cible indépendamment. C'est un exemple de politique qui fournit “session affinity†ou “sticky "
"sessionsâ€, puisque le noeud cible ne change pas une fois qu'il a été établi."
@@ -566,9 +564,7 @@
"shared by all stubs in the same client-side VM that are associated with the "
"same target service. So if a particular client downloads two stubs for the "
"same target service (e.g. an EJB), each stub will use the same target."
-msgstr ""
-"First Available Identical All Proxies (<literal>org.jboss.ha.framework."
-"interfaces.FirstAvailableIdenticalAllProxies</literal>): possède le même comportement que la politique \"First Available\" (premier disponible) sauf que le noeud cible choisi est partagé par tous les stubs de la même MV côté-client qui est associée au même service cible. Donc, si un client donné décharge deux stubs d'un même service cible (par ex. EJB), chaque stub devra utiliser la même cible."
+msgstr "First Available Identical All Proxies (<literal>org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies</literal>): possède le même comportement que la politique \"First Available\" sauf que le noeud cible choisi est partagé par tous les stubs de la même MV côté-client associée au même service cible. Donc, si un client donné décharge deux stubs d'un même service cible (par ex. EJB), chaque stub devra utiliser la même cible."
#. Tag: para
#: Clustering_Guide_Intro.xml:189
@@ -624,7 +620,7 @@
"cluster server nodes farm folder (triggers undeployment.) You should "
"manually delete the application from the farm folder of any server node not "
"currently connected to the cluster."
-msgstr "La façon la plus simple de déployer une application dans le cluster est d'utiliser le service 'farming'. C'est pour déployer à chaud le fichier des archives de l'application (comme le fichier EAR, WAR ou SAR) dans le répertoire <code>all/farm/</code> de n'importe quel membre du cluster et l'application sera automatiquement dupliquée à travers les noeuds du même cluster. Si le noeud rejoint le cluster plus tard, toutes les applications 'farming' déployées seront attirées vers le cluster et elles seront déployées localement au démarrage. Si vous supprimez l'application d'un des dossiers <literal>farm/</literal> de noeud de serveur du groupement en cours d'exécution, le déploiement de l'application sera rétracté localement, puis supprimée de tous les autres dossiers 'farming' des noeuds de serveur du cluster (ce qui déclenche la rétraction du déploiement). Vous devrez effacer manuellement les applications du dossier 'farming' de tout noeud de serv!
eur qui n'est pas actuellement connecté au cluster."
+msgstr "La façon la plus simple de déployer une application dans le cluster est d'utiliser le service 'farming'. C'est pour déployer à chaud le fichier des archives de l'application (comme les fichiers EAR, WAR ou SAR) dans le répertoire <code>all/farm/</code> de n'importe quel membre du cluster et l'application sera automatiquement dupliquée à travers les noeuds du même cluster. Si le noeud rejoint le cluster plus tard, toutes les applications 'farming' déployées seront attirées vers le cluster et elles seront déployées localement au démarrage. Si vous supprimez l'application d'un des dossiers <literal>farm/</literal> de noeud de serveur du groupement en cours d'exécution, le déploiement de l'application sera rétracté localement, puis supprimé de tous les autres dossiers 'farming' des noeuds de serveur du cluster (ce qui déclenche la rétraction du déploiement). Vous devrez effacer manuellement les applications du dossier 'farming' de tout noeud de ser!
veur qui n'est pas actuellement connecté au cluster."
#. Tag: para
#: Clustering_Guide_Intro.xml:216
@@ -639,7 +635,7 @@
"the application really represents a new deployment or represents an old "
"deployment that was removed from the rest of the cluster while the newly "
"starting node was off-line. We are working to resolve this issue."
-msgstr "Actuellement, en raison d'un problème d'implémentation, le service de déploiement de 'farming' est limité. Il fonctionne uniquement pour 1) les archives situées dans le répertoire farm/ du premier noeud à rejoindre le cluster ou 2) pour les archives déployées à chaud. Si vous commencez par mettre une application dans le répertoire /farm, et que vous démarrez le serveur pour qu'il rejoigne un cluster en cours d'exécution, l'application ne sera pas poussée à travers le groupement ou déployée. C'est parce que le service 'farming' ne sait pas si l'application représente un nouveau déploiement réel ou si elle représente un ancien déploiement qui a été retiré du reste du cluster tandis que le noeud qui commençait à démarrer était hors-ligne. Nous essayons actuellement de résoudre ce problème."
+msgstr "Actuellement, en raison d'un problème d'implémentation, le service de déploiement de 'farming' est limité. Il fonctionne uniquement pour 1) les archives situées dans le répertoire farm/ du premier noeud à rejoindre le cluster ou 2) pour les archives déployées à chaud. Si vous commencez par mettre une application dans le répertoire /farm, et que vous démarrez le serveur pour qu'il rejoigne un cluster en cours d'exécution, l'application ne sera pas poussée vers le groupement ou déployée. C'est parce que le service 'farming' ne sait pas si l'application représente un nouveau déploiement réel ou si elle représente un ancien déploiement qui a été retiré du reste du cluster tandis que le noeud qui commençait à démarrer était hors-ligne. Nous essayons actuellement de résoudre ce problème."
#. Tag: para
#: Clustering_Guide_Intro.xml:219
@@ -663,7 +659,7 @@
"quite likely, for example, that a redeployment will happen on all nodes in "
"the cluster simultaneously, briefly leaving no nodes in the cluster "
"providing service."
-msgstr "Le déploiement 'farming' n'est pas atomique. Un problème de déploiement, de rétraction de déploiement ou redéploiement d'une application sur un noeud du cluster n'empêchera par que le déploiement , rétraction de déploiement ou redéploiement, soit effectué sur les autres noeuds. Il n'existe pas de possibilité de rollback. Aussi, le déploiement n'est pas effectué par étapes, et il est très possible, par exemple, qu'un déploiement ait lieu sur tous les noeuds d'un cluster simultanément, causant ainsi une interruption de services des noeuds du cluster."
+msgstr "Le déploiement 'farming' n'est pas atomique. Un problème de déploiement, de rétraction de déploiement ou redéploiement d'une application sur un noeud du cluster n'empêchera par que le déploiement , rétraction de déploiement ou redéploiement, soit effectué sur les autres noeuds. Il n'existe pas de possibilité de rollback. Aussi, le déploiement n'est pas effectué par étapes, et il est probable, par exemple, qu'un déploiement ait lieu sur tous les noeuds d'un cluster simultanément, causant ainsi une interruption de services des noeuds du cluster."
#. Tag: para
#: Clustering_Guide_Intro.xml:226
@@ -687,7 +683,7 @@
msgid ""
"After deploying farm-service.xml you are ready to rumble. The required "
"FarmMemberService MBean attributes for configuring a farm are listed below."
-msgstr "Après avoir déployé farm-service.xml, vous passez en vitesse de croisière. Les attributs MBean FarmMemberService requis pour configurer un 'farm' sont listés ci-dessous."
+msgstr "Après avoir déployé farm-service.xml, vous passerez en vitesse de croisière. Les attributs MBean FarmMemberService requis pour configurer un 'farm' sont listés ci-dessous."
#. Tag: programlisting
#: Clustering_Guide_Intro.xml:231
@@ -749,7 +745,7 @@
"directory is if does not already exist. If a full URL is not provided, it is "
"assumed that the value is a filesytem path relative to the configuration "
"directory (e.g. <literal>$JBOSS_HOME/server/all/</literal>)."
-msgstr "<emphasis role=\"bold\">URLs</emphasis> pointe vers le répertoire vers lequel le déployeur cherche les fichiers à déployer. Ce MBean va créer ce répertoire s'il n'existe pas déja. Si un URL complet n'est pas donné, on assume que la valeur est celle d'un chemin d'accès de système de fichiers relative à celle du répertoire de configuration (e.g. <literal>$JBOSS_HOME/server/all/</literal>)."
+msgstr "Les <emphasis role=\"bold\">URLs</emphasis> pointent vers le répertoire vers lequel le déployeur cherche les fichiers à déployer. Ce MBean va créer ce répertoire s'il n'existe pas déja. Si un URL complet n'est pas donné, on assume que la valeur est celle d'un chemin d'accès de système de fichiers relative à celle du répertoire de configuration (e.g. <literal>$JBOSS_HOME/server/all/</literal>)."
#. Tag: para
#: Clustering_Guide_Intro.xml:244
@@ -773,7 +769,7 @@
"inherited from the <literal>URLDeploymentScanner</literal> MBean."
msgstr ""
"Le service 'farming' est une extension de <literal>URLDeploymentScanner</"
-"literal>, qui balaye les déploiements à chaud dans le répertoire <literal>deploy/</literal>. Donc, vous pouvez utiliser tous les attributs définis dans le MBean <literal>URLDeploymentScanner</literal> lui même, dans le MBean"
+"literal>, qui balaye les déploiements à chaud dans le répertoire <literal>deploy/</literal>. Donc, vous pouvez utiliser tous les attributs définis dans le MBean <literal>URLDeploymentScanner</literal>, dans le MBean"
"<literal>FarmMemberService</literal>. En fait, les attributs <literal>URLs</"
"literal> et <literal>ScanPeriod</literal> listés ci-dessus, sont hérités du MBean <literal>URLDeploymentScanner</literal>."
@@ -798,7 +794,7 @@
"<literal>HASessionState</literal> Mbean, the <literal>DistributedState</"
"literal> MBean and the JBoss Cache framework."
msgstr ""
-"Dans un environnement de serveur clusterisé, la gestion des états distribués constitue un service clé que doit fournir le cluster. Ainsi, dans une application bean de session à états, l'état de la session doit être synchronisé à toutes les instances Bean à travers tous les noeuds, de façon à que l'application client atteigne le même état de session, quel que soit le noeud qui sert la demande. Dans une application entité Bean, l'objet Bean doit parfois être caché dans le cluster pour réduire le chargement de la base de données. Actuellement, la réplication des états et les services cache distribués de JBoss AS sont fournis de trois façons : Mbean <literal>HASessionState</literal>, Mbean <literal>DistributedState</"
+"Dans un environnement de serveur clusterisé, la gestion des états distribués représente un service clé que le cluster doit fournir. Ainsi, dans une application stateful session bean, l'état de la session doit être synchronisé à toutes les instances bean à travers tous les noeuds, de façon à ce que l'application client atteigne le même état de session, quel que soit le noeud qui sert la demande. Dans une application entité bean, l'objet bean doit parfois être caché dans le cluster pour réduire la charge sur la base de données. Actuellement, la réplication des états et les services cache distribués de JBoss AS sont fournis de trois façons : Mbean <literal>HASessionState</literal>, Mbean <literal>DistributedState</"
"literal> MBean et la structure JBoss Cache."
#. Tag: para
@@ -811,8 +807,8 @@
"cluster-service.xml</literal> file. We will show its configuration options "
"in the EJB 2.x stateful session bean section later."
msgstr ""
-"Le MBean <literal>HASessionState</literal> est un ancien service qui fournit la réplication de sessions et des services cache distribués pour les Beans de session à états EJB 2.x. Le MBean est défini dans le fichier <literal>all/deploy/"
-"cluster-service.xml</literal> file. Nous allons montrer ses options de configuration dans la section sur les Beans de session à état EJB 2.x, plus tard."
+"Le MBean <literal>HASessionState</literal> est un ancien service qui fournit la réplication de sessions et des services cache distribués pour les stateful session bean EJB 2.x. Le MBean est défini dans le fichier <literal>all/deploy/"
+"cluster-service.xml</literal> file. Nous allons montrer ses options de configuration dans la section sur les stateful session bean EJB 2.x, plus tard."
#. Tag: para
#: Clustering_Guide_Intro.xml:268
@@ -822,7 +818,7 @@
"the HAPartition service. It is supported for backwards compatibility "
"reasons, but new applications should not use it; they should use the much "
"more sophisticated JBoss Cache instead."
-msgstr "Le MBean <literal>DistributedState</literal> est un ancien service construit sur le service HAPartition. Il est supporté pour des raisons de compatibilité rétroactive, mais les nouvelles applications ne devraient pas l'utiliser, elles devraient utiliser à la place JBoss Cache, qui est bien plus sophistiqué."
+msgstr "Le MBean <literal>DistributedState</literal> est un ancien service construit sur le service HAPartition. Il est supporté pour des raisons de compatibilité rétroactive, mais les nouvelles applications ne devraient pas l'utiliser, elles devraient plutôt utiliser JBoss Cache, qui est bien plus sophistiqué."
#. Tag: para
#: Clustering_Guide_Intro.xml:274
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Introduction.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Introduction.po 2009-03-24 03:06:43 UTC (rev 86245)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/fr-FR/Clustering_Guide_Introduction.po 2009-03-24 06:20:30 UTC (rev 86246)
@@ -8,7 +8,7 @@
"Project-Id-Version: Clustering_Guide_Introduction\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-01-15 03:45+0000\n"
-"PO-Revision-Date: 2009-02-19 15:03+1000\n"
+"PO-Revision-Date: 2009-03-24 14:35+1000\n"
"Last-Translator: Corina Roe <croe at redhat.com>\n"
"Language-Team: French <i18 at redhat.com>\n"
"MIME-Version: 1.0\n"
@@ -47,7 +47,7 @@
"Clustering is crucial for highly available enterprise applications, as it is "
"the clustering infrastructure that supports the redundancy needed for high "
"availability."
-msgstr "Clustering nous permet d'exécuter une application sur plusieurs serveurs parallèlement (ou noeuds de clusters) tout en fournissant une seule vue aux clients de l'application. La charge est distribuée à travers les différents serveurs, et même si l'un ou plusieurs serveurs sont défaillants, l'application est toujours accessible via les noeuds du cluster qui a pu survivre. Clustering est crucial aux applications d'entreprises modulables, car vous pouvez toujours améliorer la performance en ajoutant simplement des noeuds supplémentaires dans le cluster. Clustering est crucial aux applications d'entreprises hautement disponibles, car c'est l'infrastructure de clustering qui supporte la redondance qu'il faut, pour permettre un haut niveau de disponiblité des applications."
+msgstr "Clustering nous permet d'exécuter une application sur plusieurs serveurs parallèlement (ou noeuds de clusters) tout en fournissant une seule vue aux clients de l'application. La charge est distribuée à travers les différents serveurs, et même si l'un ou plusieurs serveurs sont défaillants, l'application est toujours accessible via les noeuds du cluster qui ont pu survivre. Clustering est crucial aux applications d'entreprises modulables, car vous pouvez toujours améliorer la performance en ajoutant simplement des noeuds supplémentaires dans le cluster. Clustering est crucial aux applications d'entreprises hautement disponibles, car c'est l'infrastructure de clustering qui supporte la redondance qu'il faut, pour permettre un haut niveau de disponiblité des applications."
#. Tag: para
#: Clustering_Guide_Introduction.xml:14
@@ -59,9 +59,7 @@
"literal> command for each instance. Those server instances, all started in "
"the <literal>all</literal> configuration, detect each other and "
"automatically form a cluster."
-msgstr ""
-"Le serveur JBoss Application Server (AS) est accompagné d'un support clustering prêt à l'emploi. La façon la plus simple de démarrer un cluster JBoss, est de démarrer plusieurs instances de JBoss sur le même réseau local, en utilisant la commande <literal>run -c all</"
-"literal> pour chaque instance. Ces instances de serveur, qui sont toutes démarrées dans la configuration <literal>all</literal>, se détectent les unes les autres et forment automatiquement un cluster."
+msgstr "Le serveur JBoss Application Server (AS) est accompagné d'un support clustering prêt à l'emploi. La façon la plus simple de démarrer un cluster JBoss, est de démarrer plusieurs instances de JBoss sur le même réseau local, en utilisant la commande <literal>run -c all</literal> pour chaque instance. Ces instances de serveur, qui sont toutes démarrées dans la configuration <literal>all</literal>, se détectent les unes les autres et forment automatiquement un cluster."
#. Tag: para
#: Clustering_Guide_Introduction.xml:17
@@ -71,7 +69,7 @@
"JBoss's clustering services. It is important that you understand these "
"concepts before reading the rest of the chapter. Clustering configurations "
"for specific types of applications are covered after this section."
-msgstr "Dans la première section de ce chapitre, nous aborderons les concepts de base les services clustering de JBoss. Il est important que vous compreniez bien ces concepts avant de continuer de lire le reste du chapitre. Les configurations de clustering spécifiques à certains types d'applications, sont couvertes à la suite de cette section."
+msgstr "Dans la première section de ce chapitre, nous aborderons les concepts de base des services clustering de JBoss. Il est important que vous compreniez bien ces concepts avant de continuer de lire le reste du chapitre. Les configurations de clustering spécifiques à certains types d'applications, sont couvertes dans ce guide, après cette section."
#. Tag: title
#: Clustering_Guide_Introduction.xml:23
@@ -99,7 +97,7 @@
"and name that matches the other cluster members. In summary, a JBoss cluster "
"is a set of AS server instances each of which is running an identically "
"configured and named JGroups Channel."
-msgstr "Un cluster est un ensemble de noeuds qui communiquent les uns avec les autres vers un but commun. Dans un cluster JBoss Application Server (également connu sous le nom de \"partition\"), un noeud est une instance JBoss Application Server. La communication entre les noeuds est gérée par la bibliothèque de communication de groupes JGroups, avec un canal JGroup Channel qui fournit une fonctionnalité de base de pouvoir tracer qui est dans le cluster et de pouvoir échanger des messages entre les membres du cluster. Les canaux JGroups qui ont la même configuration et le même nom, ont la possibilité de se découvrir les uns les autres de façon dynamique, et de former un groupe. C'est pourquoi simplement exécuter un \"run -c all\" sur deux instances AS sur le même réseau, leur suffit pour former un cluster - chaque AS démarre un canal (ou plutôt, un certain nombre de canaux) avec la même configuration par défaut, de façon à ce qu'ils puissent se découvr!
ir dynamiquement les uns les autres et former un cluster. Les noeuds peuvent être dynamiquement ajoutés et retirés des clusters à tout moment, simplement en démarrant ou en arrêtant un canal grâce à une configuration et à un nom qui correspondent à ceux des autres membres d'un cluster. En bref, a cluster JBoss est un ensemble d'instances de serveurs AS, qui exécutent chacun un canal JGroups Channel configuré et nommé de manière identique."
+msgstr "Un cluster est un ensemble de noeuds qui communiquent les uns avec les autres dans un but commun. Dans un cluster JBoss Application Server (également connu sous le nom de \"partition\"), un noeud est une instance JBoss Application Server. La communication entre les noeuds est gérée par la bibliothèque de communication de groupes JGroups, avec un canal JGroup Channel qui fournit une fonctionnalité de base pour pouvoir tracer qui est dans le cluster et pour pouvoir échanger des messages entre les membres du cluster. Les canaux JGroups qui ont la même configuration et le même nom, ont la possibilité de se découvrir les uns les autres de façon dynamique, et de former un groupe. C'est pourquoi simplement exécuter un \"run -c all\" sur deux instances AS du même réseau leur suffit pour former un cluster - chaque AS démarre un canal (ou plutôt, un certain nombre de canaux) avec la même configuration par défaut, de façon à ce qu'ils puissent se découvrir!
dynamiquement les uns les autres et former un cluster. Les noeuds peuvent être dynamiquement ajoutés et retirés des clusters à tout moment, simplement en démarrant ou en arrêtant un canal grâce à une configuration et à un nom qui correspondent à ceux des autres membres d'un cluster. En bref, a cluster JBoss est un ensemble d'instances de serveurs AS exécutant un canal JGroups Channel configuré et nommé de manière identique."
#. Tag: para
#: Clustering_Guide_Introduction.xml:29
@@ -155,7 +153,7 @@
"categories: the Channel used by the general purpose HAPartition service, and "
"three Channels created by JBoss Cache for special purpose caching and "
"cluster wide state replication."
-msgstr "Les sections \"Configuration JGroups\" et \"Isoler les canaux JGroups\" couvrent en détail comment configurer les canaux de telle façon à ce que les homologues souhaités puissent se trouver et les autres non. Comme mentionné plus haut, JBoss AS utilise par défaut quatre canaux JGroups séparés. Ceux-ci peuvent être divisés en deux grandes catégories : le canal utilisé par le service HAPartition d'intérêt général, et trois canaux créés par JBoss Cache pour caching spécifique ou réplication d'états dans l'ensemble du cluster."
+msgstr "La section portant sur \"Configuration JGroups\" et sur \"Isoler les canaux JGroups\" couvre en détail comment configurer les canaux de telle façon à ce que les homologues souhaités puissent se trouver et les autres non. Comme mentionné plus haut, JBoss AS utilise par défaut quatre canaux JGroups séparés. Ceux-ci peuvent être divisés en deux grandes catégories : le canal utilisé par le service HAPartition d'intérêt général, et trois canaux créés par JBoss Cache pour caching spécifique ou réplication d'états dans l'ensemble du cluster."
#. Tag: title
#: Clustering_Guide_Introduction.xml:50
@@ -178,7 +176,7 @@
"rest of this guide, including smart client-side clustered proxies, EJB 2 "
"SFSB replication and entity cache management, farming, HA-JNDI and HA "
"singletons."
-msgstr "HAPartition est un service d'intérêt général utilisé pour un ensemble de tâches dans AS clustering. A la base, il s'agit d'une abstraction construite sur un canal JGroups, qui fournit un support pour créer/recevoir des invocations RPC sur/à partir d'un ou de plusieurs membres du cluster. HAPartition supporte également un registre distribué indiquant quels services sont exécutés sur quels membres du cluster. Il envoie des notifications vers les listeners intéressés pour les changements d'appartenance au cluster ou d'enregistrement de services clusterisés. HAPartition constitue la base de bien des services clusterisés dont nous allons discuter au cours de ce guide, y compris les proxies clusterisés smart côté-client, la replication EJB 2 SFSB et la gestion d'entités cache, le farming et les singletons HA-JNDI et HA."
+msgstr "HAPartition est un service d'intérêt général utilisé pour un ensemble de tâches dans AS clustering. A la base, il s'agit d'une abstraction construite sur un canal JGroups, qui fournit un support pour créer/recevoir des invocations RPC sur/à partir d'un ou de plusieurs membres du cluster. HAPartition supporte également un registre distribué indiquant quels services sont exécutés sur quels membres du cluster. Il envoie des notifications vers les listeners intéressés par les changements d'appartenance au cluster ou par les changements d'enregistrement de services clusterisés. HAPartition constitue la base de bien des services clusterisés dont nous allons discuter au cours de ce guide, y compris les proxies clusterisés smart côté-client, la replication EJB 2 SFSB et la gestion d'entités cache, le farming et les singletons HA-JNDI et HA."
#. Tag: para
#: Clustering_Guide_Introduction.xml:58
@@ -256,7 +254,7 @@
"nodes, and its configuration is discussed in <xref linkend=\"jbosscache-"
"jgroups\"/>. The following list shows the available configuration attributes "
"in the <literal>HAPartition</literal> MBean."
-msgstr "Ici, nous avons omis la configuraiton de protocole JGroups détaillée s'appliquant à ce canal. JGroups gère la communication sous-jacente d'un noeud homologue à un autre, et sa configuration est abordée dans <xref linkend=\"jbosscache-jgroups\"/>. La liste suivante montre les attributs de configuration disponibles pour le MBean <literal>HAPartition</literal>."
+msgstr "Ici, nous avons omis la configuration de protocole JGroups détaillée s'appliquant à ce canal. JGroups gère la communication sous-jacente d'un noeud homologue à un autre, et sa configuration est abordée dans <xref linkend=\"jbosscache-jgroups\"/>. La liste suivante montre les attributs de configuration disponibles pour le MBean <literal>HAPartition</literal>."
#. Tag: para
#: Clustering_Guide_Introduction.xml:68
@@ -296,7 +294,7 @@
"(in milliseconds). State replication refers to the process of obtaining "
"initial application state from other already-running cluster members at "
"service startup. Its default value is <literal>30000</literal>."
-msgstr "<emphasis role=\"bold\">StateTransferTimeout</emphasis> est un attribut optionnel qui spécifie le délai de réplication des états à travers le cluster (en millesecondes). La réplication d'états se réfère au processus d'obtention d'états initiaux de la part d'autres membres du cluster en cours d'exécution au moment du démarrage du service. Sa valeur par défaut est de <literal>30000</literal>."
+msgstr "<emphasis role=\"bold\">StateTransferTimeout</emphasis> est un attribut optionnel qui spécifie le délai de réplication des états à travers le cluster (en millesecondes). La réplication d'états se réfère au processus d'obtention d'états initiaux de la part d'autres membres du cluster en cours d'exécution au moment du démarrage du service. Sa valeur par défaut est de <literal>30 000</literal>."
#. Tag: para
#: Clustering_Guide_Introduction.xml:83
@@ -332,7 +330,7 @@
"CurrentView field."
msgstr ""
"Vous pouvez visualiser les informations sur le cluster en cours en pointant votre navigateur vers la console JMX de n'importe quelle instance JBoss du cluster (c'est à dire, <literal>http://"
-"hostname:8080/jmx-console/</literal>), puis cliquer sur le MBean <literal>jboss:service=DefaultPartition</literal> (changer le nom du MBean pour refléter votre nom de partition si vous utilise le commutateur -g startup). Une liste des adresses IP pour les membres actuels du cluster apparaîtra dans le champ CurrentView."
+"hostname:8080/jmx-console/</literal>), puis cliquer sur le MBean <literal>jboss:service=DefaultPartition</literal> (changer le nom du MBean pour refléter votre nom de partition si vous utilisez le commutateur -g startup). Une liste des adresses IP pour les membres actuels du cluster apparaîtra dans le champ CurrentView."
#. Tag: title
#: Clustering_Guide_Introduction.xml:94 Clustering_Guide_Introduction.xml:398
@@ -414,7 +412,7 @@
"object figures out how to find the appropriate server node, marshal call "
"parameters, un-marshall call results, and return the result to the caller "
"client."
-msgstr "La plupart des services distants fournis par le serveur d'applications JBoss, comprenant JNDI, EJB, JMS, RMI et JBoss Remoting, requièrent que le client obtienne (comme apr ex. pour rechercher ou décharger) un objet stub (ou proxy). L'objet stub est généré par le serveur et il implémente l'interface commerciale du service. Le client fait alors des appels méthode locale vers l'objet stub. Le stub dirige automatiquement l'appel à travers le réseau vers où il est invoqué pour des objets de service gérés dans le serveur. Dans un environnement de clustering, l'objet stub généré par le serveur inclut un intercepteur qui sait diriger des appels vers des noeuds multiples à travers le cluster. L'objet stub détermine comment trouver le noeud de serveur qui convient, les paramètres d'appels ordonnancés, les résultats d'appels non-ordonnancés, et retourne le résultat au client."
+msgstr "La plupart des services distants fournis par le serveur d'applications JBoss, comprenant JNDI, EJB, JMS, RMI et JBoss Remoting, requièrent que le client obtienne (comme par ex. pour rechercher ou décharger) un objet stub (ou proxy). L'objet stub est généré par le serveur et il implémente l'interface commerciale du service. Le client fait alors des appels méthode locale vers l'objet stub. Le stub dirige automatiquement l'appel à travers le réseau vers lequel il est invoqué pour des objets de service gérés dans le serveur. Dans un environnement de clustering, l'objet stub généré par le serveur inclut un intercepteur qui sait diriger des appels vers des noeuds multiples à travers le cluster. L'objet stub détermine comment trouver le noeud de serveur qui convient, les paramètres d'appels ordonnancés, les résultats d'appels non-ordonnancés, et retourner le résultat au client."
#. Tag: para
#: Clustering_Guide_Introduction.xml:120
@@ -575,9 +573,7 @@
"shared by all stubs in the same client-side VM that are associated with the "
"same target service. So if a particular client downloads two stubs for the "
"same target service (e.g. an EJB), each stub will use the same target."
-msgstr ""
-"First Available Identical All Proxies (<literal>org.jboss.ha.framework."
-"interfaces.FirstAvailableIdenticalAllProxies</literal>): possède le même comportement que la politique \"First Available\" (premier disponible) sauf que le noeud cible choisi est partagé par tous les stubs de la même MV côté-client qui est associée au même service cible. Donc, si un client donné décharge deux stubs d'un même service cible (par ex. EJB), chaque stub devra utiliser la même cible."
+msgstr "First Available Identical All Proxies (<literal>org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies</literal>): possède le même comportement que la politique \"First Available\" (premier disponible) sauf que le noeud cible choisi est partagé par tous les stubs de la même MV côté-client associée au même service cible. Donc, si un client donné décharge deux stubs d'un même service cible (par ex. EJB), chaque stub devra utiliser la même cible."
#. Tag: para
#: Clustering_Guide_Introduction.xml:190
@@ -590,7 +586,7 @@
"by different services."
msgstr ""
"C'est une implémentation de l'interface org.jboss.ha.framework."
-"interfaces.LoadBalancePolicy. Les utilisateurs sont libres d'écrire leur propre implémentation de cette simple interface s'ils ont besoin d'un comportement particulier. Dans les sections qui suivent, nous verrons comment configurer les politiques d'équilibre des charges utilisées par des services différents."
+"interfaces.LoadBalancePolicy. Les utilisateurs sont libres d'écrire leur propre implémentation de cette simple interface s'ils recherchent un comportement particulier. Dans les sections qui suivent, nous verrons comment configurer les politiques d'équilibre des charges utilisées par des services différents."
#. Tag: title
#: Clustering_Guide_Introduction.xml:194
@@ -609,7 +605,7 @@
"enabled, once the load balancer routes a request from a client to node A and "
"the server initiates a session, all future requests associated with that "
"session must be routed to node A, so long as node A is available."
-msgstr "Comme noté ci-dessus, un équilibreur de charges externe fournit ses propres capacités d'équilibrage des charges. Les capacités supportées dépendent du fournisseur de l'équilibreur des charges. Le seul prérequis JBoss, c'est que l'équilibreur de charges supporte “session affinity†(alias “sticky sessionsâ€). Quand 'session affinity' est activé, et une fois que l'équilibreur des charges dirige une demande d'un client vers le noeud A et que le serveur initialise une session, toutes les demandes à venir associées à cette session doivent être dirigées vers le noeud A, dans la mesure où le noeud A est disponible."
+msgstr "Comme noté ci-dessus, un équilibreur de charges externe fournit ses propres capacités d'équilibrage des charges. Les capacités supportées dépendent du fournisseur de l'équilibreur des charges. Le seul prérequis JBoss, c'est que l'équilibreur de charges supporte “session affinity†(alias “sticky sessionsâ€). Quand 'session affinity' est activé, et une fois que l'équilibreur des charges dirige une demande d'un client vers le noeud A et que le serveur initialise une session, toutes les demandes à venir associées à cette session devront être dirigées vers le noeud A, dans la mesure où le noeud A est disponible."
#. Tag: title
#: Clustering_Guide_Introduction.xml:206
@@ -648,7 +644,7 @@
"the application really represents a new deployment or represents an old "
"deployment that was removed from the rest of the cluster while the newly "
"starting node was off-line. We are working to resolve this issue."
-msgstr "Actuellement, en raison d'un problème d'implémentation, le service de déploiement de 'farming' est limité. Il fonctionne uniquement pour 1) les archives situées dans le répertoire farm/ du premier noeud à rejoindre le cluster ou 2) pour les archives déployées à chaud. Si vous commencez par mettre une application dans le répertoire /farm, et que vous démarrez le serveur pour qu'il rejoigne un cluster en cours d'exécution, l'application ne sera pas poussée à travers le groupement ou déployée. C'est parce que le service 'farming' ne sait pas si l'application représente un nouveau déploiement réel ou si elle représente un ancien déploiement qui a été retiré du reste du cluster tandis que le noeud qui commençait à démarrer était hors-ligne. Nous essayons actuellement de résoudre ce problème."
+msgstr "Actuellement, en raison d'un problème d'implémentation, le service de déploiement de 'farming' est limité. Il fonctionne uniquement pour 1) les archives situées dans le répertoire farm/ du premier noeud à rejoindre le cluster ou 2) pour les archives déployées à chaud. Si vous commencez par mettre une application dans le répertoire /farm, et que vous démarrez le serveur pour qu'il rejoigne un cluster en cours d'exécution, l'application ne sera pas poussée à travers le groupement ou déployée. C'est parce que le service 'farming' ne sait pas si l'application représente un nouveau déploiement réel ou si elle représente un ancien déploiement qui a été retiré du reste du cluster alors que le noeud qui commençait à démarrer était hors-ligne. Nous essayons actuellement de résoudre ce problème."
#. Tag: para
#: Clustering_Guide_Introduction.xml:220
@@ -672,7 +668,7 @@
"quite likely, for example, that a redeployment will happen on all nodes in "
"the cluster simultaneously, briefly leaving no nodes in the cluster "
"providing service."
-msgstr "Le déploiement 'farming' n'est pas atomique. Un problème de déploiement, de rétraction de déploiement ou redéploiement d'une application sur un noeud du cluster n'empêchera par que le déploiement , rétraction de déploiement ou redéploiement, soit effectué sur les autres noeuds. Il n'existe pas de possibilité de rollback. Aussi, le déploiement n'est pas effectué par étapes, et il est très possible, par exemple, qu'un déploiement ait lieu sur tous les noeuds d'un cluster simultanément, causant ainsi une interruption de services des noeuds du cluster."
+msgstr "Le déploiement 'farming' n'est pas atomique. Un problème de déploiement, de rétraction de déploiement ou redéploiement d'une application sur un noeud du cluster n'empêchera par que les déploiement , rétraction de déploiement ou redéploiement, soient effectués sur les autres noeuds. Il n'existe pas de possibilité de rollback. Aussi, le déploiement n'est pas effectué par étapes, et il est très possible, par exemple, qu'un déploiement ait lieu sur tous les noeuds d'un cluster simultanément, causant de ce fait une interruption de services des noeuds du cluster."
#. Tag: para
#: Clustering_Guide_Introduction.xml:227
@@ -696,7 +692,7 @@
msgid ""
"After deploying farm-service.xml you are ready to rumble. The required "
"FarmMemberService MBean attributes for configuring a farm are listed below."
-msgstr "Après avoir déployé farm-service.xml, vous passez en vitesse de croisière. Les attributs MBean FarmMemberService requis pour configurer un 'farm' sont listés ci-dessous."
+msgstr "Après avoir déployé farm-service.xml, vous passerez en vitesse de croisière. Les attributs MBean FarmMemberService requis pour configurer un 'farm' sont listés ci-dessous."
#. Tag: programlisting
#: Clustering_Guide_Introduction.xml:232
@@ -758,7 +754,7 @@
"directory is if does not already exist. If a full URL is not provided, it is "
"assumed that the value is a filesytem path relative to the configuration "
"directory (e.g. <literal>$JBOSS_HOME/server/all/</literal>)."
-msgstr "<emphasis role=\"bold\">URLs</emphasis> pointe vers le répertoire vers lequel le déployeur cherche les fichiers à déployer. Ce MBean va créer ce répertoire s'il n'existe pas déja. Si un URL complet n'est pas donné, on assume que la valeur est celle d'un chemin d'accès de système de fichiers relative à celle du répertoire de configuration (e.g. <literal>$JBOSS_HOME/server/all/</literal>)."
+msgstr "<emphasis role=\"bold\">URLs</emphasis> pointe vers le répertoire vers lequel le déployeur cherche les fichiers à déployer. Ce MBean va créer ce répertoire s'il n'existe pas déjà . Si un URL complet n'est pas donné, on assume que la valeur est celle d'un chemin d'accès de système de fichiers relative à celle du répertoire de configuration (par ex. <literal>$JBOSS_HOME/server/all/</literal>)."
#. Tag: para
#: Clustering_Guide_Introduction.xml:245
@@ -767,7 +763,7 @@
"<emphasis role=\"bold\">ScanPeriod</emphasis> specifies the interval at "
"which the folder must be scanned for changes.. Its default value is "
"<literal>5000</literal>."
-msgstr "<emphasis role=\"bold\">ScanPeriod</emphasis> spécifie l'interval au cours duquel le dossier doit être balayé pour les changements. La valeur par défaut est <literal>5000</literal>."
+msgstr "<emphasis role=\"bold\">ScanPeriod</emphasis> spécifie l'interval au cours duquel le dossier doit être balayé pour identifier les changements. La valeur par défaut est <literal>5 000</literal>."
#. Tag: para
#: Clustering_Guide_Introduction.xml:249
@@ -782,7 +778,7 @@
"inherited from the <literal>URLDeploymentScanner</literal> MBean."
msgstr ""
"Le service 'farming' est une extension de <literal>URLDeploymentScanner</"
-"literal>, qui balaye les déploiements à chaud dans le répertoire <literal>deploy/</literal>. Donc, vous pouvez utiliser tous les attributs définis dans le MBean <literal>URLDeploymentScanner</literal> lui même, dans le MBean"
+"literal>, qui balaye les déploiements à chaud dans le répertoire <literal>deploy/</literal>. Donc, vous pouvez utiliser tous les attributs définis dans le MBean <literal>URLDeploymentScanner</literal> lui-même dans le MBean"
"<literal>FarmMemberService</literal>. En fait, les attributs <literal>URLs</"
"literal> et <literal>ScanPeriod</literal> listés ci-dessus, sont hérités du MBean <literal>URLDeploymentScanner</literal>."
@@ -807,7 +803,7 @@
"<literal>HASessionState</literal> Mbean, the <literal>DistributedState</"
"literal> MBean and the JBoss Cache framework."
msgstr ""
-"Dans un environnement de serveur clusterisé, la gestion des états distribués constitue un service clé que doit fournir le cluster. Ainsi, dans une application bean de session à états, l'état de la session doit être synchronisé à toutes les instances Bean à travers tous les noeuds, de façon à que l'application client atteigne le même état de session, quel que soit le noeud qui sert la demande. Dans une application entité Bean, l'objet Bean doit parfois être caché dans le cluster pour réduire le chargement de la base de données. Actuellement, la réplication des états et les services cache distribués de JBoss AS sont fournis de trois façons : Mbean <literal>HASessionState</literal>, Mbean <literal>DistributedState</"
+"Dans un environnement de serveur clusterisé, la gestion des états distribués constitue un service clé que doit fournir le cluster. Ainsi, dans une application stateful session bean, le session bean doit être synchronisé à toutes les instances Bean à travers tous les noeuds, de façon à que l'application client atteigne le même état de session, quel que soit le noeud qui sert la demande. Dans une application entité Bean, l'objet Bean doit parfois être caché dans le cluster pour réduire le chargement de la base de données. Actuellement, la réplication des états et les services cache distribués de JBoss AS sont fournis de trois façons : Mbean <literal>HASessionState</literal>, Mbean <literal>DistributedState</"
"literal> MBean et la structure JBoss Cache."
#. Tag: para
More information about the jboss-cvs-commits
mailing list