[jboss-cvs] JBossAS SVN: r84914 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE.

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

Author: hpeters
Date: 2009-03-02 02:06:37 -0500 (Mon, 02 Mar 2009)
New Revision: 84914

Modified:
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_EJBs.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_HTTP.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JNDI.po
Log:
translation update in process

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po	2009-03-02 05:52:08 UTC (rev 84913)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po	2009-03-02 07:06:37 UTC (rev 84914)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_Clustered_Singleton_Services\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-02-25 17:19+1000\n"
+"PO-Revision-Date: 2009-03-02 16:02+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -35,13 +35,13 @@
 "restarted on the new master. Thus, other than a brief interval when one "
 "master has stopped and another has yet to take over, the service is always "
 "being provided by one but only one node."
-msgstr "Ein geclusterter Singleton-Dienst (sog. HA Singleton) ist ein Dienst, der zwar auf mehreren Nodes eines Clusters deployt wird, seinen Dienst aber nur auf einem der Nodes bereitstellt. Der Node, auf dem der Singleton-Dienst ausgeführt wird, wird in der Regel als der \"Master Node\" bezeichnet. Wenn der Master ausfällt oder beendet wird, so wird ein anderer Master aus den verbleibenden Nodes ausgewählt und der Dienst wird wieder gestartet auf dem neuen Master. Abgesehen von einem kurzen Moment, während ein Master bereits beendet ist und der neue erst noch übernehmen muss, wird der Dienst demzufolge immer von (nur) einem Node bereitgestellt."
+msgstr "Ein geclusterter Singleton-Dienst (auch als HA Singleton bekannt) ist ein Dienst, der zwar auf mehreren Nodes eines Clusters deployt wird, seinen Dienst jedoch nur auf einem der Nodes bereitstellt. Der Node, auf dem der Singleton-Dienst ausgeführt wird, wird in der Regel als der \"Master Node\" bezeichnet. Wenn der Master ausfällt oder beendet wird, so wird ein anderer Master aus den verbleibenden Nodes ausgewählt und der Dienst wird auf dem neuen Master neu gestartet. Abgesehen von einem kurzen Moment, in dem ein Master bereits beendet ist und der neue erst noch übernehmen muss, wird der Dienst demzufolge immer von (nur) einem Node bereitgestellt."
 
 #. Tag: title
 #: Clustering_Guide_Clustered_Singleton_Services.xml:9
 #, no-c-format
 msgid "Topology after the Master Node fails"
-msgstr "Topologie nachdem der Master Node ausfällt"
+msgstr "Topologie nach Ausfall des Master Nodes"
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:17
@@ -55,7 +55,7 @@
 "different nodes in the cluster start and stop; based on those notifications "
 "each node in the cluster can independently (but consistently) determine if "
 "it is now the master node and needs to begin providing a service."
-msgstr "Der JBoss Applikationsserver (AS) bietet Unterstützung für eine Reihe von Strategien, die Ihnen beim Deployment von geclusterten Singleton-Diensten behilflich sein sollen. In diesem Abschnitt werden wir die verschiedenen Strategien behandeln. Alle dieser Strategien bauen auf dem in der Einführung beschriebenen HAPartition-Dienst auf. Sie sind darauf angewiesen, dass <literal>HAPartition</literal> Benachrichtigungen ausgibt, wenn verschiedene Nodes dem Cluster beitreten oder daraus austreten; basierend auf diesen Benachrichtigungen kann jeder Node im Cluster unabhängig (aber einheitlich) feststellen, ob er nun der Master Node ist und ab jetzt einen Dienst bereitstellen muss."
+msgstr "Der JBoss Applikationsserver (AS) bietet Unterstützung für eine Reihe von Strategien, die Ihnen beim Deployment von geclusterten Singleton-Diensten behilflich sein sollen. In diesem Abschnitt werden wir die verschiedenen Strategien behandeln. Alle diese Strategien bauen auf dem in der Einführung beschriebenen HAPartition-Dienst auf. Sie sind darauf angewiesen, dass <literal>HAPartition</literal> Benachrichtigungen ausgibt, wenn verschiedene Nodes dem Cluster beitreten oder daraus austreten; basierend auf diesen Benachrichtigungen kann jeder Node im Cluster unabhängig (aber widerspruchsfrei) feststellen, ob er nun der Master Node ist und jetzt einen Dienst bereitstellen muss."
 
 #. Tag: title
 #: Clustering_Guide_Clustered_Singleton_Services.xml:22
@@ -82,8 +82,8 @@
 "service when it stops being the master (typically at server shutdown) is to "
 "undeploy the contents of <literal>deploy-hasingleton</literal>."
 msgstr ""
-"Die einfachste und gebräuchlichste Strategie zum Deployment eines HA-Singletons besteht darin, ein gewöhnliches Deployment zu nehmen (war, ear, jar, oder was immer Sie üblicherweise in deploy platzieren), und es in dem <literal>$JBOSS_HOME/server/all/deploy-hasingleton</literal>-Verzeichnis zu deployen, statt in <literal>deploy</"
-"literal>. Das <literal>deploy-hasingleton</literal>-Verzeichnis liegt nicht unter deploy oder farm, also werden seine Inhalte nicht automatisch deployt, wenn eine AS-Instanz startet. Stattdessen obliegt es einem speziellen Dienst, die Inhalte dieses Verzeichnisses zu deployen – dem <literal>jboss.ha:service=HASingletonDeployer</literal>-MBean (was wiederum via der deploy/deploy-hasingleton-service.xml-Datei deployt wird). Der HASingletonDeployer-Dienst ist selbst ein HA-Singleton, dessen bereitgestellter Dienst, sobald er Master wird, darin besteht, die Inhalte von deploy-hasingleton zu deployen, und dessen Dienst, sobald er aufhört Master zu sein (normalerweise beim Beenden des Servers), darin besteht, die Inhalte von <literal>deploy-hasingleton</literal> zu un-deployen."
+"Die einfachste und gebräuchlichste Strategie zum Deployment eines HA-Singletons besteht darin, ein gewöhnliches Deployment zu nehmen (war, ear, jar, oder was immer Sie üblicherweise in deploy platzieren), und es in dem <literal>$JBOSS_HOME/server/all/deploy-hasingleton</literal>-Verzeichnis auszuführen, statt in <literal>deploy</"
+"literal>. Das <literal>deploy-hasingleton</literal>-Verzeichnis liegt nicht unter deploy oder farm, also werden dessen Inhalte nicht automatisch ausgeführt, wenn eine AS-Instanz startet. Stattdessen obliegt es einem speziellen Dienst, die Inhalte dieses Verzeichnisses auszuführen – dem <literal>jboss.ha:service=HASingletonDeployer</literal>-MBean (was wiederum via der deploy/deploy-hasingleton-service.xml-Datei ausgeführt wird). Der HASingletonDeployer-Dienst ist selbst ein HA-Singleton, dessen bereitgestellter Dienst, sobald er Master wird, im Deployment der Inhalte von deploy-hasingleton besteht, und dessen Dienst, sobald er aufhört Master zu sein (normalerweise beim Beenden des Servers), im Beenden des Deployments der Inhalte von <literal>deploy-hasingleton</literal> besteht."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:26
@@ -94,7 +94,7 @@
 "the master node cleanly shuts down, they will be cleanly undeployed as part "
 "of shutdown. If the master node fails or is shut down, they will be deployed "
 "on whatever node takes over as master."
-msgstr "Indem Sie also Ihre Deployments in <literal>deploy-hasingleton</literal> platzieren, wissen Sie, dass sie nur auf dem Master Node im Cluster deployt werden. Wenn der Master Node ordnungsgemäß beendet wird, werden sie im Rahmen des Beendigungsprozesses ebenso ordnungsgemäß un-deployt. Falls jedoch der Master Node ausfällt oder geschlossen wird, werden sie auf demjenigen Node deployt werden, der als Master einspringt."
+msgstr "Wenn Sie also Ihre Deployments in <literal>deploy-hasingleton</literal> platzieren, wissen Sie, dass sie nur auf dem Master Node im Cluster ausgeführt werden. Wenn der Master Node ordnungsgemäß beendet wird, wird ihre Ausführung im Rahmen des Beendigungsprozesses ebenso ordnungsgemäß gestoppt. Falls jedoch der Master Node ausfällt oder geschlossen wird, werden sie auf demjenigen Node ausgeführt werden, der als Master einspringt."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:29
@@ -120,13 +120,13 @@
 "it will be providing services. Depending on how complex the deployment of "
 "your service is and what sorts of startup activities it engages in, this "
 "could take a while, during which time the service is not being provided."
-msgstr "Wenn der Master Node ausfällt und ein anderer Node als Master übernimmt, muss ihr Singleton-Dienst den gesamten Deployment-Prozess durchlaufen, bevor er Dienste bereitstellt. Abhängig von der Komplexität des Deployment Ihres Dienstes und der Art von Aktivitäten beim Hochfahren, kann dies eine Weile dauern, währenddessen der Dienst nicht bereitgestellt werden kann."
+msgstr "Wenn der Master Node ausfällt und ein anderer Node als Master übernimmt, muss Ihr Singleton-Dienst den gesamten Deployment-Prozess durchlaufen, bevor er Dienste liefert. Abhängig von der Komplexität des Deployments Ihres Dienstes und der Art von Aktivitäten beim Hochfahren, kann dies eine Weile dauern, währenddessen der Dienst nicht verfügbar ist."
 
 #. Tag: title
 #: Clustering_Guide_Clustered_Singleton_Services.xml:50
 #, no-c-format
 msgid "Mbean deployments using HASingletonController"
-msgstr "Mbean Deployments unter Verwendung des HASingletonController"
+msgstr "MBean-Deployments unter Verwendung des HASingletonController"
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:51
@@ -141,7 +141,7 @@
 "on your service telling it to begin providing service. If it determines it "
 "is no longer the master node, it invokes a method on your service telling it "
 "to stop providing service. Let's walk through an illustration."
-msgstr "Falls Ihr Dienst ein MBean ist (d. h. kein J2EE-Deployment wie ein ear, war oder jar), können Sie ihn zusammen mit einem Dienst namens HASingletonController deployen, um es in einen HA-Singleton umzuwandeln. Es ist Aufgabe des HASingletonControllers, den Cluster in Zusammenarbeit mit dem HAPartition-Dienst zu überwachen und zu bestimmen, ob er nun der Master Node für seinen Dienst ist. Falls er feststellt, dass er nun der Master Node ist, ruft er eine Methode an Ihrem Dienst auf und teilt ihm mit, die Bereitstellung des Dienstes zu beginnen. Wenn er feststellt, dass er nicht länger der Master Node ist, ruft er eine Methode an Ihrem Service auf und teilt ihm mit, die Bereitstellung des Dienstes zu beenden. Gehen wir schrittweise ein Beispiel durch."
+msgstr "Falls Ihr Dienst ein MBean ist (d. h. kein J2EE-Deployment wie ein ear, war oder jar), können Sie es zusammen mit einem Dienst namens HASingletonController deployen, um es in einen HA-Singleton umzuwandeln. Es ist Aufgabe des HASingletonControllers, den Cluster in Zusammenarbeit mit dem HAPartition-Dienst zu überwachen und zu bestimmen, ob er nun der Master Node für seinen Dienst ist. Falls er feststellt, dass er nun der Master Node ist, ruft er eine Methode an Ihrem Dienst auf und teilt ihm mit, die Bereitstellung des Dienstes zu beginnen. Wenn er feststellt, dass er nicht länger der Master Node ist, ruft er eine Methode an Ihrem Dienst auf und teilt ihm mit, die Bereitstellung des Dienstes zu beenden. Gehen wir schrittweise ein Beispiel durch."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:54
@@ -151,7 +151,7 @@
 "only thing special about it is it needs to expose in its MBean interface a "
 "method that can be called when it should begin providing service, and "
 "another that can be called when it should stop providing service:"
-msgstr "Zunächst einmal haben wir ein MBean-Dienst, den wir zum HA-Singleton machen wollen. Das einzig Besondere daran ist, dass es in seiner MBean-Schnittstelle eine Methode offenlegen muss, die aufgerufen werden kann, sobald er mit dem Bereitstellen von Diensten beginnen soll, sowie einer anderen Methode, die aufgerufen werden kann, sobald er mit dem Bereitstellen von Diensten aufhören soll:"
+msgstr "Zunächst einmal haben wir ein MBean-Dienst, den wir zum HA-Singleton machen wollen. Das einzig Besondere daran ist, dass es in seiner MBean-Schnittstelle eine Methode offenlegen muss, die aufgerufen werden kann, sobald er mit dem Bereitstellen von Diensten beginnen soll, sowie eine andere Methode, die aufgerufen werden kann, sobald er mit dem Bereitstellen von Diensten aufhören soll:"
 
 #. Tag: programlisting
 #: Clustering_Guide_Clustered_Singleton_Services.xml:57
@@ -201,7 +201,7 @@
 msgid ""
 "We used “startSingleton” and “stopSingleton” in the above example, but you "
 "could name the methods anything."
-msgstr "Wir verwendeten “startSingleton” und “stopSingleton” im obigen Beispiel, aber Sie können diese Methoden beliebig benennen."
+msgstr "Wir verwendeten im obigen Beispiel “startSingleton” und “stopSingleton”, aber Sie können diese Methoden beliebig benennen."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:62
@@ -210,7 +210,7 @@
 "Next, we deploy our service, along with an HASingletonController to control "
 "it, most likely packaged in a .sar file, with the following <literal>META-"
 "INF/jboss-service.xml</literal>:"
-msgstr "Als nächstes deployen wir unseren Dienst, zusammen mit einem HASingletonController, um ihn zu kontrollieren, vermutlich gepackt in einer .sar-Datei, mit dem folgenden <literal>META-INF/jboss-service.xml</literal>:"
+msgstr "Als nächstes deployen wir unseren Dienst zusammen mit einem HASingletonController, um ihn zu kontrollieren, wahrscheinlich verpackt in einer .sar-Datei, mit dem folgenden <literal>META-INF/jboss-service.xml</literal>:"
 
 #. Tag: programlisting
 #: Clustering_Guide_Clustered_Singleton_Services.xml:65
@@ -293,7 +293,12 @@
 "deployed; it doesn't wait until the node becomes the master node. So, the "
 "service could be primed and ready to go, just waiting for the controller to "
 "implement startSingleton() at which point it can immediately provide service."
-msgstr "Ein offensichtlicher Nachteil bei diesem Verfahren ist, dass es nur für MBeans funktioniert. Vorteil ist, dass das obige Beispiel in <literal>deploy</literal> oder <literal>farm</literal> platziert werden kann und dadurch Hot Deployment und Farmed Deployment möglich ist. Auch könnten komplexe, zeitintensive Anforderungen für den Start in unserem Beispiel möglicherweise in create()- oder start()-Methoden implementiert werden. JBoss ruft create() oder start() auf, sobald der Dienst deployt wird; es wartet nicht darauf, dass der Node zum Master Node wird. Also kann der Dienst einsatzbereit sein, und nur darauf warten, dass der Controller startSingleton() implementiert, woraufhin er sofort seinen Dienst bereitstellen kann."
+msgstr ""
+"Ein offensichtliches Manko hteilsbei diesems Verfahren ist, dass es nur für MBeans funkoniert. "
+"Vorteil ist, dass das obige Beispiel in <literal>deploy</literal> oder <literal>farm</literal> platziert werden kann und dadurch Hot Deployment und Farmed Deployment mögch ist. "
+"Auch könnten komplexe, zeitn fürup-Anforderungen den Start in unserem Beispiel möglicherweise in create()- oder start()-Methoden implementierwerden. "
+"JBoss ruft create() oder start() auf, sobald der Dienst deployt wird; es wartet nicht darauf, dass der Node zum Master Ne wird. "
+"Also kann der Dienst einsatzbereit braucht seinnoch , und nzu ur darauf warten, dass der Controller startSingleton() implementiert, woraufhin er sofort seinen Dienst bereitstellen kann."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:72
@@ -303,7 +308,7 @@
 "an interesting example of using an HASingletonController. Here is its "
 "deployment descriptor (extracted from the <literal>deploy/deploy-hasingleton-"
 "service.xml</literal> file):"
-msgstr "Der oben erläuterte jboss.ha:service=HASingletonDeployer-Dienst ist selbst ein interessantes Beispiel für die Anwendung eines HASingletonControllers. Nachfolgend sehen Sie seinen Deployment-Deskriptor (extrahiert aus der <literal>deploy/deploy-hasingleton-service.xml</literal>-Datei):"
+msgstr "Der oben erläuterte jboss.ha:service=HASingletonDeployer-Dienst ist selbst ein interessantes Beispiel für die Anwendung eines HASingletonControllers. Nachfolgend sehen Sie seinen Deployment-Deskriptor (Auszug aus der <literal>deploy/deploy-hasingleton-service.xml</literal>-Datei):"
 
 #. Tag: programlisting
 #: Clustering_Guide_Clustered_Singleton_Services.xml:75
@@ -365,13 +370,13 @@
 "singleton service's start/stop methods can take an argument, in this case "
 "the location of the directory the <literal>MainDeployer</literal> should "
 "deploy/undeploy."
-msgstr "Einige interessante Punkte hier. Erstens handelt es sich bei dem kontrollierten Dienst um den <literal>MainDeployer</literal>-Dienst – der Haupt-Deployment-Dienst in JBoss. Das heißt, dies ist ein Dienst, der nicht in der Absicht geschrieben wurde, ihn von einem <literal>HASingletonController</literal> kontrollieren zu lassen. Und dennoch funktioniert es! Zweitens, die Ziel-Start- und Ziel-Stopmethoden lauten “deploy” und “undeploy”. Keine Anforderung bezüglich bestimmter Namen, oder auch nur dass sie logisch “start” und “stop” Funktionalitäten besitzen. Hier ist die Funktionalität der aufgerufenen Methoden eher “do” und “undo”. Zuguterletzt beachten Sie die “<literal>TargetStart(Stop)MethodArgument</literal>”-Attribute. Die start/stop-Methoden Ihres Singleton-Dienstes können ein Argument übernehmen, in diesem Fall der Speicherort des Verzeichnissses, das der <literal>MainDeployer</literal> deployen/un-deployen soll."
+msgstr "Einige interessante Punkte hierbei. Erstens handelt es sich bei dem kontrollierten Dienst um den <literal>MainDeployer</literal>-Dienst – der Haupt-Deployment-Dienst in JBoss. Das heißt, es handelt sich um einen Dienst, der nicht mit der Absicht geschrieben wurde, ihn von einem <literal>HASingletonController</literal> kontrollieren zu lassen. Und dennoch funktioniert es! Zweitens, die Ziel-Start- und Ziel-Stop-Methoden lauten “deploy” und “undeploy”. Es gibt keine Anforderungen bezüglich bestimmter Namen, oder auch nur dass sie logisch “start”- und “stop”-Funktionalitäten besitzen. Hier ist die Funktionalität der aufgerufenen Methoden eher “do” und “undo”. Zuguterletzt, beachten Sie die “<literal>TargetStart(Stop)MethodArgument</literal>”-Attribute. Die start/stop-Methoden Ihres Singleton-Dienstes können ein Argument übernehmen, in diesem Fall der Speicherort des Verzeichnissses, für das der <literal>MainDeployer</literal> Deploy!
 ment/Undeployment durchführen soll."
 
 #. Tag: title
 #: Clustering_Guide_Clustered_Singleton_Services.xml:85
 #, no-c-format
 msgid "HASingleton deployments using a Barrier"
-msgstr "HASingleton Deployments unter Verwendung von \"Barriers\""
+msgstr "HASingleton-Deployments unter Verwendung von \"Barriers\""
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:86
@@ -381,7 +386,7 @@
 "stopped whenever the content of deploy-hasingleton gets deployed/undeployed, "
 "(i.e., whenever the current node becomes the master), need only specify a "
 "dependency on the Barrier mbean:"
-msgstr "Ganz normal innerhalb von deploy oder farm deployte Dienste, die gestartet/gestoppt werden wollen, sobald der Inhalt von deploy-hasingleton deployt/un-deployt wird (d. h. jedesmal wenn der aktuelle Node zum Master wird), brauchen nur eine Abhängigkeit auf dem Barrier-MBean festlegen:"
+msgstr "Dienste, die ganz normal innerhalb von deploy oder farm ausgeführt werden, und die gestartet/gestoppt werden wollen, sobald der Inhalt von deploy-hasingleton deployt/undeployt wird (d. h. jedesmal wenn der aktuelle Node zum Master wird), brauchen nur eine Abhängigkeit zum Barrier-MBean festzulegen:"
 
 #. Tag: programlisting
 #: Clustering_Guide_Clustered_Singleton_Services.xml:88
@@ -409,7 +414,7 @@
 "Barrier MBean using the usual &lt;depends&gt; tag, and they will be started "
 "and stopped in tandem with the Barrier. When the BarrierController is "
 "undeployed the Barrier is destroyed too."
-msgstr "Und so funktioniert es: ein BarrierController wird deployt zusammen mit dem jboss.ha:service=HASingletonDeployer-MBean, und lauscht auf JMX-Benachrichtigungen von dort. Ein BarrierController ist ein vergleichsweise simples MBean, das sich zum Empfang jeglicher JMX-Benachrichtigungen im System anmelden kann. Es verwendet die empfangenen Benachrichtigungen, um den Lebenszyklus eines dynamisch erstellten MBean namens \"Barrier\" zu kontrollieren. Der Barrier wird instanziert, registriert, und auf den CREATE-Zustand gebracht, wenn der BarrierController deployt wird. Anschließend startet und stoppt der BarrierController den Barrier, wenn entsprechende JMX-Benachrichtigungen empfangen werden. Demzufolge brauchen andere Dienste nur vom Barrier-MBean abzuhängen, mittels des üblichen &lt;depends&gt;-Tags, und sie werden zusammen mit dem Barrier gestartet und gestoppt. Wird der BarrierController un-deployt, so wird der Barrier ebenfalls entfernt."
+msgstr "Und so funktioniert es: Ein BarrierController wird deployt zusammen mit dem jboss.ha:service=HASingletonDeployer-MBean, und lauscht auf JMX-Benachrichtigungen von dort. Ein BarrierController ist ein vergleichsweise simples MBean, das sich für den Empfang jeglicher JMX-Benachrichtigungen im System anmelden kann. Es verwendet die empfangenen Benachrichtigungen, um den Lebenszyklus eines dynamisch erstellten MBean namens \"Barrier\" zu kontrollieren. Der Barrier wird instanziert, registriert, und auf den CREATE-Zustand gebracht, wenn der BarrierController ausgeführt wird. Anschließend startet und stoppt der BarrierController den Barrier, wenn entsprechende JMX-Benachrichtigungen empfangen werden. Demzufolge brauchen andere Dienste nur vom Barrier-MBean abzuhängen, mittels der üblichen &lt;depends&gt;-Tags, und sie werden zusammen mit dem Barrier gestartet und gestoppt. Wird der BarrierController undeployt, so wird der Barrier ebenfalls entfernt."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:94
@@ -418,7 +423,7 @@
 "This provides an alternative to the deploy-hasingleton approach in that we "
 "can use farming to distribute the service, while content in deploy-"
 "hasingleton must be copied manually on all nodes."
-msgstr "Dies stellt insofern eine Alternative dar zum deploy-hasingleton-Verfahren, als wir nun Farming zum Verteilen des Dienstes nutzen können, während Inhalte in deploy-hasingleton manuell auf alle Nodes kopiert werden muss."
+msgstr "Dies stellt insofern eine Alternative zum deploy-hasingleton-Verfahren dar, als wir nun Farming zum Verteilen des Dienstes nutzen können, während Inhalte in deploy-hasingleton manuell auf alle Nodes kopiert werden müssen."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:97
@@ -429,7 +434,7 @@
 "on the master node. This is different with the deploy-hasingleton approach "
 "that will only deploy (instantiate/create/start) the contents of the deploy-"
 "hasingleton directory on one of the nodes."
-msgstr "Andererseits wird der Barrier-abhängige Dienst zwar auf allen Nodes instanziert/erstellt (d. h. alle create()-Methoden aufgerufen), aber nur auf dem Master Node gestartet. Dies unterscheidet sich vom deploy-hasingleton-Verfahren, bei dem die Inhalte des deploy-hasingleton-Verzeichnisses nur auf einem der Nodes deployt (instanziert/erstellt/gestartet) wird."
+msgstr "Andererseits wird der vom Barrier abhängige Dienst zwar auf allen Nodes instanziert/erstellt (d. h. alle create()-Methoden aufgerufen), aber nur auf dem Master Node gestartet. Dies unterscheidet sich vom deploy-hasingleton-Verfahren, bei dem die Inhalte des deploy-hasingleton-Verzeichnisses nur auf einem der Nodes deployt (instanziert/erstellt/gestartet) wird."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:101
@@ -438,13 +443,13 @@
 "So services depending on the barrier will need to make sure they do minimal "
 "or no work inside their create() step, rather they should use start() to do "
 "the work."
-msgstr "Dienste abhängig vom Barrier müssen also sicherstellen, kaum oder gar keine Arbeit innerhalb ihres create()-Schritts auszuführen, sondern sollten stattdessen start() verwenden, um Arbeit auszuführen."
+msgstr "Vom Barrier abhängige Dienste müssen also sicherstellen, kaum oder gar keine Arbeit innerhalb ihres create()-Schritts auszuführen, sondern sollten stattdessen start() verwenden, um Arbeit auszuführen."
 
 #. Tag: title
 #: Clustering_Guide_Clustered_Singleton_Services.xml:104
 #, no-c-format
 msgid "Note"
-msgstr "Anmerkungen"
+msgstr "Anmerkung"
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:105
@@ -456,7 +461,7 @@
 "literal> to control services that need to be \"destroyed\" as part of their "
 "normal “undeploy” operation (like, for example, an <literal>EJBContainer</"
 "literal>) will not have the desired effect."
-msgstr "Barrier kontrolliert den Start/Stopp von abhängigen Diensten, aber nicht deren Zerstörung, die nur erfolgt, wenn der <literal>BarrierController</literal> selbst zerstört/un-deployt wird. Daher wird die Verwendung von <literal>Barrier</literal> zum Kontrollieren von Diensten, die als Teil ihrer normalen \"un-deploy\"-Operation \"zerstört\" werden müssen (wie z. B. ein <literal>EJBContainer</literal>), nicht den gewünschten Effekt haben."
+msgstr "Der Barrier kontrolliert den Start/Stopp von abhängigen Diensten, aber nicht deren Zerstörung, die nur erfolgt, wenn der <literal>BarrierController</literal> selbst zerstört/undeployt wird. Daher wird die Verwendung von <literal>Barrier</literal> zum Kontrollieren von Diensten, die als Teil ihrer normalen Undeployment-Operation \"zerstört\" werden müssen (wie z. B. ein <literal>EJBContainer</literal>), nicht den gewünschten Effekt haben."
 
 #. Tag: title
 #: Clustering_Guide_Clustered_Singleton_Services.xml:114
@@ -472,7 +477,7 @@
 "that each node in the cluster can independently react to changes in cluster "
 "membership and correctly decide whether it is now the “master node”. How is "
 "this done?"
-msgstr "Die verschiedenen Verwaltungsstrategien für geclusterte Singletons sind alle angewiesen auf die Tatsache, dass jeder Node im Cluster unabhängig auf Änderungen in der Cluster-Mitgliedschaft reagieren und richtig entscheiden kann, ob er jetzt der \"Master Node\" ist. Doch wie funktioniert das?"
+msgstr "Die verschiedenen Verwaltungsstrategien für geclusterte Singletons sind alle darauf angewiesen, dass jeder Node im Cluster unabhängig auf Änderungen in der Cluster-Mitgliedschaft reagieren und richtig entscheiden kann, ob er jetzt der \"Master Node\" ist. Doch wie funktioniert das?"
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:118
@@ -487,7 +492,7 @@
 "CurrentView attribute in the <literal>jboss:service=DefaultPartition</"
 "literal> mbean. Every member of the cluster will have the same view, with "
 "the members in the same order."
-msgstr "Vor JBoss AS 4.2.0 war die Methodik hierfür klar und einfach. Für jedes Mitglied im Cluster bewahrt das HAPartition-MBean ein Attribut namens CurrentView, welches im Wesentlichen eine geordnete Liste der aktuellen Mitglieder im Cluster ist. Wenn Nodes dem Cluster beitreten oder aus ihm austreten stellt JGroups sicher, dass alle verbleibenden Mitglieder eine aktualisierte Ansicht erhalten. Sie können die aktuelle Ansicht einsehen, indem Sie in die JMX-Konsole gehen und sich das CurrentView-Attribut im <literal>jboss:service=DefaultPartition</literal>-MBean ansehen. Jedes Mitglied des Clusters wird dieselbe Ansicht besitzen, mit denselben Mitgliedern, in derselben Reihenfolge."
+msgstr "Vor JBoss AS 4.2.0 war die Methodik hierfür klar und einfach. Für jedes Mitglied im Cluster bewahrt das HAPartition-MBean ein Attribut namens CurrentView, welches im Wesentlichen eine geordnete Liste der aktuellen Mitglieder im Cluster ist. Wenn Nodes dem Cluster beitreten oder aus ihm austreten, stellt JGroups sicher, dass alle verbleibenden Mitglieder eine aktualisierte Ansicht erhalten. Sie können die aktuelle Ansicht einsehen, indem Sie in die JMX-Konsole gehen und sich das CurrentView-Attribut im <literal>jboss:service=DefaultPartition</literal>-MBean ansehen. Jedes Mitglied des Clusters wird dieselbe Ansicht besitzen, mit denselben Mitgliedern, in derselben Reihenfolge."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:121
@@ -498,7 +503,7 @@
 "the order of nodes in the view will reflect the order in which they joined "
 "the cluster (although this is not always the case, and should not be assumed "
 "to be the case.)"
-msgstr "Nehmen wir beispielsweise an, wir haben einen Cluster bestehend aus vier Nodes, Nodes A bis D, und die aktuelle Ansicht kann als {A, B, C, D} angegeben werden. Im Allgemeinen spiegelt die Reihenfolge der Nodes in dieser Ansicht die Reihenfolge wider, in der sie dem Cluster beigetreten sind (dies ist jedoch nicht immer der Fall, und sollte nicht einfach angenommen werden)."
+msgstr "Nehmen wir beispielsweise an, wir haben einen Cluster bestehend aus vier Nodes, Nodes A bis D, und die aktuelle Ansicht kann als {A, B, C, D} angegeben werden. Im Allgemeinen spiegelt die Reihenfolge der Nodes in dieser Ansicht die Reihenfolge wider, in der sie dem Cluster beigetreten sind (dies ist jedoch nicht immer der Fall, und sollte nicht vorausgesetzt werden)."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:124
@@ -511,7 +516,7 @@
 "are deployed where, in view order. So, on every node in the cluster, the "
 "<literal>HAPartition</literal> service knows that the view with respect to "
 "the Foo service is {A, C, D} (no B)."
-msgstr "Um unser Beispiel auszuweiten, lassen Sie uns nun weiter annehmen, dass es einen Singleton-Dienst (d. h. einen <literal>HASingletonController</literal>) namens Foo gibt, der im gesamten Cluster deployt ist mit Ausnahme von B, aus welchem Grund auch immer. Der <literal>HAPartition</literal>-Dienst pflegt über den gesamten Cluster hinweg eine Registry, welche Dienste wo deployt sind, in der Reihenfolge ihres Auftretens. Auf jedem Node im Cluster weiß der <literal>HAPartition</literal>-Dienst also, dass die Ansicht im Hinblick auf den Foo-Dienst {A, C, D} lautet, ohne B."
+msgstr "Lassen Sie uns für unser Beispiel nun weiter annehmen, dass es einen Singleton-Dienst (d. h. einen <literal>HASingletonController</literal>) namens Foo gibt, der im gesamten Cluster deployt ist mit Ausnahme von B, aus welchem Grund auch immer. Der <literal>HAPartition</literal>-Dienst pflegt über den gesamten Cluster hinweg eine Registry, welche Dienste wo deployt sind, in der Reihenfolge ihres Auftretens. Auf jedem Node im Cluster weiß der <literal>HAPartition</literal>-Dienst also, dass die Ansicht im Hinblick auf den Foo-Dienst {A, C, D} lautet, ohne B."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:128

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_EJBs.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_EJBs.po	2009-03-02 05:52:08 UTC (rev 84913)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_EJBs.po	2009-03-02 07:06:37 UTC (rev 84914)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_EJBs\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-02-27 12:02+1000\n"
+"PO-Revision-Date: 2009-03-02 09:27+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -724,7 +724,7 @@
 "never return. For many client applications, this possibility is "
 "unacceptable. As a result, JBoss doesn't make the RetryInterceptor part of "
 "its default client interceptor stacks for clustered EJBs."
-msgstr "Der RetryInterceptor ist in vielen Fällen nützlich, hat jedoch den Nachteil, dass er solange weiter versucht, den HA-Proxy in JNDI zu finden, bis es ihm gelingt. Falls er dies aus irgendeinem Grund nicht kann, wird dieser Prozess möglicherweise endlos weitergeführt werden, weshalb der EJB-Aufruf, der den RetryInterceptor ausgelöst hat, nie zurückkehren würde. Für viele Client-Anwendungen wäre dies untragbar. Deshalb macht JBoss den RetryInterceptor nicht Teil seines Standard-Client-Interzeptorstapels für geclusterte EJBs."
+msgstr "Der RetryInterceptor ist in vielen Fällen nützlich, hat jedoch den Nachteil, dass er solange weiter versucht, den HA-Proxy in JNDI zu finden, bis es ihm gelingt. Falls er dies aus irgendeinem Grund nicht kann, wird dieser Prozess möglicherweise endlos weitergeführt werden, weshalb der EJB-Aufruf, der den RetryInterceptor ausgelöst hat, nie antworten würde. Für viele Client-Anwendungen wäre dies untragbar. Deshalb macht JBoss den RetryInterceptor nicht Teil seines Standard-Client-Interzeptorstapels für geclusterte EJBs."
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:156

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_HTTP.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_HTTP.po	2009-03-02 05:52:08 UTC (rev 84913)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_HTTP.po	2009-03-02 07:06:37 UTC (rev 84914)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_HTTP\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-02-27 16:30+1000\n"
+"PO-Revision-Date: 2009-03-02 14:08+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -708,7 +708,7 @@
 msgstr ""
 "Nun haben Sie eine voll funktionsfähige Apache+mod_jk "
 "Lastverteilungskonfiguration, die die Aufrufe der Servlet-Container Ihres "
-"Clusters verteilt und außerdem die \"Session Stickiness\" besorgt (d.h. "
+"Clusters verteilt und außerdem die \"Session Stickiness\" besorgt (d. h. "
 "Clients verwenden stets denselben Servlet-Container)."
 
 #. Tag: para
@@ -736,7 +736,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 "Die vorangegangenen Erläuterungen konzentrierten sich auf die Verwendung von mod_jk als Lastverteiler. Alle weiteren Erläuterungen bezüglich Clustering von HTTP-Diensten in JBoss AS sind anwendbar ganz unabhängig vom verwendeten Lastverteiler."
+msgstr "Die vorangegangenen Erläuterungen konzentrierten sich auf die Verwendung von mod_jk als Lastverteiler. Alle weiteren Erläuterungen bezüglich Clustering von HTTP-Diensten in JBoss AS sind unabhängig vom verwendeten Lastverteiler anwendbar."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:153
@@ -749,7 +749,7 @@
 "data is lost. A better and more reliable solution is to replicate session "
 "data across the nodes in the cluster. This way, the client can hit any "
 "server node and obtain the same session state."
-msgstr "In <xref linkend=\"clustering-http-nodes\"/> wurde erläutert, wie mittels so genannter \"Sticky Sessions\" ein Client stets an demselben Server-Node bearbeitet wird, um den Session-Status beizubehalten. \"Sticky Sessions\" allein sind jedoch keine ideale Lösung. Wenn ein Node ausfällt, gehen dessen komplette Session-Daten verloren. Eine bessere und vor allem zuverlässigere Lösung ist ist, die Session-Daten auf sämtlichen Nodes innerhalb des Clusters zu replizieren. Auf diese Weise erhält der Client an allen Server-Nodes denselben Session-Status."
+msgstr "In <xref linkend=\"clustering-http-nodes\"/> wurde erläutert, wie mittels so genannter \"Sticky Sessions\" ein Client stets an demselben Server-Node bearbeitet wird, um den Session-Status beizubehalten. \"Sticky Sessions\" allein sind jedoch keine ideale Lösung. Fällt ein Node aus, gehen dessen komplette Session-Daten verloren. Eine bessere und vor allem zuverlässigere Lösung besteht darin, die Session-Daten auf sämtlichen Nodes innerhalb des Clusters zu replizieren. Auf diese Weise erhält der Client an allen Server-Nodes denselben Session-Status."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:155
@@ -759,7 +759,7 @@
 "use of JBoss Cache to provide HTTP session replication services to the JBoss "
 "Tomcat cluster. This MBean is defined in the <literal>deploy/jboss-web-"
 "cluster.sar/META-INF/jboss-service.xml file</literal>."
-msgstr "Das <literal>jboss.cache:service=TomcatClusteringCache</literal>-MBean benutzt das JBoss Cache, um den HTTP-Session-Replikationsdienst für den HTTP-Lastverteiler in einem JBoss Tomcat Cluster zu liefern. Dieses MBean ist in der <literal>deploy/jboss-web-cluster.sar/META-INF/jboss-service.xml file</literal>-Datei definiert."
+msgstr "Das <literal>jboss.cache:service=TomcatClusteringCache</literal>-MBean benutzt JBoss Cache, um den HTTP-Session-Replikationsdienst für den HTTP-Lastverteiler in einem JBoss Tomcat-Cluster zu liefern. Dieses MBean ist in der <literal>deploy/jboss-web-cluster.sar/META-INF/jboss-service.xml file</literal>-Datei definiert."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:158
@@ -769,7 +769,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 "Vor AS 4.2.0 war die HTTP-Session Cache-Konfigurationsdatei die <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>-Datei. Vor AS 4.0.4 CR2 hieß die Datei <literal>deploy/tc5-cluster-service.xml</literal>."
+msgstr "Vor AS 4.2.0 war der Speicherort der HTTP-Session Cache-Konfigurationsdatei <literal>deploy/tc5-cluster.sar/META-INF/jboss-service.xml</literal>. Vor AS 4.0.4 CR2 hieß die Datei <literal>deploy/tc5-cluster-service.xml</literal>."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:160
@@ -865,7 +865,7 @@
 "in JBoss AS. This is because FIELD granularity HTTP session replication "
 "(covered below) needs the added features of the <literal>TreeCacheAop</"
 "literal> (a.k.a. <literal>PojoCache</literal>) class."
-msgstr "Beachten Sie, dass der Wert des Attributs des mbean-Element-Codes org.jboss.cache.aop.TreeCacheAop lautet, sich also von den anderen in JBoss AS verwendeten JBoss Cacht-MBeans unterscheidet. Der Grund hierfür ist, dass HTTP-Sessionreplikation mit FIELD-Granularität (weiter unten erläutert) die zusätzlichen Features der <literal>TreeCacheAop</literal> (d. h. <literal>PojoCache</literal>)-Klasse benötigt."
+msgstr "Beachten Sie, dass der Attributwert des mbean-Element-Codes org.jboss.cache.aop.TreeCacheAop lautet, sich darin also von den anderen in JBoss AS verwendeten JBoss Cache-MBeans unterscheidet. Der Grund hierfür ist, dass HTTP-Session-Replikation mit FIELD-Granularität (weiter unten erläutert) die zusätzlichen Features der <literal>TreeCacheAop</literal> (d. h. <literal>PojoCache</literal>)-Klasse benötigt."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:168
@@ -893,7 +893,7 @@
 "Factory des Transaktionsmanagers fest. Die Standardeinstellung lautet hier "
 "<literal>org.jboss.cache.BatchModeTransactionManagerLookup</literal>. Dem "
 "Cache wird darin mitgeteilt, NICHT an JTA-spezifischen Transaktionen "
-"teilzunehmen. Statt dessen steuert der Cache seinen eigenen Transaktionen. Verändern Sie dies bitte nicht."
+"teilzunehmen. Stattdessen verwaltet der Cache seine eigenen Transaktionen. Verändern Sie dies bitte nicht."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:178
@@ -911,7 +911,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> steuert die Art und Weise, wie der Cache repliziert wird. Die gültigen Werte lauten <literal>REPL_SYNC</literal> und <literal>REPL_ASYNC</literal>. Bei beiden Einstellungen aktualisiert der Anfrage-Thread des Clients den lokalen Cache mit den aktuellen Session-Inhalten, und sendet danach eine Nachricht an die Caches der anderen Cluster-Mitglieder in der er sie auffordert, dieselben Änderungen durchzuführen. Mit REPL_ASYNC (Standard) kehrt der Anfrage-Thread zurück, sobald die Aktualisierungsnachricht ins Netzwerk gestellt wurde. Mit REPL_SYNC blockiert der Anfrage-Thread, bis er eine Antwortnachricht von allen Cluster-Mitgliedern erhält, in denen er über die erfolgreiche Aktualisierung informiert wird. Die Verwendung von synchroner Replikation gewährleistet, dass Änderungen im ganzen Cluster durchgeführt werden, bevor die Web-Anfrage abschließt. Allerdings ist die synchrone Replikation deutlich langsamer."
+msgstr "<emphasis role=\"bold\">CacheMode</emphasis> steuert die Art und Weise, wie der Cache repliziert wird. Die gültigen Werte lauten <literal>REPL_SYNC</literal> und <literal>REPL_ASYNC</literal>. Mit beiden Einstellungen aktualisiert der Anfrage-Thread des Clients den lokalen Cache mit den aktuellen Session-Inhalten, sendet anschließend eine Nachricht an die Caches auf anderen Cluster-Mitgliedern und fordert sie darin auf, dieselbe Änderung durchzuführen. Mit REPL_ASYNC (Standard) antwortet der Anfrage-Thread, sobald die Aktualisierungsnachricht ins Netzwerk gestellt wurde. Mit REPL_SYNC blockiert der Anfrage-Thread, bis er eine Antwortnachricht von allen Cluster-Mitgliedern erhält, in denen er über die erfolgreiche Aktualisierung informiert wird. Die Verwendung von synchroner Replikation gewährleistet, dass Änderungen im ganzen Cluster durchgeführt werden, bevor die Web-Anfrage abschließt. Allerdings ist die synchrone Replikation deutlich langsamer."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:182
@@ -922,7 +922,7 @@
 "word \"Tomcat-\" appended by the current JBoss partition name. All the nodes "
 "must use the same cluster name."
 msgstr ""
-"<emphasis role=\"bold\">ClusterName</emphasis> bestimmt den Cluster-Namen in "
+"<emphasis role=\"bold\">ClusterName</emphasis> bestimmt den Cluster-Namen, in "
 "dem der Cache arbeitet. Der Standard-Cluster-Name ist das Wort \"Tomcat-\" "
 "gefolgt vom aktuellen JBoss-Partitionsnamen. Alle Nodes sollten denselben "
 "Cluster-Namen verwenden."
@@ -952,7 +952,7 @@
 "more information."
 msgstr ""
 "<emphasis role=\"bold\">ClusterConfig</emphasis> enthält die Konfiguration "
-"des zugrunde liegenden JGroups Stacks. Für weitere Informationen werfen Sie bitte einen Blick auf <xref linkend=\"jbosscache-jgroups\"/>."
+"des zugrunde liegenden JGroups Stapels. Für weitere Informationen werfen Sie bitte einen Blick auf <xref linkend=\"jbosscache-jgroups\"/>."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:195
@@ -1067,7 +1067,7 @@
 "literal> and in need of replication). It has 4 options:"
 msgstr ""
 "Das <literal>replication-trigger</literal>-Element bestimmt, wodurch eine "
-"Session-Replikation ausgelöst wird (d. h. wann eine Session als <literal>dirty</literal> gilt und Replikation benötigt). Es besitzt 4 Optionen:"
+"Session-Replikation ausgelöst wird (d. h. wann eine Session als <literal>dirty</literal> gilt und Replikation benötigt). Es gibt 4 Optionen:"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:218
@@ -1083,7 +1083,7 @@
 "that object may not be replicated."
 msgstr ""
 "<emphasis role=\"bold\">SET</emphasis>: Mit dieser Richtlinie gilt eine "
-"Session nur als \"dirty\", wenn ein Attribut in der Session festgelegt ist (d. h. HttpSession.setAttribute() wird aufgerufen). Falls Ihre Anwendung immer den veränderten Wert in der Session festhält, ist dieses hinsichtlich der Performance die wohl beste Option. Der Nachteil von SET besteht darin, dass wenn ein Objekt von einer Session abgerufen und modifiziert wird ohne der Session wieder hinzugefügt zu werden, so wird der Session-Manager nicht wissen können, dass das Attribut \"dirty\" ist, und Änderung an diesem Objekt werden ggf. nicht repliziert."
+"Session nur als \"dirty\", wenn ein Attribut in der Session festgelegt ist (d. h. HttpSession.setAttribute() ist aufgerufen). Falls Ihre Anwendung immer den veränderten Wert in der Session festhält, ist dieses hinsichtlich der Performance die wohl beste Option. Der Nachteil von SET besteht darin, dass wenn ein Objekt von einer Session abgerufen und modifiziert wird ohne der Session wieder hinzugefügt zu werden, so wird der Session-Manager nicht wissen können, dass das Attribut \"dirty\" ist, und Änderung an diesem Objekt werden ggf. nicht repliziert."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:221
@@ -1096,7 +1096,7 @@
 "SET_AND_GET is that it can have significant performance implications, since "
 "even reading immutable objects from the session (e.g., strings, numbers) "
 "will mark the read attributes as needing to be replicated."
-msgstr "<emphasis role=\"bold\">SET_AND_GET</emphasis>: Bei dieser Richtlinie wird jedes Attribut das geladen oder eingestellt wird als \"dirty\" gekennzeichnet. Falls ein Objekt der Session aufgerufen und verändert wird, ohne dass es in die Session zurückgeschrieben wird, so wird die Änderung an diesem Objekt repliziert. Der Nachteil von SET_AND_GET besteht darin, dass es die Performance stark beeinflussen kann, denn selbst das Auslesen von unveränderlichen Objekten aus der Session (z. B. Strings, Zahlen) wird die gelesenen Attribute als replikationsbedürftig kennzeichnen."
+msgstr "<emphasis role=\"bold\">SET_AND_GET</emphasis>: Bei dieser Richtlinie wird jedes Attribut, das geladen oder eingestellt wird, als \"dirty\" gekennzeichnet. Falls ein Objekt der Session aufgerufen und verändert wird, ohne dass es in die Session zurückgeschrieben wird, so wird die Änderung an diesem Objekt repliziert. Der Nachteil von SET_AND_GET besteht darin, dass es die Performance stark beeinflussen kann, denn selbst das Auslesen von unveränderlichen Objekten aus der Session (z. B. Strings, Zahlen) wird die gelesenen Attribute als replikationsbedürftig kennzeichnen."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:224
@@ -1112,7 +1112,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>: Diese Richtlinie ähnelt der SET_AND_GET-Richtlinie, außer dass GET-Operationen, die Attributwerte mit primitiven Typen zurückgeben, das Attribut nicht als \"dirty\" kennzeichnen. Primitive Systemtypen (z. B. String, Integer, Long, etc.) sind unveränderlich, daher besteht keine Grund, ein Attribut mit einem solchen Typ als \"dirty\" zu markieren, nur weil es gelesen wurde. Wenn eine GET-Operation einen Wert eines nicht-primitiven Typs zurückgibt, kann der Session-Manager nicht ohne Weiteres feststellen, ob das Objekt veränderlich ist. Er nimmt also an, das Objekt sei veränderlich, und kennzeichnet das Attribut als \"dirty\". Diese Konfiguration vermeidet den Nachteil von SET, während die Performance-Einbußen von SET_AND_GET reduziert werden. Dies ist die Standardeinstellung."
+msgstr "<emphasis role=\"bold\">SET_AND_NON_PRIMITIVE_GET</emphasis>: Diese Richtlinie ähnelt der SET_AND_GET-Richtlinie, abgesehen davon, dass GET-Operationen, die Attributwerte mit primitiven Typen wiedergeben, das Attribut nicht als \"dirty\" kennzeichnen. Primitive Systemtypen (z. B. String, Integer, Long, etc.) sind unveränderlich, daher besteht keine Grund, ein Attribut mit diesem Typ als \"dirty\" zu markieren, nur weil es gelesen wurde. Wenn eine GET-Operation einen Wert eines nicht primitiven Typs zurückgibt, kann der Session-Manager nicht ohne Weiteres feststellen, ob das Objekt veränderlich ist oder nicht. Er nimmt also an, das Objekt sei veränderlich und kennzeichnet das Attribut als \"dirty\". Diese Konfiguration vermeidet den Nachteil von SET, während die Performance-Einbußen von SET_AND_GET vermindert werden. Dies ist die Standardeinstellung."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:227
@@ -1133,7 +1133,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>: Bei dieser Option wird eine Session bei jedem Zugriff als \"dirty\" markiert. Da während jeder HTTP-Anfrage auf die Session zugegriffen wird, wird sie bei jeder Anfrage repliziert. Der Zweck von ACCESS ist es, sicherzustellen, dass die Zeitstempel (\"Time Stamp\") des letzten Zugriffs in der Session über den gesamten Cluster synchron gehalten werden. Da bei den anderen replikationsauslösenden Optionen der Zeitstempel möglicherweise nicht in anderen Clustering-Nodes aktualisiert wird, weil keine Replikation stattfindet, kann es sein, dass die Session in anderen Nodes vor dem aktiven Node abläuft, falls die HTTP-Anfrage keine Attribute der Session abfragt oder verändert. Wenn diese Option eingestellt ist, werden die Zeitstempel der Sessions über sämtliche Nodes des Clusters synchronisiert. Bitte beachten Sie, dass diese Option großen Einfluss auf die Performance haben kann, und verwenden Sie sie daher mit Vorsicht. W!
 enn bei den anderen replikationsauslösenden Optionen eine Session 80% ihres Ablaufintervalls durchschritten hat ohne repliziert zu werden, so wird in jedem Fall als Sicherheitsvorkehrung ihr Zeitstempel repliziert. Dadurch ist ACCESS nur unter besonderen Umständen nützlich, in denen diese Sicherheitsvorkehrung unzureichend ist."
+msgstr "<emphasis role=\"bold\">ACCESS</emphasis>: Bei dieser Option wird eine Session bei jedem Zugriff als \"dirty\" markiert. Da während jeder HTTP-Anfrage auf die Session zugegriffen wird, wird sie bei jeder Anfrage repliziert. Der Zweck von ACCESS ist es, sicherzustellen, dass die Zeitstempel (\"Timestamps\") des letzten Zugriffs in der Session über den gesamten Cluster synchron gehalten werden. Da bei den anderen replikationsauslösenden Optionen der Zeitstempel möglicherweise nicht in anderen Clustering-Nodes aktualisiert wird, weil keine Replikation stattfindet, kann es sein, dass die Session in anderen Nodes vor dem aktiven Node abläuft, falls die HTTP-Anfrage keine Attribute der Session abfragt oder verändert. Wenn diese Option eingestellt ist, werden die Zeitstempel der Sessions über sämtliche Nodes des Clusters synchronisiert. Bitte beachten Sie, dass diese Option großen Einfluss auf die Performance haben kann, und verwenden Sie sie daher mit Vorsicht. W!
 enn eine Session bei den anderen replikationsauslösenden Optionen 80% ihres Ablaufintervalls durchschritten hat, ohne repliziert zu werden, so wird in jedem Fall als Sicherheitsvorkehrung ihr Zeitstempel repliziert. Dadurch ist ACCESS nur unter besonderen Umständen nützlich, in denen diese Sicherheitsvorkehrung unzureichend ist."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:230
@@ -1162,7 +1162,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>: Replikation gilt nur für \"dirty\" Attribute in der Session sowie manche Session-Daten, wie der Zeitstempel des letzten Zugriffs. Für Sessions, die große Mengen an Daten mitführen, kann diese Option die Replikations-Performance verbessern. Attribute werden jedoch separat serialisiert, wenn also eine gemeinsame Referenz zwischen in den Attributen gespeicherten Objekten existiert, so wird diese gemeinsame Referenz auf entfernten Nodes ggf. zerstört. Nehmen wir beispielsweise an, ein Personenobjekt gespeichert unter dem Schlüssel \"Ehemann\" hat eine Referenz zu einer Adresse, während ein anderes Personenobjekt gespeichert unter dem Schlüssel \"Ehefrau\" eine Referenz zu demselben Adressobjekt besitzt. Wenn nun die \"Ehemann\"- und \"Ehefrau\"-Attribute auf den entfernten Nodes separat deserialisiert werden, hat jedes Personenobjekt dann eine Referenz zu seinem eigenen Adressobjekt; das Adressobjekt wird nicht läng!
 er gemeinsam verwendet."
+msgstr "<emphasis role=\"bold\">ATTRIBUTE</emphasis>: Replikation wird nur durchgeführt für \"dirty\" Attribute in der Session sowie manche Session-Daten, wie der Zeitstempel des letzten Zugriffs. Für Sessions, die große Mengen an Daten enthalten, kann diese Option die Replikations-Performance verbessern. Attribute werden jedoch separat serialisiert, wenn also eine gemeinsame Referenz zwischen Objekten existiert, die in den Attributen gespeicherten sind, so wird diese gemeinsame Referenz auf Remote-Nodes ggf. zerstört. Nehmen wir beispielsweise an, ein Personenobjekt, gespeichert unter dem Schlüssel \"Ehemann\", hat eine Referenz zu einer Adresse, während ein anderes Personenobjekt, gespeichert unter dem Schlüssel \"Ehefrau\", eine Referenz zu demselben Adressobjekt besitzt. Wenn nun die \"Ehemann\"- und \"Ehefrau\"-Attribute auf den Remote-Nodes separat deserialisiert werden, besitzt danach jedes Personenobjekt eine Referenz zu seinem eigenen Adressobjekt; das Adre!
 ssobjekt wird nicht länger geteilt."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:238
@@ -1172,7 +1172,7 @@
 "replicated if any attribute is dirty. The entire session is serialized in "
 "one unit, so shared object references are maintained on remote nodes. This "
 "is the default setting."
-msgstr "<emphasis role=\"bold\">SESSION</emphasis>: Das ganze Session-Objekt wird repliziert, wenn eines der Attribute \"dirty\" ist. Die gesamte Session wird als eine Einheit serialisiert, so dass gemeinsam verwendete Referenzen auf entfernten Nodes erhalten bleiben. Dies ist die Standardeinstellung."
+msgstr "<emphasis role=\"bold\">SESSION</emphasis>: Das ganze Session-Objekt wird repliziert, wenn eines der Attribute \"dirty\" ist. Die gesamte Session wird als eine Einheit serialisiert, so dass gemeinsam verwendete Referenzen auf Remote-Nodes erhalten bleiben. Dies ist die Standardeinstellung."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:243
@@ -1183,7 +1183,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>: Replikation wird nur für einzelne, veränderte Datenfelder innerhalb von Session-Attributobjekten angewendet. Gemeinsam verwendete Referenzen werden über den gesamten Cluster beibehalten. Dies ist potenziell am leistungsstärksten, erfordert jedoch Änderungen an Ihrer Applikation (dies wird später erläutert)."
+msgstr "<emphasis role=\"bold\">FIELD</emphasis>: Replikation wird nur für einzelne, veränderte Datenfelder innerhalb von Session-Attributobjekten durchgeführt. Gemeinsam verwendete Referenzen werden über den gesamten Cluster beibehalten. Dies ist hinsichtlich der Performance potenziell die beste Option, erfordert jedoch Änderungen an Ihrer Applikation (dies wird später erläutert)."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:246
@@ -1193,7 +1193,7 @@
 "whether you want all replication messages associated with a request to be "
 "batched into one message. Only applicable if replication-granularity is "
 "FIELD. Default is <literal>true</literal>."
-msgstr "Das <literal>replication-field-batch-mode</literal>-Element zeigt an, ob Sie alle mit einer Anfrage assoziierten Nachrichten in eine Nachricht stapeln möchten. Gilt nur, wenn die Replikationsgranularität FIELD ist. Der voreingestellte Wert lautet <literal>true</literal>."
+msgstr "Das <literal>replication-field-batch-mode</literal>-Element zeigt an, ob Sie alle mit einer Anfrage assoziierten Replikationsnachrichten in eine Nachricht stapeln möchten. Gilt nur, wenn die Replikationsgranularität FIELD ist. Der voreingestellte Wert lautet <literal>true</literal>."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:247
@@ -1234,7 +1234,7 @@
 "Die Replikation auf FIELD-Ebene repliziert nur veränderte Datenfelder "
 "innerhalb von Objekten, die in der Session gespeichert werden. Dies könnte "
 "möglicherweise den Datenverkehr zwischen den geclusterten Nodes drastisch "
-"senken und somit die Leistung des Gesamtclusters verbessern. Um die Replikation auf FIELD-Ebene zu verwenden, müssen Sie zunächst einmal Ihre Java-Klasse vorbereiten (d. h. Bytecode steigern), so dass der Session-Cache erkennen kann, wenn Felder in gecachten Objekten verändert wurden und repliziert werden müssen."
+"senken und somit die Leistung des Gesamt-Clusters verbessern. Um die Replikation auf FIELD-Ebene zu verwenden, müssen Sie zunächst einmal Ihre Java-Klasse vorbereiten (d. h. den Bytecode anreichern, sog \"Bytecode Enhancement\"), so dass der Session-Cache erkennen kann, wenn Felder in gecachten Objekten verändert wurden und repliziert werden müssen. "
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:262
@@ -1242,7 +1242,7 @@
 msgid ""
 "The first step in doing this is to identify the classes that need to be "
 "prepared. This is done via annotations. For example:"
-msgstr "Der erste Schritt hierzu besteht darin, die Klasse zu identifizieren, die vorbereitet werden muss. Dies erfolgt via Annotationen. Zum Beispiel:"
+msgstr "Der erste Schritt hierzu besteht darin, die Klassen zu identifizieren, die vorbereitet werden müssen. Dies geschieht mittels Annotationen. Zum Beispiel:"
 
 #. Tag: programlisting
 #: Clustering_Guide_HTTP.xml:266
@@ -1313,7 +1313,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 "Es ist nicht nötig, <literal>Student</literal> zu annotieren. Es wird automatisch annotiert, da es sich um eine Unterklasse von <literal>Person</literal> handelt. Jboss AS 4.2 benötigt JDK 5 zur Laufzeit, aber einige Benutzer müssen ggf. ihre Projekte noch mit JDK 1.4 bauen. In diesem Fall kann das Annotieren von Klassen mittels JDK 1.4 Style-Annotationen eingebettet in JavaDocs durchgeführt werden. Zum Beispiel:"
+msgstr "Es ist nicht nötig, <literal>Student</literal> zu annotieren. Es wird automatisch annotiert, da es sich um eine Unterklasse von <literal>Person</literal> handelt. Jboss AS 4.2 benötigt JDK 5 während der Laufzeit, aber einige Benutzer müssen ggf. ihre Projekte noch mit JDK 1.4 bauen. In diesem Fall kann das Annotieren von Klassen mittels Annotationen im JDK 1.4 Stil durchgeführt werden, die in JavaDocs eingebettet sind. Zum Beispiel:"
 
 #. Tag: programlisting
 #: Clustering_Guide_HTTP.xml:278
@@ -1377,9 +1377,7 @@
 "step is only need if the JDK 1.4 style annotations are used; if JDK 5 "
 "annotations are used it is not necessary. Here is an example on how to "
 "invoke those commands from command line."
-msgstr ""
-"Sobald Sie Ihre Klassen annotiert haben, werden Sie einen vorbereitenden Schritt durchführen müssen, um für Ihre Klassen Bytecode-Steigerung durchzuführen für die Verwendung durch TreeCacheAop. Sie werden den JBoss AOP Pre-Compiler (Vorkompilierer) <literal>annotationc</literal> und Post-Compiler (Nachkompilierer) "
-"<literal>aopc</literal> verwenden müssen, um den Quellcode oben vor und nach der Kompilierung durch den Java-Compiler zu bearbeiten. Der \"annotationc\"-Schritt ist nur bei Verwendung von JDK 1.4 Style-Annotationen nötig, wenn JDK 5 Annotationen verwendet werden, ist er unnötig. Nachfolgend sehen Sie ein Beispiel dafür, wie Sie diese Befehle von der Befehlszeile aufrufen."
+msgstr "Nachdem Sie Ihre Klassen annotiert haben, werden Sie einen vorbereitenden Schritt ausführen müssen, in dem Sie für Ihre Klassen Bytecode-Anreicherung durchführen für die Verwendung durch TreeCacheAop. Sie werden den JBoss AOP Pre-Compiler <literal>annotationc</literal> und Post-Compiler <literal>aopc</literal> verwenden müssen, um den Quellcode oben vor und nach der Kompilierung durch den Java-Compiler zu bearbeiten. Der \"annotationc\"-Schritt ist nur nötig bei Verwendung von Annotationen im JDK 1.4 Stil, wenn JDK 5 Annotationen verwendet werden, ist er nicht nötig. Nachfolgend sehen Sie ein Beispiel dafür, wie Sie diese Befehle von der Befehlszeile aufrufen."
 
 #. Tag: programlisting
 #: Clustering_Guide_HTTP.xml:291
@@ -1401,9 +1399,7 @@
 "compiler. The JBoss AOP project also provides easy to use ANT tasks to help "
 "integrate those steps into your application build process."
 msgstr ""
-"Bitte konsultieren Sie die JBoss AOP-Dokumentation zum Gebrauch des Vor- und "
-"Nachkompilierers. Das JBoss AOP-Projekt bietet auch einfach zu benutzende "
-"ANT-Tasks, die Ihnen bei der Integration dieser Schritte beim Aufbauvorgang "
+"Bitte konsultieren Sie die JBoss AOP-Dokumentation zum Gebrauch des Pre- und Post-Compilers. Das JBoss AOP-Projekt bietet auch einfach zu benutzende ANT-Tasks, die Ihnen bei der Integration dieser Schritte beim Aufbauvorgang "
 "Ihrer Anwendung helfen."
 
 #. Tag: para
@@ -1461,12 +1457,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 ""
-"Im folgenden wird nun noch die Replikation auf FIELD-Ebene an diesen "
-"Datenklassen erläutert. Bitte beachten Sie, dass es nicht nötig ist "
-"<literal>session.setAttribute()</literal> aufzurufen, nachdem Sie die "
-"Änderungen am Datenobjekt vorgenommen haben und dass sämtliche Änderungen in "
-"den Feldern automatisch über den Cluster hinweg repliziert werden."
+msgstr "Zum Abschluss sehen wir nun noch ein Beispiel für die Replikation auf FIELD-Ebene an diesen Datenklassen. Bitte beachten Sie, dass es nicht nötig ist <literal>session.setAttribute()</literal> aufzurufen, nachdem Sie die Änderungen am Datenobjekt vorgenommen haben und dass sämtliche Änderungen in den Feldern automatisch über den Cluster hinweg repliziert werden."
 
 #. Tag: programlisting
 #: Clustering_Guide_HTTP.xml:318
@@ -1595,7 +1586,7 @@
 "session. The <literal>org.jboss.cache</literal> and <literal>org.jboss.web</"
 "literal> logging categories provide additional insight into session "
 "replication useful for debugging purposes."
-msgstr "Diese Ausgabe zeigt zwei separate Web-Sessions, die mittels JBossCache geteilt werden und von denen eine den Namen <emphasis>quote</emphasis> trägt. Das Beispiel verwendet eine <literal>replication-granularity</literal> von <literal>session</literal>. Wäre eine Replikation auf <literal>attribute</literal> Ebene verwendet werden, so wären weitere Eintragungen zu den einzelnen replizierten Session-Attributen vorhanden. In jedem Falle werden die replizierten Werte in einem nicht einsehbaren <literal>MarshelledValue</literal>-Container gespeichert. Es gibt derzeit keine Tools, mit denen Sie die Inhalte der replizierten Sessionwerte einsehen könnten. Falls Sie keine Ausgabe sehen, war die Anwendung entweder nicht ordnungsgemäß als <literal>distributable</literal> gekennzeichnet oder Sie haben keinen Teil der Anwendung aufgerufen, der Werte in der HTTP-Session ablegt. Die <literal>org.jboss.cache</literal> und <literal>org.jboss.web</literal>-Protokollkategorien bie!
 ten zusätzlichen Einblick in die Replikation der Session, was inbesondere bei der Fehlersuche und -beseitigung hilfreich sein kann."
+msgstr "Diese Ausgabe zeigt zwei separate Web-Sessions, in einer Anwendung namens <emphasis>quote</emphasis>, die mittels JBossCache geteilt werden. Das Beispiel verwendet eine <literal>replication-granularity</literal> von <literal>session</literal>. Wäre eine Replikation auf <literal>attribute</literal>-Ebene verwendet werden, so wären weitere Eintragungen zu den einzelnen replizierten Session-Attributen vorhanden. In jedem Falle werden die replizierten Werte in einem nicht einsehbaren <literal>MarshelledValue</literal>-Container gespeichert. Es gibt derzeit keine Tools, mit denen Sie die Inhalte der replizierten Session-Werte einsehen könnten. Falls Sie keine Ausgabe sehen, war die Anwendung entweder nicht ordnungsgemäß als <literal>distributable</literal> gekennzeichnet oder Sie haben keinen Teil der Anwendung aufgerufen, der Werte in der HTTP-Session ablegt. Die <literal>org.jboss.cache</literal> und <literal>org.jboss.web</literal>-Protokollkategorien bieten zusÃ!
 ¤tzlichen Einblick in die Replikation der Session, was inbesondere bei der Fehlersuche und -beseitigung hilfreich sein kann."
 
 #. Tag: title
 #: Clustering_Guide_HTTP.xml:338
@@ -1615,7 +1606,7 @@
 "service. Although session replication does not need to be explicitly enabled "
 "for the applications in question, the <literal>jboss-web-cluster.sar</"
 "literal> file needs to be deployed."
-msgstr "JBoss unterstützt den geclusterten \"Single Sign On\" (einmalige Anmeldung), bei der ein Benutzer sich bei einer Web-Anwendung des JBoss Servers authentifiziert und dann von sämtlichen Web-Anwendungen des Geräts oder eines anderen Nodes im Cluster, die innerhalb desselben virtuellen Hosts ausgeführt werden, erkannt wird. Die Authentifizierungsreplikation erfolgt durch dasselbe JBoss Cache-MBean, das auch für den HTTP-Session-Replikationsdienst verwendet wird. Obwohl die Session-Replikation für die betreffenden Anwendungen nicht explizit aktiviert sein muss, muss die <literal>jboss-web-cluster.sar</literal>-Datei nicht ausgeführt werden."
+msgstr "JBoss unterstützt den geclusterten \"Single Sign On\" (einmalige Anmeldung), bei der ein Benutzer sich bei einer Web-Anwendung des JBoss Servers authentifiziert und dann von sämtlichen Web-Anwendungen des Geräts oder eines anderen Nodes im Cluster, die innerhalb desselben virtuellen Hosts ausgeführt werden, erkannt wird. Die Authentifizierungsreplikation erfolgt durch dasselbe JBoss Cache-MBean, das auch für den HTTP-Session-Replikationsdienst verwendet wird. Obwohl die Session-Replikation für die betreffenden Anwendungen nicht explizit aktiviert sein muss, muss die <literal>jboss-web-cluster.sar</literal>-Datei deployt werden."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:342
@@ -1645,7 +1636,7 @@
 #: Clustering_Guide_HTTP.xml:348
 #, no-c-format
 msgid "Clustered Session Notification Policy"
-msgstr "Richtlinie zur Benachrichtigung von geclusterten Sessions"
+msgstr "Richtlinie für geclusterte Session-Benachrichtigung"
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:349
@@ -1658,7 +1649,7 @@
 "http.HttpSessionListener</package>, <package>javax.servlet.http."
 "HttpSessionAttributeListener</package>, and <package>javax.servlet.http."
 "HttpSessionBindingListener interfaces</package>."
-msgstr "Dieser Abschnitt stellt das Konzept der Richtlinie zur Benachrichtigung von geclusterten Sessions vor, zum Feststellen, ob die Servlet Spec Benachrichtigungen bezüglich Session-Ereignissen an den lokalen Cluster-Node gesendet werden dürfen. Diese Benachrichtigungen werden an Implementierungen der <package>javax.servlet.http.HttpSessionListener</package>, <package>javax.servlet.http.HttpSessionAttributeListener</package>, und <package>javax.servlet.http.HttpSessionBindingListener interfaces</package> gesendet."
+msgstr "Dieser Abschnitt stellt das Konzept der Richtlinie für geclusterte Session-Benachrichtigung vor, welche bestimmt, ob die Servlet-Spec-Benachrichtigungen hinsichtlich Session-Ereignissen an den lokalen Cluster-Node gesendet werden dürfen. Diese Benachrichtigungen werden an Implementierungen der <package>javax.servlet.http.HttpSessionListener</package>, <package>javax.servlet.http.HttpSessionAttributeListener</package>, und <package>javax.servlet.http.HttpSessionBindingListener interfaces</package> gesendet."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:352
@@ -1667,7 +1658,7 @@
 "This new notification policy concept is defined in the <package>org.jboss."
 "web.tomcat.service.session.notification</package> Java package, and all "
 "classes referenced below are a part of this package."
-msgstr "Diese neue Konzept der Benachrichtigungsrichtlinie ist im <package>org.jboss.web.tomcat.service.session.notification</package> Java-Paket definiert, und alle unten referenzierten Klassen sind Teil dieses Pakets."
+msgstr "Dieses neue Konzept der Benachrichtigungsrichtlinie ist im <package>org.jboss.web.tomcat.service.session.notification</package> Java-Paket definiert, und alle unten genannten Klassen sind Teil dieses Pakets."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:354
@@ -1682,7 +1673,7 @@
 "classname>, which implements the same behavior except for undeployment "
 "situations in which no <classname>HttpSessionListener</classname> and "
 "<classname>HttpSessionAttributeListener</classname> notifications are sent."
-msgstr "Obwohl es möglich ist, <classname>ClusteredSessionNotificationPolicy</classname> für fallspezifische Anpassungen zu implementieren, so bietet JBoss <classname>LegacyClusteredSessionNotificationPolicy</classname>, was die Verhaltensweisen in älteren JBoss Versionen implementiert (Standard), und <classname>IgnoreUndeployLegacyClusteredSessionNotificationPolicy</classname>, was dieselben Verhaltensweisen implementiert mit Ausnahme von Undeployment-Situationen, in denen keine <classname>HttpSessionListener</classname> und <classname>HttpSessionAttributeListener</classname>-Benachrichtigung gesendet wird."
+msgstr "Obwohl es möglich ist, <classname>ClusteredSessionNotificationPolicy</classname> für fallspezifische Anpassungen zu implementieren, bietet JBoss <classname>LegacyClusteredSessionNotificationPolicy</classname>, was die Verhaltensweisen in älteren JBoss Versionen implementiert (Standard), sowie <classname>IgnoreUndeployLegacyClusteredSessionNotificationPolicy</classname>, was dieselben Verhaltensweisen implementiert mit Ausnahme von Undeployment-Situationen, in denen keine <classname>HttpSessionListener</classname> und <classname>HttpSessionAttributeListener</classname>-Benachrichtigungen gesendet werden."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:357
@@ -1703,7 +1694,7 @@
 "and setting it equal to the class name of the policy you want to choose. "
 "This will change the policy for all web applications deployed in the "
 "application server."
-msgstr "Verwenden Sie die Systemeigenschaft 'jboss.web.clustered.session.notification.policy' und stellen sie ein gleich dem Klassennamen derjeninge Richtlinie, die Sie auswählen möchten. Dies wird die Richtlinie für alle im Anwendungsserver eingesetzten Web-Anwendungen ändern."
+msgstr "Verwenden Sie die Systemeigenschaft 'jboss.web.clustered.session.notification.policy' und setzen diese auf den Klassennamen derjeninge Richtlinie, die Sie auswählen möchten. Dies wird die Richtlinie für alle im Anwendungsserver eingesetzten Web-Anwendungen ändern."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:367
@@ -1739,5 +1730,5 @@
 "web_4_2.dtd</ulink>). However, the internal jboss-web.xml parsing logic will "
 "properly handle the element in JBoss AS 4.2.4 and later as well was in EAP "
 "4.2.0.GA_CP05 and 4.3.0.GA_CP03 and later."
-msgstr "Das oben gezeigte \"session-notification-policy\"-Element ist nicht Teil der offiziellen Dokumenttyp-Definition (DTD) für JBoss 4.2+ jboss-web.xml (siehe <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>). Nichtsdestotrotz wird die interne jboss-web.xml Parsing-Logik das Element ordnungsgemäß handhaben in JBoss AS 4.2.4 und höher, sowie in EAP 4.2.0.GA_CP05 und 4.3.0.GA_CP03 und höher."
+msgstr "Das oben gezeigte \"session-notification-policy\"-Element ist nicht Teil der offiziellen Dokumenttypdefinition (DTD) für JBoss 4.2+ jboss-web.xml (siehe <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>). Nichtsdestotrotz wird die interne jboss-web.xml Parsing-Logik das Element ordnungsgemäß bearbeiten in JBoss AS 4.2.4 und höher, sowie in EAP 4.2.0.GA_CP05 und 4.3.0.GA_CP03 und höher."
 

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po	2009-03-02 05:52:08 UTC (rev 84913)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po	2009-03-02 07:06:37 UTC (rev 84914)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_JMS\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-02-25 13:47+1000\n"
+"PO-Revision-Date: 2009-03-02 17:04+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -35,7 +35,7 @@
 "JBoss AS 3.2.4 und spätere Versionen unterstützen \"High Availability\"-JMS "
 "(HA-JMS) Dienste in der <literal>all</literal>-Serverkonfiguration. In der "
 "aktuellen Produktionsversion des JBoss AS ist der HA-JMS-Dienst als geclusterter "
-"Singleton Fail-Over-Dienst implementiert."
+"Singleton Failover-Dienst implementiert."
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:12
@@ -49,7 +49,7 @@
 "Wenn Sie HA-JMS selbst zu konfigurieren bereit sind, können Sie mit früheren "
 "Versionen des JBoss AS arbeiten. Einer unserer Kunden verwendet HA-JMS "
 "erfolgreich in der JBoss AS 3.0.7 Version. Bitte setzen Sie sich mit dem "
-"JBoss-Support in Verbindung, falls Sie Fragen haben."
+"JBoss Support in Verbindung, falls Sie Fragen haben."
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:16
@@ -60,13 +60,13 @@
 "JBoss Messaging project. JBoss Messaging's clustering implementation is "
 "considerably different from HA-JMS based on JBoss MQ; most notably it is not "
 "based on a singleton service only running on one node in the cluster."
-msgstr "Der HA-JMS in JBoss AS 4.2.2 und früheren Versionen basiert auf dem JBoss MQ Messaging-Produkt. In späteren Versionen des AS wird JBoss MQ durch das neuere JBoss Messaging-Projekt ersetzt. Die Clustering-Implementierung in JBoss Messaging unterscheidet sich deutlich von dem auf JBoss MQ basierenden HA-JMS; insbesondere basiert es nicht auf einem Singleton-Dienst, der nur auf einem einzigen Node im Cluster ausgeführt wird."
+msgstr "Der HA-JMS in JBoss AS 4.2.2 und früheren Versionen basiert auf dem JBoss MQ-Messaging-Produkt. In späteren Versionen des AS wird JBoss MQ durch das neuere JBoss Messaging-Projekt ersetzt. Die Clustering-Implementierung in JBoss Messaging unterscheidet sich deutlich von dem auf JBoss MQ basierenden HA-JMS; insbesondere basiert es nicht auf einem Singleton-Dienst, der nur auf einem Node im Cluster ausgeführt wird."
 
 #. Tag: title
 #: Clustering_Guide_JMS.xml:25
 #, no-c-format
 msgid "High Availability Singleton Fail-over"
-msgstr "Der \"High Availability Singleton Fail-Over\""
+msgstr "Der \"High Availability Singleton Failover\""
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:26
@@ -80,8 +80,8 @@
 "against server failures but does not reduce the work load on the JMS server "
 "node."
 msgstr ""
-"Der JBoss HA-JMS-Dienst (d. h. Message Queues, Topics und unterstützende Dienste) wird zu jedem Zeitpunkt stets nur auf einem einzelnen Node (d. h. dem \"Master Node\") im Cluster ausgeführt. Falls dieser Node ausfällt, wählt der Cluster "
-"einfach einen anderen Node aus, auf dem der JMS-Dienst ausgeführt wird (Fail-Over), und die Queues, Topics und unterstützende Dienste werden auf jenem Server deployt. Diese Konfiguration bietet Redundanz gegen Serverausfälle, senkt jedoch nicht die Arbeitsbelastung am JMS-Server-Node."
+"Der JBoss HA-JMS-Dienst (d. h. Message Queues, Topics und unterstützende Dienste) wird zu jedem Zeitpunkt stets nur auf einem einzelnen Node (d. h. dem Master Node) im Cluster ausgeführt. Falls dieser Node ausfällt, wählt der Cluster "
+"einfach einen anderen Node aus, auf dem der JMS-Dienst ausgeführt wird (Failover), und die Queues, Topics und unterstützende Dienste werden auf jenem Server deployt. Diese Konfiguration bietet Redundanz gegen Serverausfälle, senkt jedoch nicht die Arbeitsbelastung am JMS-Server-Node."
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:28
@@ -100,7 +100,7 @@
 #: Clustering_Guide_JMS.xml:33
 #, no-c-format
 msgid "Server Side Configuration"
-msgstr "Die Konfiguration auf Serverseite"
+msgstr "Die serverseitige Konfiguration"
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:35
@@ -115,7 +115,7 @@
 "JMS (e.g., MDBs and other JMS clients) do not need to be deployed in deploy-"
 "hasingleton. They should only be deployed there if you only want them "
 "running on one node in the cluster at a time."
-msgstr "Der größte Konfigurationsunterschied zwischen HA-JMS in der all-Konfiguration und der nicht-HA-Version, die sich in der Standardkonfiguration befindet, besteht im Speicherort der meisten Konfigurationsdateien. Für HA-JMS befinden sich die meisten Konfigurationsdateien in dem deploy-hasingleton/jms-Verzeichnis, nicht in deploy/jms. Ihre Queues und Topics müssen im deploy-hasingleton (oder ein Unterverzeichnis davon, wie deploy-hasingleton/jms) deployt werden. Anwendungskomponenten, die als Clients für HA-JMS fungieren (z. B. MDBs und andere JMS-Clients), brauchen nicht in deploy-hasingleton deployt werden. Diese sollten dort nur dann deployt werden, falls Sie wünschen, dass diese jeweils auf einem einzigen Node im Cluster ausgeführt werden."
+msgstr "Der größte Konfigurationsunterschied zwischen HA-JMS in der all-Konfiguration und der nicht-HA-Version, die sich in der Standardkonfiguration befindet, besteht im Speicherort der meisten Konfigurationsdateien. Bei HA-JMS befinden sich die meisten Konfigurationsdateien in dem deploy-hasingleton/jms-Verzeichnis, nicht in deploy/jms. Ihre Queues und Topics müssen im deploy-hasingleton (oder ein Unterverzeichnis davon, wie deploy-hasingleton/jms) deployt werden. Anwendungskomponenten, die als Clients für HA-JMS fungieren (z. B. MDBs und andere JMS-Clients), brauchen nicht in deploy-hasingleton deployt werden. Diese sollten dort nur dann deployt werden, falls Sie wünschen, dass diese zu jeder Zeit auf nur einem einzigen Node im Cluster ausgeführt werden."
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:38
@@ -126,10 +126,7 @@
 "related service MBeans and all deployed queues and topics. However, "
 "applications that use JMS (e.g., MDBs and other JMS clients) do not need to "
 "be deployed identically across the cluster."
-msgstr ""
-"Um den Singleton Fail-Over HA-JMS-Dienst zu verwenden, müssen Sie die JMS-"
-"Dienste auf sämtlichen Nodes des Clusters identisch konfigurieren. Das "
-"beinhaltet alle JMS-bezogenen Service-MBeans und alle deployten Queues und Topics. Alle Anwendungen, die JMS verwenden (z. B. MDBs und andere JMS-Clients) müssen indes nicht im gesamten Cluster identisch deployt sein."
+msgstr "Um den Singleton Failover HA-JMS-Dienst zu verwenden, müssen Sie die JMS-Dienste auf sämtlichen Nodes des Clusters identisch konfigurieren. Das beinhaltet alle JMS-bezogenen Service-MBeans und alle deployten Queues und Topics. Alle Anwendungen, die JMS verwenden (z. B. MDBs und andere JMS-Clients) müssen indes nicht im gesamten Cluster identisch deployt sein."
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:44
@@ -143,7 +140,7 @@
 "any cluster environments, all nodes need to persist data against a shared "
 "database. So, the first thing to do before you start clustered JMS is to "
 "setup a shared database for JMS. You need to do the following:"
-msgstr "Der JMS-Server ist so konfiguriert, dass er seine Daten im <literal>DefaultDS</literal> behält. In der Standardeinstellung ist das der eingebettete (\"embedded\") HSQLDB. Damit der HA-JMS-Dienst Fail-Over funktionieren kann, muss der neu gestartete HA-JMS-Server die vom alten Server gespeicherten Daten finden können. Dies ist wahrscheinlich nicht möglich, wenn die Daten in Dateien gespeichert wurden, die durch den HSQLDB des alten Servers geschrieben wurden. In den meisten Cluster-Umgebungen müssen alle Nodes Daten auf einer gemeinsamen Datenbank halten. Ehe Sie also einen geclusterten JMS starten, müssen Sie eine gemeinsame Datenbank für JMS einrichten. Hierzu müssen Sie folgendes tun:"
+msgstr "Der JMS-Server ist so konfiguriert, dass er seine Daten im <literal>DefaultDS</literal> behält. In der Standardeinstellung ist das der eingebettete (\"embedded\") HSQLDB. Damit der HA-JMS-Dienst Failover funktionieren kann, muss der neu gestartete HA-JMS-Server die vom alten Server gespeicherten Daten finden können. Dies wäre wahrscheinlich nicht möglich, wenn die Daten in Dateien gespeichert wurden, die durch den HSQLDB des alten Servers geschrieben wurden. In den meisten Cluster-Umgebungen müssen alle Nodes Daten auf einer gemeinsamen Datenbank halten. Ehe Sie also einen geclusterten JMS starten, müssen Sie eine gemeinsame Datenbank für JMS einrichten. Hierzu müssen Sie folgendes tun:"
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:50
@@ -168,7 +165,7 @@
 "<literal>docs/examples/jms</literal>."
 msgstr ""
 "Ersetzen Sie die <literal>hsqldb-jdbc2-service.xml</literal>-Datei "
-"im<literal>server/all/deploy-hasingleton/jms</literal>-Verzeichnis mit einer "
+"im <literal>server/all/deploy-hasingleton/jms</literal>-Verzeichnis mit einer "
 "speziell auf Ihre Bedürfnisse abgestimmten. Wenn Sie zum Beispiel MySQL "
 "verwenden, so heißt die Datei <literal>mysql-jdbc2-service.xml</literal>. "
 "Die Konfigurationsdateien für eine Reihe von RDBMS sind mit der JBoss AS-Distribution gebündelt. Sie finden diese unter <literal>docs/examples/jms</literal>."
@@ -209,7 +206,7 @@
 "and topicsusing HA-JNDI (the default port is 1100). This ensures the factory/"
 "queue/topic can be found no matter which cluster node is running the HA-JMS "
 "server."
-msgstr "Der HA-JMS-Client muss sowohl JMS-Verbindungs-Factorys als auch Queues und Topics mittels HA-JNDI auffinden (der Standard-Port ist 1100). Das gewährleistet, dass die Factory/Queue/Topic gefunden werden kann, unabhängig davon, auf welchem Cluster Node der HA-JMS-Server ausgeführt wird."
+msgstr "Der HA-JMS-Client muss sowohl JMS-Verbindungs-Factorys, als auch Queues und Topics mittels HA-JNDI aufsuchen (der Standard-Port ist 1100). Das gewährleistet, dass die Factory/Queue/Topic gefunden werden kann, unabhängig davon, auf welchem Cluster Node der HA-JMS-Server ausgeführt wird."
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:91
@@ -301,7 +298,7 @@
 "logic. If the HA-JMS service fails over to a different master node, all "
 "client operations on the current connection will fail with a JMSException. "
 "To deal with this:"
-msgstr "Der JA-JMS-Client muss mit Ausnahmen umgehen können, die auf der JMS-Verbindung auftreten, falls ein Server-Failover erfolgt. Anders als z. B. geclusterte EJB-Proxys beinhaltet das JMS-Verbindungsobjekt keine Logik zum automatischen Failover. Falls ein Failover des JA-JMS-Dienstes auf einen anderen Master Node erfolgt, werden alle Client-Operationen auf der aktuellen Verbindung mit einer JMSException fehlschlagen. Um hiermit umzugehen:"
+msgstr "Der JA-JMS-Client muss mit Ausnahmen umgehen können, die auf der JMS-Verbindung auftreten, wenn ein Server-Failover erfolgt. Anders als z. B. geclusterte EJB-Proxys beinhaltet das JMS-Verbindungsobjekt keine Logik zum automatischen Failover. Falls ein Failover des JA-JMS-Dienstes auf einen anderen Master Node erfolgt, werden alle Client-Operationen auf der aktuellen Verbindung mit einer JMSException fehlschlagen. Um dies zu handhaben:"
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:118
@@ -312,7 +309,7 @@
 "find the JBoss JMS Resource Adapter; the resource adapter will handle the "
 "task of detecting server failover and reconnecting to the new server when it "
 "starts."
-msgstr "Wenn der Client innerhalb des Applikations-Servers ausgeführt wird, sollte der Client die ConnectionFactory erhalten durch Aufsuchen von java:/JmsXA in JNDI. Dies wird den JBoss JMS-Ressourcenadapter finden; der Ressourcenadapter übernimmt dann die Aufgabe, den Server-Failover zu erkennen und mit dem neu gestarteten Server zu verbinden."
+msgstr "Wenn der Client innerhalb des Anwendungsservers ausgeführt wird, sollte der Client die ConnectionFactory erhalten durch Aufsuchen von java:/JmsXA in JNDI. Dies wird den JBoss JMS-Ressourcenadapter finden; der Ressourcenadapter übernimmt dann die Aufgabe, den Server-Failover zu erkennen und mit dem neu gestarteten Server zu verbinden."
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:122
@@ -324,7 +321,7 @@
 "the task of closing the old connection and reconnecting. Following is a "
 "example application that continuously sends messages to a queue, handling "
 "any exceptions that occur:"
-msgstr "Für Clients außerhalb des Anwendungsservers ist die beste Methode, einen ExceptionListener bei der Verbindung zu registrieren; der Listener erhält einen Callback, falls eine Ausnahme auf der Verbindung auftritt. Der Callback übernimmt dann die Aufgabe, die alte Verbindung zu beenden und neu zu verbinden. Nachfolgend sehen Sie eine Beispielanwendung, die kontinuierlich Nachrichten an eine Queue sendet, und handhabt jegliche auftretende Ausnahmen:"
+msgstr "Für Clients außerhalb des Anwendungsservers ist die beste Vorgehensweise, einen ExceptionListener bei der Verbindung zu registrieren; der Listener erhält einen Callback, falls eine Ausnahme auf der Verbindung auftritt. Der Callback übernimmt dann die Aufgabe, die alte Verbindung zu beenden und neu zu verbinden. Nachfolgend sehen Sie eine Beispielanwendung, die kontinuierlich Nachrichten an eine Warteschlange sendet, und etwaige auftretende Ausnahmen handhabt:"
 
 #. Tag: programlisting
 #: Clustering_Guide_JMS.xml:128
@@ -665,7 +662,7 @@
 "When you deploy an MDB in JBoss, JBoss' MDB container handles for you all "
 "issues associated with finding the cluster singleton HA-JMS server and with "
 "reconnecting to it if it fails over."
-msgstr "Wenn Sie eine MDB in JBoss deployen, übernimmt der JBoss MDB-Container sämtliche Aufgaben bezüglich der Suchen des Cluster-Singleton HA-JMS-Servers undder Neuverbindung im Falle eines Fail-Overs. "
+msgstr "Wenn Sie einen MDB in JBoss deployen, erledigt der JBoss MDB-Container sämtliche Aufgaben rund um die Suche des Cluster-Singleton HA-JMS-Servers sowie Neuverbindung im Falle eines Failovers."
 
 #. Tag: title
 #: Clustering_Guide_JMS.xml:143
@@ -689,10 +686,10 @@
 "ausgeführt werden, können MDBs an mehreren Nodes Nachrichten vom HA-JMS "
 "Master Node empfangen und bearbeiten. Die zweifelhaften Queues und Topics "
 "resultieren im lastverteilten Verhalten der MDBs. Um die Lastverteilung für "
-"MDBs zu aktivieren, können Sie einen Receiver für die Queue bestimmen. Der "
-"Receiver protokolliert, welcher Node auf Nachricht wartet und in welcher "
+"MDBs zu aktivieren, können Sie einen Empfänger (\"Receiver\") für die Queue bestimmen. Der "
+"Empfänger protokolliert, welcher Node auf Nachricht wartet und in welcher "
 "Reihenfolge Nachrichten bearbeitet werden sollten. JBoss bietet drei "
-"Receiver-Implementierungen."
+"Empfängerimplementierungen."
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:151
@@ -733,5 +730,5 @@
 "literal> or <literal>ReceiversImplLinkedList</literal> implementations due "
 "to an undesirable implementation detail of <literal>HashSet</literal> in the "
 "JVM."
-msgstr "Sie können den Klassennamen der Receiver-Implementierung als ein Attribut in dem MBean festlegen, das die permanente JMS-<literal>Queue</literal> oder <literal>DestinationManager</literal> auf jedem Node definiert. Für optimale Leistung der Lastverteilung empfehlen wir die Verwendung der <literal>ReceiversImplArrayList</literal> oder <literal>ReceiversImplLinkedList</literal>-Implementierung, aufgrund eines unerwünschten Implementierungsdetails von <literal>HashSet</literal> in der JVM."
+msgstr "Sie können den Klassennamen der Empfängerimplementierung als ein Attribut in dem MBean festlegen, das die permanente JMS-<literal>Queue</literal> oder <literal>DestinationManager</literal> auf jedem Node definiert. Für optimale Leistung der Lastverteilung empfehlen wir die Verwendung der <literal>ReceiversImplArrayList</literal> oder <literal>ReceiversImplLinkedList</literal>-Implementierung, aufgrund eines unerwünschten Implementierungsdetails von <literal>HashSet</literal> in der JVM."
 

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JNDI.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JNDI.po	2009-03-02 05:52:08 UTC (rev 84913)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JNDI.po	2009-03-02 07:06:37 UTC (rev 84914)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_JNDI\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-02-27 15:36+1000\n"
+"PO-Revision-Date: 2009-03-02 09:32+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -278,7 +278,7 @@
 "für Bean A und JNDI wird ein Binding desselben Namens an Node 2 für Bean B "
 "besitzen). Wenn folglich ein Client eine HA-JNDI-Abfrage für diesen Namen "
 "durchführt, wird diese an einem beliebigen JNDI-Server des Clusters "
-"aufgerufen und zum lokal gebundenen Stub zurückgeschickt. Dennoch ist es "
+"aufgerufen und der lokal gebundene Stub zurückgeschickt. Dennoch ist es "
 "möglich, dass es sich dabei nicht um den korrekten Stub handelt, den der "
 "Client zu erhalten erwartet! Daher ist die beste Vorgehensweise, sicherzustellen, dass im Cluster durchweg verschiedene Namen für logisch verschiedene Bindings verwendet werden."
 
@@ -335,7 +335,7 @@
 "für Bean A und JNDI wird ein Binding desselben Namens an Node 2 für Bean B "
 "besitzen). Wenn folglich ein Client eine HA-JNDI-Abfrage für diesen Namen "
 "durchführt, wird diese an einem beliebigen JNDI-Server des Clusters "
-"aufgerufen und zum lokal gebundenen Stub zurückgeschickt. Dennoch ist es "
+"aufgerufen und der lokal gebundene Stub zurückgeschickt. Dennoch ist es "
 "möglich, dass es sich dabei nicht um den korrekten Stub handelt, den der "
 "Client zu erhalten erwartet! Daher ist die beste Vorgehensweise, sicherzustellen, dass im Cluster durchweg verschiedene Namen für logisch verschiedene Bindings verwendet werden."