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

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

Author: hpeters
Date: 2009-02-26 02:27:08 -0500 (Thu, 26 Feb 2009)
New Revision: 84783

Modified:
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Intro.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JNDI.po
Log:
translation update in progress

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Intro.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Intro.po	2009-02-26 07:12:01 UTC (rev 84782)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Intro.po	2009-02-26 07:27:08 UTC (rev 84783)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_Intro\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 16:48+1000\n"
+"PO-Revision-Date: 2009-02-26 15:54+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -48,7 +48,7 @@
 "Clustering is crucial for highly available enterprise applications, as it is "
 "the clustering infrastructure that supports the redundancy needed for high "
 "availability."
-msgstr "Mit Clustering (\"Gruppierung\") ist die Ausführung einer Anwendung auf mehreren parallel laufenden Servern (sog. \"Cluster-Nodes\" oder \"Cluster-Knoten\") möglich, während den Anwendungs-Clients ein einheitlicher View geboten wird. Die Auslastung wird dabei auf verschiedene Server verteilt, und selbst falls es zu einer Störung auf einem oder mehreren der Server kommt, ist die Anwendung über andere, nicht betroffene Cluster-Nodes nach wie vor zugänglich. Clustering ist von maßgeblicher Bedeutung für skalierbare Anwendungen eines Unternehmens, da die Leistung ganz bequem durch Hinzufügen weiterer Nodes (\"Knoten\") zum Cluster erhöht werden kann. Clustering ist ebenfalls entscheidend für hochverfügbare Anwendungen einer Unternehmens, denn die Clustering-Infrastruktur unterstützt die Redundanz, die für hohe Verfügbarkeit erforderlich ist."
+msgstr "Mit Clustering (\"Gruppierung\") ist die Ausführung einer Anwendung auf mehreren parallel laufenden Servern (sog. \"Cluster-Nodes\" oder \"Cluster-Knoten\") möglich, während den Anwendungs-Clients eine einzige Ansicht geboten wird. Die Auslastung wird dabei auf verschiedene Server verteilt, und selbst falls es zu einer Störung auf einem oder mehreren der Server kommt, ist die Anwendung über andere, nicht betroffene Cluster-Nodes nach wie vor zugänglich. Clustering ist von maßgeblicher Bedeutung für skalierbare Anwendungen eines Unternehmens, da die Leistung ganz bequem durch Hinzufügen weiterer Nodes (\"Knoten\") zum Cluster erhöht werden kann. Clustering ist ebenfalls entscheidend für hochverfügbare Anwendungen einer Unternehmens, denn die Clustering-Infrastruktur unterstützt die Redundanz, die für hohe Verfügbarkeit erforderlich ist."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:14
@@ -78,7 +78,7 @@
 "for specific types of applications are covered after this section."
 msgstr ""
 "Im ersten Abschnitt dieses Kapitels werden die Grundkonzepte der JBoss Clustering-Dienste "
-"erörtert. Es ist wichtig, dass Sie diese verstehen, ehe Sie die übrigen Abschnitte dieses Kapitels lesen. Clustering-Konfigurationen für spezifische Anwendungstypen werden nach diesem Abschnitt behandelt."
+"erörtert. Es ist wichtig, dass Sie diese verstehen, ehe Sie die übrigen Abschnitte dieses Kapitels lesen. Clustering-Konfigurationen für spezielle Anwendungstypen werden nach diesem Abschnitt behandelt."
 
 #. Tag: title
 #: Clustering_Guide_Intro.xml:23
@@ -106,7 +106,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 "Ein Cluster ist eine Gruppe von Nodes (\"Knoten\"), die miteinander kommunizieren und auf ein gemeinsames Ziel hin arbeiten. In einem JBoss Anwendungsserver-Cluster (der sogenannten \"Partition\") handelt es sich bei einem Node um eine JBoss Anwendungsserver-Instanz. Kommunikation zwischen den Nodes wird durch die JGroups Gruppenkommunikations-Bibliothek gehandhabt, mit einem JGroups Channel, der die Kernfunktionalität liefert zum Nachverfolgen, wer sich im Cluster befindet, und verlässlich Nachrichten zwischen den Cluster-Mitgliedern austauscht. JGroups Channels mit denselben Konfigurationen und Namen besitzen die Fähigkeit, sich gegenseitig dynamisch aufzufinden und eine Gruppe zu bilden. Deshalb ist das bloße Ausführen von \"run -c all\" auf zwei AS-Instanzen desselben Netzwerks ausreichend, damit diese einen Cluster bilden – jeder AS startet einen Channel (tatsächlich mehrere) mit derselben Standardkonfiguration, so dass diese sich gegenseitig dynamisch !
 finden und einen Cluster bilden. Nodes können jederzeit dynamisch dem Cluster hinzugefügt oder aus ihm entfernt werden, einfach durch das Starten oder Beenden eines Channels mit Konfiguration und Namen, die denen der anderen Cluster-Mitglieder entsprechen. Zusammenfassend kann gesagt werden, dass es sich bei einem JBoss Cluster um eine Gruppe von AS-Server-Instanzen handelt, von denen jede einen identisch konfigurierten und benannten JGroups Channel ausführt."
+msgstr "Ein Cluster ist eine Gruppe von Nodes (\"Knoten\"), die miteinander kommunizieren und auf ein gemeinsames Ziel hin arbeiten. In einem JBoss Anwendungsserver-Cluster (der sogenannten \"Partition\") handelt es sich bei einem Node um eine JBoss Anwendungsserver-Instanz. Kommunikation zwischen den Nodes wird durch die JGroups Gruppenkommunikationsbibliothek gehandhabt mithilfe eines JGroups Channels, der die Kernfunktionalität liefert zum Nachverfolgen, wer sich im Cluster befindet, und zum zuverlässigen Nachrichtenaustausch zwischen den Cluster-Mitgliedern. JGroups Channels mit denselben Konfigurationen und Namen besitzen die Fähigkeit, sich gegenseitig dynamisch aufzufinden und eine Gruppe zu bilden. Deshalb ist das bloße Ausführen von \"run -c all\" auf zwei AS-Instanzen desselben Netzwerks ausreichend, damit diese einen Cluster bilden – jeder AS startet einen Channel (tatsächlich mehrere) mit derselben Standardkonfiguration, so dass diese sich gegenseitig dy!
 namisch finden und einen Cluster bilden. Nodes können jederzeit dynamisch einem Cluster hinzugefügt oder aus ihm entfernt werden, einfach durch das Starten oder Beenden eines Channels, der die gleiche Konfiguration und den gleichen Namen besitzt wie die anderen Cluster-Mitglieder. Zusammenfassend kann gesagt werden, dass es sich bei einem JBoss Cluster um eine Gruppe von AS-Serverinstanzen handelt, von denen jede einen identisch konfigurierten und benannten JGroups Channel ausführt."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:29
@@ -130,7 +130,7 @@
 "<literal>cluster</literal>. It's easy to think of this as a two node "
 "cluster, but it's important to understand that you really have 4 channels, "
 "and hence 4 two node clusters."
-msgstr "Wenn Sie also zwei AS 4.2.x Instanzen nehmen und <literal>run -c all</literal> ausführen, werden die Channels sich gegenseitig finden und Sie haben einen konzeptionellen <literal>Cluster</literal>. Man könnte meinen, dass dies ein Cluster mit zwei Nodes sei, es ist aber wichtig zu verstehen, dass Sie hier in Wahrheit 4 Channels und demzufolge 4 Cluster mit zwei Nodes haben."
+msgstr "Wenn Sie also in zwei AS 4.2.x Instanzen gehen und <literal>run -c all</literal> ausführen, werden die Channels sich gegenseitig entdecken und Sie haben einen konzeptionellen <literal>Cluster</literal>. Man könnte meinen, dass dies ein Cluster mit zwei Nodes sei, es ist aber wichtig zu verstehen, dass Sie hier in Wahrheit 4 Channels und demzufolge 4 Cluster bestehend aus zwei Nodes haben."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:36
@@ -143,13 +143,13 @@
 "simply by configuring the AS instances such that within a set of nodes meant "
 "to form a cluster the Channel configurations and names match while they "
 "differ from any other channels on the same network."
-msgstr "In demselben Netzwerk, sogar für denselben Dienst, können wir verschiedene Cluster haben. Unter <xref linkend=\"clustering-Partition.fig\"/> finden Sie ein Beispielnetzwerk von JBoss Server-Instanzen, aufgeteilt auf drei Cluster, der dritte davon nur mit einem Node. Diese Art Topologie kann eingestellt werden, indem ganz einfach die AS-Instanzen derart konfiguriert werden, dass sich innerhalb einer Gruppe von Nodes, die ein Cluster bilden sollen, die Channel-Konfiguration und -Namen gleichen, während sie sich von denen in jedem anderen Channel desselben Netzwerks unterscheiden."
+msgstr "In demselben Netzwerk, sogar für denselben Dienst, können wir verschiedene Cluster haben. <xref linkend=\"clustering-Partition.fig\"/> stellt ein Beispielnetzwerk von JBoss Server-Instanzen dar, untergeteilt in drei Cluster, der dritte nur mit einem Node. Diese Art Topologie kann eingerichtet werden, indem ganz einfach die AS-Instanzen derart konfiguriert werden, dass sich in einer Gruppe von Nodes, die einen Cluster bilden sollen, die Channel-Konfigurationen und -Namen gleichen, während sie sich von denen in jedem anderen Channel desselben Netzwerks unterscheiden."
 
 #. Tag: title
 #: Clustering_Guide_Intro.xml:38
 #, no-c-format
 msgid "Clusters and server nodes"
-msgstr "Cluster und Server Nodes"
+msgstr "Cluster und Server-Nodes"
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:46
@@ -162,7 +162,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 "Der Abschnitt über “JGroups Konfiguration” und über “Isolieren von JGroups Channels” behandelt ausführlich die Konfiguration von Channels, so dass erwünschte Peers sich gegenseitig finden, unerwünschte dagegen nicht. Wie bereits erwähnt, verwendet JBoss AS standardmäßig vier verschiedene JGroups Channels. Diese können in zwei grobe Kategorien unterschieden werden: der Channel, der vom Mehrzweck-Clustering-HAPartition-Dienst verwendet wird, und drei Channels, die von JBoss Chache erstellt werden für spezielles Caching und clusterweite Statusreplikation."
+msgstr "Der Abschnitt über “JGroups Konfiguration” und über “Isolieren von JGroups Channels” behandelt ausführlich die Konfiguration von Channels in einer derartigen Weise, dass erwünschte Peers sich gegenseitig finden, unerwünschte dagegen nicht. Wie bereits erwähnt verwendet JBoss AS standardmäßig vier verschiedene JGroups Channels. Diese können in zwei grobe Kategorien unterschieden werden: ein Channel, der vom Mehrzweck-Clustering-HAPartition-Dienst verwendet wird, und drei Channels, die von JBoss Chache erstellt werden für spezielles Caching und clusterweite Statusreplikation."
 
 #. Tag: title
 #: Clustering_Guide_Intro.xml:50
@@ -185,7 +185,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 ist ein Mehrzweckdienst, der für eine Vielzahl von Aufgaben beim AS-Clustering eingesetzt wird. Im Wesentlichen handelt es sich um ist es eine Abst, die basierend auf einem JGroups Channel gebaut wurde, um Unterstützung für das Senden/Empfangen von RPC-Aufrufen an/von einem oder mehreren Cluster-Mitgliedern bieten. HAPartition unterstützt ebenfalls eine verteilte Registry mit Informationen darüber, welche Clustering-Dienste auf welchen Clustering-Mitgliedern ausgeführt werden. Es sendet Benachrichtigungen an interessierte Listeners, sobald sich die Cluster-Mitgliedschaft oder die Registry der geclusterten Dienste verändert. HAPartition bildet den Kern von vielen der im Laufe dieses Handbuches erläuterten Clustering-Dienste, einschließlich Smart Client-Side Clustered Proxys, EJB 2 SFSB-Replikation und Entity-Cache-Management, Farming, HA-JNDI und HA Singletons.raktion"
+msgstr "HAPartition ist ein Mehrzweckdienst, der für eine Vielzahl von Aufgaben beim AS-Clustering eingesetzt wird. Im Wesentlichen handelt es sich um eine Abstraktion, die basierend auf einem JGroups Channel gebaut wurde, um Unterstützung für das Senden/Empfangen von RPC-Aufrufen an/von einem oder mehreren Cluster-Mitgliedern zu liefern. HAPartition unterhält zudem eine verteilte Registry mit Informationen darüber, welche Clustering-Dienste auf welchen Cluster-Mitgliedern ausgeführt werden. Es sendet Benachrichtigungen an interessierte Listeners, sobald sich die Cluster-Mitgliedschaft oder die Registry der geclusterten Dienste verändert. HAPartition bildet den Kern von vielen der im Verlauf dieses Handbuches erläuterten Clustering-Dienste, einschließlich Smart Client-Side geclusterte Proxys, EJB 2 SFSB-Replikation und Entity-Cache-Management, Farming, HA-JNDI und HA Singletons."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:57
@@ -196,10 +196,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 ""
-"Das folgende Beispiel zeigt die in der Standard JBoss AS-Distribution "
-"verpackte <literal>HAPartition</literal>-MBean-Definition. Falls Sie also JBoss Server mit den Standard-Clustering-Einstellungen auf einem lokalen Netzwerk starten, so erhalten Sie "
-"einen Standard-Cluster mit dem Namen <literal>DefaultPartition</literal>, der alle Server-Instanzen sowie deren Nodes enthält."
+msgstr "Das folgende Beispiel zeigt die mit der Standard JBoss AS-Distribution gelieferte <literal>HAPartition</literal>-MBean-Definition. Falls Sie also JBoss Server mit den Standard-Clustering-Einstellungen auf einem lokalen Netzwerk starten, erhalten Sie einen Standard-Cluster mit dem Namen <literal>DefaultPartition</literal>, der alle Server-Instanzen sowie deren Nodes enthält."
 
 #. Tag: programlisting
 #: Clustering_Guide_Intro.xml:61
@@ -265,11 +262,8 @@
 "jgroups\"/>. The following list shows the available configuration attributes "
 "in the <literal>HAPartition</literal> MBean."
 msgstr ""
-"Hier haben wir die detaillierte JGroups Protokollkonfiguration für diesen "
-"Channel weggelassen. JGroups erledigt die zugrunde liegende Peer-to-Peer-"
-"Kommunikation zwischen Nodes, wobei die betreffende Konfiguration in <xref linkend=\"jbosscache-"
-"jgroups\"/> behandelt wird. Die folgende Liste stellt "
-"die verfügbaren Konfigurationseigenschaften im <literal>HAPartition</literal>-MBean dar."
+"Wir haben hier die detaillierte JGroups Protokollkonfiguration für diesen Channel weggelassen. JGroups erledigt die zugrunde liegende Peer-to-Peer-Kommunikation zwischen Nodes, und dessen Konfiguration wird in <xref linkend=\"jbosscache-"
+"jgroups\"/> behandelt. Die folgende Liste stellt die verfügbaren Konfigurationseigenschaften im <literal>HAPartition</literal>-MBean dar."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:67
@@ -282,7 +276,7 @@
 msgstr ""
 "Bei <emphasis role=\"bold\">PartitionName</emphasis> handelt es sich um ein "
 "optionales Attribut, das den Namen des Clusters festlegt. Der voreingestellte "
-"Wert lautet <literal>DefaultPartition</literal>. Benutzen Sie den <literal>-g </literal> (d. h. --partition) Befehlszeilenschalter, um diesen Wert beim Start von JBoss einzustellen."
+"Wert lautet <literal>DefaultPartition</literal>. Benutzen Sie den <literal>-g </literal> (oder --partition) Befehlszeilenschalter, um diesen Wert beim Start von JBoss einzustellen."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:71
@@ -319,7 +313,7 @@
 "service startup. Its default value is <literal>30000</literal>."
 msgstr ""
 "Bei <emphasis role=\"bold\">StateTransferTimeout</emphasis> handelt es sich "
-"um ein optionales Attribut, mit dem der Timeout für die Statusreplikation am Cluster (in Millisekunden) festgelegt wird. Statusreplikation bezieht sich auf den Vorgang, den ursprünglichen Anwendungsstatus von anderen, bereits laufenden Cluster-Mitgliedern beim Start des Dienstes zu erhalten. Der voreingestellte Wert lautet hier <literal>30000</literal>."
+"um ein optionales Attribut, mit dem der Timeout für die Statusreplikation am Cluster (in Millisekunden) festgelegt wird. Statusreplikation bezieht sich auf den Vorgang, den initialen Anwendungsstatus von anderen, bereits laufenden Cluster-Mitgliedern beim Start des Dienstes zu erhalten. Der voreingestellte Wert lautet hier <literal>30000</literal>."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:82
@@ -341,7 +335,7 @@
 "<literal>PartitionName</literal> and the <literal>ParitionConfig</literal> "
 "elements. Changes in either element on some but not all nodes would cause "
 "the cluster to split."
-msgstr "Damit Nodes einen Cluster bilden, müssen sie genau dieselben <literal>PartitionName</literal> und <literal>ParitionConfig</literal>-Elemente besitzen. Änderungen in einem der beiden Elemente auf einigen, aber nicht allen Nodes würde zur Teilung des Clusters führen."
+msgstr "Damit Nodes einen Cluster bilden, müssen sie genau dieselben <literal>PartitionName</literal> und <literal>ParitionConfig</literal>-Elemente besitzen. Änderungen in einem der beiden Elemente auf einigen, aber nicht allen Nodes, würde zur Teilung des Clusters führen."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:89
@@ -360,7 +354,7 @@
 #: Clustering_Guide_Intro.xml:93
 #, no-c-format
 msgid "Note"
-msgstr "Anmerkungen"
+msgstr "Anmerkung"
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:94
@@ -391,13 +385,13 @@
 "a separate Mbean, and each cache creates its own JGroups Channel. We will "
 "cover those MBeans when we discuss specific services in the next several "
 "sections."
-msgstr "Beim JBoss Cache handelt es sich um ein vollständig verteiltes Cache-Framework, das in einer beliebigen Anwendungsserverumgebung oder auch eigenständig verwendet werden kann. Der JBoss AS integriert das JBoss Cache, um Cache-Dienste für HTTP-Sessions, EJB 3.0 Sessions und EJB 3.0 Entity-Beans bereitzustellen. Jeder dieser Cache-Dienste ist in einem separaten MBean definiert, und jeder Cache erstellt seinen eigenen JGroups Channel. Wir gehen näher auf diese MBeans ein, wenn wir in den folgenden Abschnitten spezielle Dienste behandeln."
+msgstr "Beim JBoss Cache handelt es sich um ein vollständig verteiltes Cache-Framework, das in einer beliebigen Anwendungsserverumgebung oder auch eigenständig verwendet werden kann. Der JBoss AS integriert den JBoss Cache, um Cache-Dienste für HTTP-Sessions, EJB 3.0 Sessions und EJB 3.0 Entity-Beans bereitzustellen. Jeder dieser Cache-Dienste ist in einem separaten MBean definiert, und jeder Cache erstellt seinen eigenen JGroups Channel. Wir gehen näher auf diese MBeans ein, wenn wir in den folgenden Abschnitten spezielle Dienste behandeln."
 
 #. Tag: title
 #: Clustering_Guide_Intro.xml:106
 #, no-c-format
 msgid "Service Architectures"
-msgstr "Service-Architekturen"
+msgstr "Dienste-Architekturen"
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:107
@@ -410,13 +404,13 @@
 "clustering architectures are used with JBoss AS: client-side interceptors (a."
 "k.a smart proxies or stubs) and external load balancers. Which architecture "
 "your application will use will depend on what type of client you have."
-msgstr "Die vom <literal>HAPartition</literal>-MBean definierte Clustering-Topographie auf den einzelnen Nodes für System-Administratoren von großer Bedeutung. Für die meisten Anwendungsentwickler ist jedoch wahrscheinlich die Cluster-Architektur aus Perspektive der Client-Applikationen wichtiger. JBoss AS verwendet zwei grundlegende Arten von Clustering-Architekturen: Clientbasierte Interzeptoren (auch: Proxys oder Stubs) und externe Lastverteiler. Welche Architektur von Ihrer Anwendung benutzt wird, hängt von der Art Ihres Clients ab."
+msgstr "Die vom <literal>HAPartition</literal>-MBean definierte Clustering-Topographie auf den einzelnen Nodes ist zwar für System-Administratoren von großer Bedeutung. Aber für die meisten Anwendungsentwickler ist wahrscheinlich die Cluster-Architektur aus Perspektive der Client-Applikationen wichtiger. JBoss AS verwendet zwei grundlegende Arten von Clustering-Architekturen: clientbasierte Interzeptoren (auch: Proxys oder Stubs) und externe Lastverteiler. Welche Architektur von Ihrer Anwendung benutzt wird, hängt von der Art Ihres Clients ab."
 
 #. Tag: title
 #: Clustering_Guide_Intro.xml:113 Clustering_Guide_Intro.xml:159
 #, no-c-format
 msgid "Client-side interceptor architecture"
-msgstr "Die clientbasierte Interzeptor-Architektur"
+msgstr "Die clientbasierte Interzeptorarchitektur"
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:114
@@ -434,7 +428,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 "Bei den meisten vom JBoss Anwendungsserver bereitgestellten Remote-Dienste, einschließlich JNDI, EJB, RMI und JBoss Remoting, muss der Client (etwa durch Lookup und Download) ein Stub (oder Proxy)-Objekt erhalten. Das Stub-Objekt wird vom Server generiert und implementiert die Unternehmensschnittstelle des Dienstes. Durch den Client erfolgen dann lokale Methodenaufrufe an das Stub-Objekt. Der Stub leitet den Aufruf automatisch über das Netzwerk weiter und ruft ihn gegen vom Server verwaltete Serviceobjekte auf. In einer Clustering-Umgebung beinhaltet das vom Server generierte Stub-Objekt auch einen Interzeptor, der Signale an die Nodes innerhalb des Clusters weiterleiten kann. Das Stub-Objekt findet heraus, wie es den passenden Server-Node findet, ordnet die Aufrufparameter, sortiert die Aufrufergebnisse und sendet die Ergebnisse zurück an den Client."
+msgstr "Bei den meisten vom JBoss Anwendungsserver bereitgestellten Remote-Dienste, einschließlich JNDI, EJB, RMI und JBoss Remoting, muss der Client (etwa durch Lookup und Download) ein Stub (oder Proxy)-Objekt erhalten. Das Stub-Objekt wird vom Server generiert und implementiert die Unternehmensschnittstelle des Dienstes. Durch den Client erfolgen dann lokale Methodenaufrufe an das Stub-Objekt. Der Stub leitet den Aufruf automatisch über das Netzwerk weiter und ruft ihn am vom Server verwalteten Dienstobjekten auf. In einer Clustering-Umgebung beinhaltet das vom Server generierte Stub-Objekt auch einen Interzeptor, der Signale an die Nodes innerhalb des Clusters weiterleiten kann. Das Stub-Objekt findet heraus, wie es den passenden Server-Node findet, ordnet die Aufrufparameter, sortiert die Aufrufergebnisse und sendet die Ergebnisse zurück an den Client."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:119
@@ -452,7 +446,7 @@
 "stub are transparent to the client application. The client-side interceptor "
 "clustering architecture is illustrated in <xref linkend=\"clustering-"
 "InterceptorArch.fig\"/>."
-msgstr "Die Stub-Interzeptoren bewahren aktualisierte Informationen zum Cluster. Sie kennen zum Beispiel die IP-Adressen sämtlicher verfügbarer Server-Nodes, den Algorithmus zur Verteilung der Auslastung auf die Nodes (siehe nächster Abschnitt) sowie den notwendigen Anfragen-Failover, falls der Zielnode nicht verfügbar ist. Mit jeder Service-Anfrage aktualisiert der Server-Node den Stub-Interzeptor im Hinblick auf die neuesten Veränderungen am Cluster. Wenn zum Beispiel einer der Nodes des Clusters ausfällt, wird jeder Client-Stub-Interzeptor mit der neuen Konfiguration aktualisiert sobald er sich das nächste Mal mit einem aktiven Node im Cluster verbindet. Alle Veränderungen am Service-Stub erfolgen transparent für die Client-Anwendung. Die clientbasierte Clustering-Architektur des Interzeptors ist in <xref linkend=\"clustering-InterceptorArch.fig\"/> dargestellt."
+msgstr "Die Stub-Interzeptoren bewahren aktualisierte Informationen zum Cluster. Sie kennen zum Beispiel die IP-Adressen sämtlicher verfügbarer Server-Nodes, den Algorithmus zur Verteilung der Auslastung auf die Nodes (siehe nächster Abschnitt) sowie den notwendigen Anfragen-Failover, falls der Zielnode nicht verfügbar ist. Mit jeder Dienst-Anfrage aktualisiert der Server-Node den Stub-Interzeptor im Hinblick auf die neuesten Veränderungen am Cluster. Wenn zum Beispiel einer der Nodes des Clusters ausfällt, wird jeder Client-Stub-Interzeptor mit der neuen Konfiguration aktualisiert, sobald er sich das nächste Mal mit einem aktiven Node im Cluster verbindet. Alle Veränderungen am Dienst-Stub erfolgen transparent für die Client-Anwendung. Die clientbasierte Clustering-Architektur des Interzeptors ist in <xref linkend=\"clustering-InterceptorArch.fig\"/> dargestellt."
 
 #. Tag: title
 #: Clustering_Guide_Intro.xml:122
@@ -498,7 +492,7 @@
 "architecture is illustrated in <xref linkend=\"clustering-BalancerArch.fig\"/"
 ">."
 msgstr ""
-"Andere JBoss Dienste, insbesondere die HTTP-Web-Dienste, erfordern keine Downloads durch den Client. Der Client (z. B. ein Webbrowser) schickt Anfragen und erhält gemäß bestimmter Kommunikationsprotokolle Rückmeldung (z.B. das HTTP-Protokoll) direkt über die Leitung. In diesem Fall wird ein externer Lastverteiler benötigt, um alle Anfragen zu bearbeiten und sie an die Server-Nodes im Cluster zu versenden. Der Client muss nur wissen, wie er den Lastverteiler ansprechen kann; die JBoss AS-Instanzen hinter dem Lastverteiler kennt er nicht. Obwohl der Lastverteiler logisch Teil des Clusters ist, bezeichnen wir ihn als \"extern\", da er nicht in demselben Prozess ausgeführt wird wie der Client oder die JBoss AS-Instanzen. Er kann entweder in Software oder Hardware implementiert werden. Es gibt viele Anbieter von Hardware-Lastverteilern; das mod_jk Apache-Modul ist ein exzellentes Beispiel für einen Software-Lastverteiler. Ein externer Lastverteiler implementiert seine e!
 igenen Verfahren zum Verständnis der Cluster-Konfiguration, und bringt seine eigenen Richtlinien für Lastverteilung und Failover mit. Die Cluster-Architektur des externen Lastverteilers ist in <xref linkend=\"clustering-BalancerArch.fig\"/"
+"Andere JBoss Dienste, insbesondere die HTTP-Web-Dienste, erfordern keine Downloads durch den Client. Der Client (z. B. ein Webbrowser) schickt Anfragen und erhält gemäß bestimmter Kommunikationsprotokolle Rückmeldung (z. B. das HTTP-Protokoll) direkt über die Leitung. In diesem Fall wird ein externer Lastverteiler benötigt, um alle Anfragen zu bearbeiten und sie an die Server-Nodes im Cluster zu versenden. Der Client braucht nur zu wissen, wie er den Lastverteiler ansprechen kann; die JBoss AS-Instanzen hinter dem Lastverteiler kennt er nicht. Obwohl der Lastverteiler logisch Teil des Clusters ist, bezeichnen wir ihn als \"extern\", da er nicht in demselben Prozess ausgeführt wird wie der Client oder die JBoss AS-Instanzen. Er kann entweder in Software oder Hardware implementiert werden. Es gibt viele Anbieter von Hardware-Lastverteilern; das mod_jk Apache-Modul ist ein sehr gutes Beispiel für einen Software-Lastverteiler. Ein externer Lastverteiler implementiert s!
 eine eigenen Verfahren zum Erkennen der Cluster-Konfiguration, und bringt seine eigenen Richtlinien für Lastverteilung und Failover mit. Die Cluster-Architektur des externen Lastverteilers ist in <xref linkend=\"clustering-BalancerArch.fig\"/"
 "> dargestellt."
 
 #. Tag: title
@@ -535,7 +529,7 @@
 "balancing policies to determine which server node to which node a new "
 "request should be sent. In this section, let's go over the load balancing "
 "policies available in JBoss AS."
-msgstr "Sowohl der JBoss clientbasierte Interzeptor (Stub) als auch der Lastverteiler befolgen bei der Lastverteilung Systemrichtlinien, um zu bestimmen, an welchen Server-Node eine neue Anfrage weitergeleitet wird. In diesem Abschnitt behandeln wir die Systemrichtlinien der Lastverteilung im JBoss AS."
+msgstr "Sowohl der JBoss clientbasierte Interzeptor (Stub) als auch der Lastverteiler befolgen bei der Lastverteilung Systemrichtlinien, um zu bestimmen, an welchen Server-Node eine neue Anfrage weitergeleitet wird. In diesem Abschnitt behandeln wir die Systemrichtlinien (auch \"Policys\") der Lastverteilung im JBoss AS."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:160
@@ -545,7 +539,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 "In JBoss 4.2.2 stehen folgende Lastverteilungsoptionen zur Verfügung, wenn die clientbasierte Interzeptor-Architektur verwendet wird. Der clientbasierte Stub bewahrt eine Liste aller Nodes, die den Zieldienst bereitstellen; es ist dann Aufgabe der Lastverteilungsrichtlinie, für jede Anfrage aus dieser Liste einen Node auszuwählen."
+msgstr "In JBoss 4.2.2 stehen folgende Lastverteilungsoptionen zur Verfügung, wenn die clientbasierte Interzeptorarchitektur verwendet wird. Der clientbasierte Stub bewahrt eine Liste aller Nodes, die den Zieldienst bereitstellen; es ist dann Aufgabe der Lastverteilungsrichtlinie, für jede Anfrage aus dieser Liste einen Node auszuwählen."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:165
@@ -557,7 +551,7 @@
 "the list."
 msgstr ""
 "Round-Robin (<literal>org.jboss.ha.framework.interfaces.RoundRobin</"
-"literal>): Jede Anfrage wird an einen neuen Node verschickt, der Reihe nach fortlaufend durch die Liste mit Nodes. Der erste Ziel-Node wird zufällig von der Liste ausgewählt. "
+"literal>): Jede Anfrage wird an einen neuen Node verschickt, der Reihe nach die Liste mit Nodes durchlaufend. Der erste Ziel-Node wird zufällig von der Liste ausgewählt. "
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:171
@@ -584,7 +578,7 @@
 "service (e.g., an EJB), each stub will independently pick its target. This "
 "is an example of a policy that provides “session affinity” or “sticky "
 "sessions”, since the target node does not change once established."
-msgstr "First Available (<literal>org.jboss.ha.framework.interfaces.FirstAvailable</literal>): Einer der verfügbaren Ziel-Nodes wird als Hauptziel ausgewählt und anschließend für jeden Aufruf verwendet: Der gewählte Node wird zufällig aus der Liste der Clustermitglieder ausgewählt. Wenn die Liste von Ziel-Nodes sich verändert (weil ein Node hinzukommt oder wegfällt), wird die Richtlinie (auch: \"Policy\") einen anderen Ziel-Node auswählen, falls der aktuell gewählte Node nicht doch noch verfügbar ist. Jeder clientbasierte Stub wählt unabhängig von den anderen Stubs seinen eigenen Ziel-Node, wenn also ein bestimmter Client zwei Stubs herunterlädt für denselben Zieldienst (z. B. ein EJB), so wird jeder Stub eigenständig sein Ziel auswählen. Dies ist ein Beispiel für eine Richtlinie, die Session-Affinität oder \"Sticky Sessions\" liefert, denn der Ziel-Node ändert sich nach dessen Festlegung nicht mehr."
+msgstr "First Available (<literal>org.jboss.ha.framework.interfaces.FirstAvailable</literal>): Einer der verfügbaren Ziel-Nodes wird als Hauptziel ausgewählt und anschließend für jeden Aufruf verwendet: Der gewählte Node wird zufällig aus der Liste der Cluster-Mitglieder ausgewählt. Wenn die Liste von Ziel-Nodes sich verändert (weil ein Node hinzukommt oder wegfällt), wird die Richtlinie einen anderen Ziel-Node auswählen, falls der aktuell gewählte Node nicht doch noch verfügbar ist. Jeder clientbasierte Stub wählt unabhängig von den anderen Stubs seinen eigenen Ziel-Node, wenn also ein bestimmter Client zwei Stubs herunterlädt für denselben Zieldienst (z. B. ein EJB), so wird jeder Stub eigenständig sein Ziel auswählen. Dies ist ein Beispiel für eine Richtlinie, die Session-Affinität oder \"Sticky Sessions\" bietet, denn der Ziel-Node ändert sich nach dessen Festlegung nicht mehr."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:183
@@ -609,13 +603,13 @@
 "implementation of this simple interface if they need some special behavior. "
 "In later sections we'll see how to configure the load balance policies used "
 "by different services."
-msgstr "Alle der oben genannten sind Implementierungen der org.jboss.ha.framework.interfaces.LoadBalancePolicy-Schnittstelle; es steht Benutzern frei, ihre eigene Implementierung dieser einfachen Schnittstelle zu schreiben, falls sie eine besondere Verhaltensweise benötigen. In späteren Abschnitten werden wir behandeln, wie die von verschiedenen Diensten genutzten Lastverteilungsrichtlinien konfiguriert werden."
+msgstr "Bei allen handelt es sich um Implementierungen der org.jboss.ha.framework.interfaces.LoadBalancePolicy-Schnittstelle. Es steht Anwendern frei, ihre eigene Implementierung dieser einfachen Schnittstelle zu schreiben, wenn sie eine besondere Verhaltensweise benötigen. In späteren Abschnitten werden wir behandeln, wie die von verschiedenen Diensten genutzten Richtlinien zur Lastverteilung konfiguriert werden."
 
 #. Tag: title
 #: Clustering_Guide_Intro.xml:193
 #, no-c-format
 msgid "External load balancer architecture"
-msgstr "Architektur eines externen Lastverteilers"
+msgstr "Architektur des externen Lastverteilers"
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:195
@@ -628,7 +622,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 "Wie oben bereits erwähnt, bringt ein externer Lastverteiler seine eigenen Lastverteilungsfunktionalität mit. Welche Funktionalitäten unterstützt werden, hängt vom Anbieter des Lastverteilers ab. Die einzige JBoss-Anforderung ist, dass der Lastverteiler Session-Affinität (sog. \"Sticky Sessions\") unterstützen muss. Sobald der Lastverteiler eine Anfrage von einem Client an Node A leitet, und der Server eine Session initiiert hat, so müssen bei aktivierter Session-Affinität alle zukünftigen Anfragen diese Session betreffend auch an Node A geleitet werden, solange Node A verfügbar ist."
+msgstr "Wie oben bereits erwähnt, bringt ein externer Lastverteiler seine eigenen Lastverteilungsfunktionalitäten mit. Welche Funktionalitäten unterstützt werden, hängt vom Anbieter des Lastverteilers ab. Die einzige JBoss Anforderung ist, dass der Lastverteiler Session-Affinität (sog. \"Sticky Sessions\") unterstützen muss. Sobald der Lastverteiler eine Anfrage von einem Client an Node A leitet, und der Server eine Session initiiert, so müssen bei aktivierter Session-Affinität alle zukünftigen Anfragen diese Session betreffend auch an Node A geleitet werden, solange Node A verfügbar ist."
 
 #. Tag: title
 #: Clustering_Guide_Intro.xml:205
@@ -652,7 +646,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 "Der einfachste Weg, eine Anwendung im Cluster zu deployen, ist mittels des Farming-Dienstes. Indem Sie die Archivdatei der Anwendung (z. B. eine EAR, WAR oder SAR-Datei) im <code>all/farm/</code>-Verzeichnis von einem der Cluster-Mitglieder \"hot-deployen\", wird die Anwendung automatisch über alle Nodes desselben Clusters dupliziert. Falls dem Cluster später ein Node hinzugefügt wird, wird er alle farm-deployten Anwendungen im Cluster einbinden, und sie beim Start lokal deployen. Falls Sie die Applikation aus dem <literal>farm/</literal>-Ordner von einem der laufenden Cluster-Server-Nodes löschen, wird die Applikation lokal undeployt, und anschließend aus den farm-Ordnern von allen anderen Cluster-Server-Nodes entfernt (löst Undeployment aus). Sie sollten die Anwendung manuell aus den farm-Ordnern allderjeniger Server-Nodes entfernen, die aktuell nicht mit dem Cluster verbunden sind."
+msgstr "Der einfachste Weg, eine Anwendung im Cluster zu deployen, ist mittels des Farming-Dienstes. Indem Sie die Archivdatei der Anwendung (z. B. eine EAR, WAR oder SAR-Datei) im <code>all/farm/</code>-Verzeichnis von einem der Cluster-Mitglieder \"hot-deployen\" (d. h. zur Laufzeit implementieren), wird die Anwendung automatisch über alle Nodes desselben Clusters dupliziert. Falls dem Cluster später ein Node hinzugefügt wird, wird er alle farm-deployten Anwendungen im Cluster einbeziehen und sie beim Start lokal deployen. Falls Sie die Applikation aus dem <literal>farm/</literal>-Ordner von einem der laufenden Cluster-Server-Nodes löschen, wird die Applikation lokal undeployt, und anschließend aus den farm-Ordnern von allen anderen Cluster-Server-Nodes entfernt (löst Undeployment aus). Sie sollten die Anwendung manuell aus den farm-Ordnern allderjenigen Server-Nodes entfernen, die aktuell nicht mit dem Cluster verbunden sind."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:216
@@ -668,8 +662,8 @@
 "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 ""
-"Aufgrund einer Schwäche in der Implementierung funktioniert der Farm-Deployment-Dienst derzeit nur für 1) Archive, die sich im farm/-Verzeichnis des allerersten Nodes im Cluster befinden, oder 2) hot-deployte Archive. "
-"Wenn Sie eine neue Anwendung zum famr/-Verzeichnis hinzufügen und anschließend den Server starten, damit dieser einem bereits bestehenden Cluster beitritt, so wird die Applikation nicht über den gesamten Cluster gestreut oder deployt. Der Grund hierfür liegt im Farm-Dienst, der nicht weiß, ob eine Anwendung tatsächlich ein neues Deployment repräsentiert, oder nur ein altes Deployment, welches vom übrigen Cluster entfernt wurde, während der neu startende Node offline war. Wir arbeiten daran, dieses Problem zu beheben."
+"Aufgrund einer Schwäche in der Implementierung funktioniert der Farm-Deployment-Dienst derzeit nur für 1) Archive, die sich im farm/-Verzeichnis des ersten Nodes im Cluster befinden, oder 2) hot-deployte Archive. "
+"Wenn Sie zuerst eine neue Anwendung zum farm/-Verzeichnis hinzufügen und anschließend den Server starten, damit dieser einem bereits bestehenden Cluster beitritt, so wird die Applikation nicht über den gesamten Cluster verteilt oder deployt. Der Grund hierfür liegt im Farm-Dienst, der nicht weiß, ob eine Anwendung tatsächlich ein neues Deployment repräsentiert, oder nur ein altes Deployment, welches vom übrigen Cluster entfernt wurde, während der neu startende Node offline war. Wir arbeiten daran, dieses Problem zu beheben."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:219
@@ -680,7 +674,7 @@
 "will be replicated around the cluster piecemeal, and it is very likely that "
 "remote nodes will begin trying to deploy things before all the pieces have "
 "arrived, leading to deployment failure."
-msgstr "Sie können nur gezippte Archivdateien in das Farm-Verzeichnis platzieren, keine entpackten Verzeichnisse. Werden entpackte Verzeichnisse im Farm-Verzeichnis abgelegt, so werden die Inhalte des Verzeichnisses stückweise im Cluster repliziert, und es ist sehr wahrscheinlich, dass entfernte Nodes bereits mit dem Deployment einiger Teile beginnen, bevor alle Teile angekommen sind, was zum Scheitern des Deployments führt."
+msgstr "Sie können nur gezippte Archivdateien in das Farm-Verzeichnis platzieren, keine entpackten Verzeichnisse. Werden entpackte Verzeichnisse im Farm-Verzeichnis abgelegt, so werden die Inhalte des Verzeichnisses stückweise im Cluster repliziert, wodurch Remote-Nodes höchstwahrscheinlich bereits mit dem Deployment einiger Teile beginnen werden, bevor alle Teile angekommen sind, was zum Scheitern des Deployments führt."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:222
@@ -693,7 +687,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 "Farmed Deployment ist nicht atomisch. Ein Problem beim Deployen, Un-Deployen oder Re-Deployen einer Anwendung auf einem Node im Cluster wird nicht notwendigerweise das Deployen, Un-Deployen oder Re-Deployen auf anderen Nodes beeinträchtigen. Es gibt keine Funktionalität zu Zurücksetzen (\"Rollback\"). Auch wird das Deployment nicht schrittweise ausgeführt; so ist es sogar wahrscheinlich, dass z. B. ein Re-Deployment auf allen Nodes im Cluster gleichzeitig erfolgt, wodurch kurzzeitig kein Node im Cluster den Dienst bereitstellt."
+msgstr "Farmed Deployment ist nicht atomisch. Ein Problem beim Deployment, Undeployment oder Redeployment einer Anwendung auf einem Node im Cluster wird nicht notwendigerweise das Deployment, Undeployment oder Redeployment auf anderen Nodes verhindern. Es existiert keine Funktionalität zum Zurücksetzen (\"Rollback\"). Zudem wird Deployment nicht schrittweise ausgeführt; so ist es sogar wahrscheinlich, dass z. B. ein Redeployment auf allen Nodes im Cluster gleichzeitig erfolgt, wodurch kurzzeitig kein Node im Cluster mehr den Dienst bereitstellt."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:226
@@ -707,7 +701,7 @@
 "JBoss deploy directory <literal>$JBOSS_HOME/server/your_own_config/deploy/"
 "deploy.last</literal>. Make sure that your custom configuration has "
 "clustering enabled."
-msgstr "Das Farming ist in der <literal>all</literal>-Konfiguration von JBoss AS-Distributionen voreingestellt, so dass Sie es nicht selbst einstellen müssen. Die <literal>farm-service.xml</literal>-Konfigurationsdatei befindet sich im deploy/deploy.last-Verzeichnis. Falls Sie das Farming in Ihrer individuellen Konfiguration aktivieren möchten, kopieren Sie einfach die farm-service.xml-Datei (nennen Sie diese <literal>farm-service.xml</literal>), und kopieren Sie sie in das JBoss Deploy-Verzeichnis <literal>$JBOSS_HOME/server/your_own_config/deploy/deploy.last</literal>. Vergewissern Sie sich, dass in Ihrer Konfiguration das Clustering aktiviert ist."
+msgstr "Das Farming ist in der <literal>all</literal>-Konfiguration von JBoss AS-Distributionen voreingestellt, so dass Sie es nicht selbst einstellen müssen. Die <literal>farm-service.xml</literal>-Konfigurationsdatei befindet sich im deploy/deploy.last-Verzeichnis. Falls Sie das Farming in Ihrer individuellen Konfiguration aktivieren möchten, kopieren Sie einfach die farm-service.xml-Datei in das JBoss Deploy-Verzeichnis <literal>$JBOSS_HOME/server/your_own_config/deploy/deploy.last</literal>. Vergewissern Sie sich, dass in Ihrer Konfiguration das Clustering aktiviert ist."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:228
@@ -770,7 +764,7 @@
 "cluster communication."
 msgstr ""
 "Bei <emphasis role=\"bold\">ClusterPartition</emphasis> handelt es sich um ein "
-"notwendiges Merkmal, um den vom Farm-Dienst für clusterinterne Kommunikation verwendeten HAPartition-Dienst einzuspeisen."
+"erforderliches Merkmal, um den HAPartition-Dienst einzuspeisen, der vom Farm-Dienst für clusterinterne Kommunikation verwendet wird."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:239
@@ -784,7 +778,7 @@
 msgstr ""
 "<emphasis role=\"bold\">URLs</emphasis> weist auf das Verzeichnis, in dem "
 "der Deployer das Deployment der Dateien überwacht. Falls es nicht bereits "
-"existiert, so erstellt das MBean dieses Verzeichnis. Wird keine vollständige URL bereitgestellt, so wird angenommen, dass der Wert ein Dateisystempfad relativ zum Konfiguratinsverzeichnis ist (z. B. <literal>$JBOSS_HOME/server/all/</literal>)."
+"existiert, so erstellt das MBean dieses Verzeichnis. Wird keine vollständige URL angegeben, so wird angenommen, dass der Wert ein Dateisystempfad relativ zum Konfiguratinsverzeichnis ist (z. B. <literal>$JBOSS_HOME/server/all/</literal>)."
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:244
@@ -822,7 +816,7 @@
 #: Clustering_Guide_Intro.xml:257
 #, no-c-format
 msgid "Distributed state replication services"
-msgstr "Verteilte Dienste zur Statusreplikation (\"State Replication Services\")"
+msgstr "Verteilte Dienste zur Statusreplikation"
 
 #. Tag: para
 #: Clustering_Guide_Intro.xml:258
@@ -873,5 +867,5 @@
 "for any custom caching requirements your applications may have. We will "
 "cover JBoss Cache in more detail when we discuss specific services in the "
 "next several sections.."
-msgstr "Wie bereits erwähnt, wird JBoss Cache verwendet zum Bereitstellen von Cache-Diensten für HTTP-Sessions, EJB 3.0 Session-Beans und EJB 3.0 Entity-Beans. Es ist das Haupt-Tool für verteiltes Statusmanagement im JBoss AS und eine ausgezeichnete Wahl für jegliche spezielle Caching-Anforderungen Ihrer Anwendungen. Wir gehen näher auf JBoss Cache ein, wenn wir in den folgenden Abschnitten spezielle Dienste behandeln."
+msgstr "Wie bereits erwähnt wird JBoss Cache dazu verwendet, Cache-Dienste für HTTP-Sessions, EJB 3.0 Session-Beans und EJB 3.0 Entity-Beans bereitzustellen. Es ist das wichtigste Werkzeug für verteiltes Statusmanagement im JBoss AS und eine ausgezeichnete Wahl für jegliche spezielle Caching-Anforderungen Ihrer Anwendungen. Wir gehen näher auf JBoss Cache ein, wenn wir in den folgenden Abschnitten spezielle Dienste behandeln."
 

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-02-26 07:12:01 UTC (rev 84782)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JNDI.po	2009-02-26 07:27:08 UTC (rev 84783)
@@ -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-16 15:41+1000\n"
+"PO-Revision-Date: 2009-02-26 17:23+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -30,7 +30,7 @@
 "JNDI is one of the most important services provided by the application "
 "server. The JBoss HA-JNDI (High Availability JNDI) service brings the "
 "following features to JNDI:"
-msgstr "JNDI ist einer der wichtigsten Dienste, die von einem Anwendungsserver bereitgestellt werden. Der JBoss HA-JNDI (\"High Availability JNDI\") Dienst bringt die folgenden Features in JNDI ein:"
+msgstr "JNDI ist einer der wichtigsten Dienste, die vom Anwendungsserver bereitgestellt werden. Der JBoss HA-JNDI (\"High Availability JNDI\") Dienst bringt die folgenden Features in JNDI ein:"
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:10
@@ -40,7 +40,7 @@
 "connected to the HA-JNDI service on a particular JBoss AS instance, and that "
 "service fails or is shut down, the HA-JNDI client can transparently fail "
 "over to another AS instance."
-msgstr "Transparenter Failover von Naming-Operationen. Wenn ein HA-JNDI Naming Context mit dem HA-JNDI-Dienst auf einer bestimmten JBoss AS-Instanz verbunden ist, und dieser Dienst ausfällt oder beendet wird, kann der HA-JNDI-Client transparent auf eine andere AS-Instanz ausweichen."
+msgstr "Transparenter Failover von Naming-Operationen. Wenn ein HA-JNDI Naming Context mit dem HA-JNDI-Dienst auf einer bestimmten JBoss AS-Instanz verbunden ist, und dieser Dienst ausfällt oder beendet wird, kann der HA-JNDI-Client transparent auf eine andere AS-Instanz ausweichen (\"Failover\")."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:15
@@ -49,13 +49,13 @@
 "Load balancing of naming operations. An HA-JNDI naming Context will "
 "automatically load balance its requests across all the HA-JNDI servers in "
 "the cluster."
-msgstr "Lastverteilung von Naming-Operationen. Ein HA-JNDI Naming Context wendet bei seinen Anfragen an alle HA-JNDI-Server im Cluster automatisch Lastverteilung an."
+msgstr "Lastverteilung von Naming-Operationen. Ein HA-JNDI Naming Context wendet bei seinen Anfragen automatisch Lastverteilung über alle HA-JNDI-Server im Cluster an."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:20
 #, no-c-format
 msgid "Automatic client discovery of HA-JNDI servers (using multicast)."
-msgstr "Automatic Client Discovery von HA-JNDI-Servern (mittels Multicast)."
+msgstr "Automatische Client Discovery von HA-JNDI-Servern (mittels Multicast)."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:25
@@ -64,7 +64,7 @@
 "Unified view of JNDI trees cluster-wide. Client can connect to the HA-JNDI "
 "service running on any node in the cluster and find objects bound in JNDI on "
 "any other node. This is accomplished via two mechanisms:"
-msgstr "Einheitliche Ansicht von JNDI-Trees clusterweit. Der Client kann sich mit dem HA-JNDI-Dienst verbinden, der auf einem beliebigen Node im Cluster läuft, und kann Objekte finden, die in JNDI auf jedem anderen Node gebunden sind. Dies wird erreicht durch zwei Verfahren:"
+msgstr "Einheitliche Ansicht von JNDI-Trees clusterweit. Clients können sich mit einem HA-JNDI-Dienst verbinden, der auf einem beliebigen Node im Cluster läuft, und kann Objekte finden, die auf einem beliebigen anderen Node in JNDI gebunden sind. Dies wird durch zwei Verfahren erreicht:"
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:33
@@ -73,7 +73,7 @@
 "Cross-cluster lookups. A client can perform a lookup and the server side HA-"
 "JNDI service has the ability to find things bound in regular JNDI on any "
 "node in the cluster."
-msgstr "Cross-Cluster Lookups. Ein Client kann einen Lookup durchführen, und der serverseitige HA-JNDI-Dienst kann Dinge finden, die im regulären JNDI auf jedem Node im Cluster eingebunden sind."
+msgstr "Cross-Cluster Lookups. Wenn ein Client einen Lookup ausführt, kann der serverbasierte HA-JNDI-Dienst Elemente finden, die auf einem beliebigen Node im Cluster im regulären JNDI gebunden sind."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:37
@@ -82,7 +82,7 @@
 "A replicated cluster-wide context tree. An object bound into the HA-JNDI "
 "service will be replicated around the cluster, and a copy of that object "
 "will be available in-VM on each node in the cluster."
-msgstr "Ein replizierter, clusterweiter Context-Tree. Ein Objekt, gebunden an den HA-JNDI-Dienst, wird um den Cluster herum repliziert, und eine Kopie dieses Objektes wird in-VM auf jedem Node im Cluster verfügbar sein."
+msgstr "Ein replizierter, clusterweiter Context-Tree. Ein im HA-JNDI-Dienst gebundenes Objekt wird über den gesamten Cluster hinweg repliziert, und eine Kopie dieses Objektes wird in-VM auf jedem Node im Cluster verfügbar sein."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:46
@@ -95,7 +95,7 @@
 "to look up those proxies. However, it is important to understand that using "
 "HA-JNDI (or not) has no effect whatsoever on the clustering behavior of the "
 "objects that are looked up. To illustrate:"
-msgstr "JNDI ist eine Schlüsselkomponente für viele andere Interzeptor-basierte Clustering-Dienste: Diese Dienste registrieren sich beim JNDI, so dass der Client ihre Proxys finden und so ihre Dienste in Anspruch nehmen kann. HA-JNDI ergänzt das Bild dadurch, dass er sicherstellt, dass Clients hochverfügbare Mittel besitzen, diese Proxys zu suchen. Es ist jedoch wichtig zu verstehen, dass das Verwenden (oder auch Nicht-Verwenden) von HA-JNDI keinerlei Auswirkungen hat auf die Clustering-Verhaltensweisen der gesuchten Objekte. Zur Veranschaulichung:"
+msgstr "JNDI ist eine Schlüsselkomponente für viele andere interzeptorbasierte Clustering-Dienste: Diese Dienste registrieren sich beim JNDI, so dass der Client ihre Proxys finden und so ihre Dienste in Anspruch nehmen kann. HA-JNDI ergänzt das Bild, indem er sicherstellt, dass Clients hochverfügbare Mittel besitzen, diese Proxys zu suchen. Es ist jedoch wichtig zu verstehen, dass das Verwenden (oder auch Nicht-Verwenden) von HA-JNDI keinerlei Auswirkungen hat auf die Clustering-Verhaltensweisen der gesuchten Objekte. Zur Veranschaulichung:"
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:51
@@ -104,7 +104,7 @@
 "If an EJB is not configured as clustered, looking up the EJB via HA-JNDI "
 "does not somehow result in the addition of clustering capabilities (load "
 "balancing of EJB calls, transparent failover, state replication) to the EJB."
-msgstr "Falls ein EJB nicht als geclustered konfiguriert ist, wird das Suchen des EJB via HA-JNDI nicht auf einmal dazu führen, dass Clustering-Fähigkeiten (Lastverteilung von EJB-Aufrufen, transparenter Failover, Statusreplikation) zur EJB hinzugefügt werden."
+msgstr "Falls ein EJB nicht als geclustered konfiguriert ist, wird das Suchen des EJB per HA-JNDI nicht auf einmal dazu führen, dass Clustering-Funktionalitäten (Lastverteilung von EJB-Aufrufen, transparenter Failover, Statusreplikation) zur EJB hinzugefügt werden."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:56
@@ -113,7 +113,7 @@
 "If an EJB is configured as clustered, looking up the EJB via regular JNDI "
 "instead of HA-JNDI does not somehow result in the removal of the bean "
 "proxy's clustering capabilities."
-msgstr "Falls ein EJB als geclustered konfiguriert ist, wird das Suchen des EJB via regulärem JNDI anstelle von HA-JNDI nicht auf einmal dazu führen, dass dem Bean-Proxy Clustering-Fähigkeiten entzogen werden."
+msgstr "Falls ein EJB als geclustered konfiguriert ist, wird das Suchen des EJB per regulärem JNDI anstelle von HA-JNDI nicht auf einmal dazu führen, dass dem Bean-Proxy Clustering-Fähigkeiten entzogen werden."
 
 #. Tag: title
 #: Clustering_Guide_JNDI.xml:66
@@ -134,7 +134,7 @@
 "Other than the need to ensure the appropriate naming properties are provided "
 "to the InitialContext, the fact that the naming Context is using HA-JNDI is "
 "completely transparent to the client."
-msgstr "Der JBoss clientseitige HA-JNDI Naming Context basiert auf der clientseitigen Interzeptorarchitektur. Der Client erhält ein HA-JNDI-Proxy-Objekt (mittels des InitialContext-Objekts) und ruft JNDI-Lookup-Dienste auf dem entfernten Server durch den Proxy auf. Der Client spezifiziert, dass er einen HA-JNDI-Proxy wünscht durch Konfiguration der Naming-Eigenschaften, die vom InitialContext-Objekt verwendet werden. In dem Abschnitt \"Client-Konfiguration\" wird dies ausführlich behandelt. Abgesehen davon, dass sichergestellt werden muss, dass dem InitialContext die passenden Naming-Eigenschaften geliefert werden, ist die Tatsache, dass der Naming Context HA-JNDI verwendet, für den Client völlig transparent."
+msgstr "Der JBoss clientseitige HA-JNDI Naming Context basiert auf der clientseitigen Interzeptorarchitektur. Der Client erhält ein HA-JNDI-Proxy-Objekt (via dem InitialContext-Objekt) und ruft JNDI-Lookup-Dienste auf dem Remote-Server durch den Proxy auf. Der Client legt fest, dass er einen HA-JNDI-Proxy wünscht, durch Konfiguration der Naming-Eigenschaften, die vom InitialContext-Objekt verwendet werden. In dem Abschnitt \"Client-Konfiguration\" wird dies ausführlich behandelt. Abgesehen davon, dass sichergestellt werden muss, dass dem InitialContext die passenden Naming-Eigenschaften geliefert werden, ist die Tatsache, dass der Naming Context HA-JNDI verwendet, für den Client völlig transparent."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:70
@@ -148,19 +148,20 @@
 "to either tree. The design rationale for this architecture is as follows:"
 msgstr ""
 "Auf der Serverseite pflegt der JBoss HA-JNDI (\"High Availability JNDI\") Dienst einen "
-"clusterweiten Context-Tree (\"Context-Verzeichnisbaum\"). Der clusterweite "
-"Tree ist verfügbar, so lange mindestens ein Node im Cluster vorhanden ist. "
-"Jeder Node im Cluster besitzt außerdem seinen eigenen lokalen JNDI-"
-"Context-Tree. Der HA-JNDI-Dienst auf dem Node kann Objekte finden, die an den lokalen JNDI-Context-Tree gebunden sind. Eine Anwendung kann ihre Objekte an beide Trees binden. Die Entwurfsprinzipien dieser Architektur lauten wie folgt:"
+"clusterweiten Context Tree (\"Context-Verzeichnisbaum\"). Der clusterweite "
+"Tree ist verfügbar, so lange noch mindestens ein Node im Cluster vorhanden ist. "
+"Jeder Node im Cluster besitzt außerdem seinen eigenen lokalen JNDI "
+"Context Tree. Der HA-JNDI-Dienst auf dem Node kann Objekte finden, die an den lokalen JNDI Context Tree gebunden sind. Eine Anwendung kann ihre Objekte an beide Trees binden. Die Entwurfsprinzipien dieser Architektur lauten wie folgt:"
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:75
 #, no-c-format
+#, fuzzy
 msgid ""
 "It avoids migration issues with applications that assume that their JNDI "
 "implementation is local. This allows clustering to work out-of-the-box with "
 "just a few tweaks of configuration files."
-msgstr "Es vermeidet Schwierigkeiten bei der Migration mit Anwendungen, die annehmen, dass ihre JNDI-Implementierung lokal ist. So wird hervorragendes Clustering ermöglicht, bei dem nur ein paar Anpassungen in den Konfigurationsdateien erforderlich sind."
+msgstr "Es vermeidet Schwierigkeiten bei der Migration von Anwendungen, die voraussetzen, dass ihre JNDI-Implementierung lokal erfolgt. So wird hervorragendes Clustering ermöglicht, bei dem nur ein paar Anpassungen in den Konfigurationsdateien erforderlich sind."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:81
@@ -179,8 +180,8 @@
 "all underlying cluster code uses a straight new <literal>InitialContext()</"
 "literal> to lookup or create bindings."
 msgstr ""
-"Aufgrund dieses Entwurfs ist der HA-JNDI Service ein optionaler Dienst, da "
-"alle zugrunde liegenden Clustercodes einen neuen <literal>InitialContext()</"
+"Aufgrund dieses Entwurfs ist der HA-JNDI-Dienst ein optionaler Dienst, da "
+"der gesamte zugrunde liegende Cluster Code einen neuen <literal>InitialContext()</"
 "literal> verwendet, um Bindings zu suchen oder zu erstellen."
 
 #. Tag: para
@@ -193,10 +194,8 @@
 "homes and such will not be bound to the cluster-wide JNDI Context, but "
 "rather, each home will be bound into the local JNDI."
 msgstr ""
-"Auf der Serverseite wird ein benennender <literal>Context</literal>, der bezogen wird via eines Aufrufs an einen neuen <literal>InitialContext()</literal>, an einen ausschließlich lokalen, nicht clusterweiten JNDI-Context gebunden "
-"(es handelt sich dabei um elementares JNDI). Sämtliche EJB-Homes werden "
-"nicht in den clusterweiten JNDI-Context eingebunden, sondern jedes Home wird "
-"in die lokale JNDI eingebunden."
+"Auf der Serverseite wird ein Naming-<literal>Context</literal>, der bezogen wird via eines Aufrufs an einen neuen <literal>InitialContext()</literal>, an einen ausschließlich lokalen, nicht clusterweiten JNDI-Context gebunden "
+"(es handelt sich dabei um elementares JNDI). Sämtliche EJB-Homes werden nicht an den clusterweiten JNDI-Context gebunden, sondern jedes Home wird an die lokale JNDI gebunden."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:95
@@ -205,13 +204,13 @@
 "When a remote client does a lookup through HA-JNDI, HA-JNDI will delegate to "
 "the local JNDI Context when it cannot find the object within the global "
 "cluster-wide Context. The detailed lookup rule is as follows."
-msgstr "Wenn ein Remote Client eine Suche mittels HA-JNDI durchführt, so sendet HA-JNDI an den lokalen JNDI-Context, wenn es das Objekt im globalen, clusterweiten Context nicht findet. Die genau Lookup-Regel lautet wie folgt. "
+msgstr "Wenn ein Remote Client eine Suche mittels HA-JNDI durchführt, dann delegiert HA-JNDI an den lokalen JNDI-Context, wenn es das Objekt im globalen, clusterweiten Context nicht findet. Die genau Lookup-Regel lautet wie folgt."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:100
 #, no-c-format
 msgid "If the binding is available in the cluster-wide JNDI tree, return it."
-msgstr "Falls das Binding im clusterweiten JNDI-Tree verfügbar ist und es beantwortet."
+msgstr "Falls das Binding im clusterweiten JNDI-Tree verfügbar ist, wird es zurückgegeben."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:103
@@ -219,7 +218,7 @@
 msgid ""
 "If the binding is not in the cluster-wide tree, delegate the lookup query to "
 "the local JNDI service and return the received answer if available."
-msgstr "Falls das Binding im clusterweiten Tree nicht verfügbar ist, sendet es die Lookup-Anfrage an den lokalen JNDI-Dienst und schickt die erhaltene Antwort (falls verfügbar) zurück."
+msgstr "Falls das Binding im clusterweiten Tree nicht verfügbar ist, wird die Lookup-Anfrage an den lokalen JNDI-Dienst delegiert und die erhaltene Antwort (falls verfügbar) zurückgegeben."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:106
@@ -228,7 +227,7 @@
 "If not available, the HA-JNDI services asks all other nodes in the cluster "
 "if their local JNDI service owns such a binding and returns the answer from "
 "the set it receives."
-msgstr "Falls keine Antwort verfügbar ist, fragt der HA-JNDI-Dienst bei allen anderen Nodes im Cluster an, ob deren lokaler JNDI-Dienst über ein solches Binding verfügt und schickt die erhaltene Antwort zurück."
+msgstr "Falls keine Antwort verfügbar ist, fragt der HA-JNDI-Dienst bei allen anderen Nodes im Cluster an, ob deren lokaler JNDI-Dienst über ein solches Binding verfügt und sendet die erhaltene Antwort zurück."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:109
@@ -237,8 +236,8 @@
 "If no local JNDI service owns such a binding, a "
 "<literal>NameNotFoundException</literal> is finally raised."
 msgstr ""
-"Falls kein lokaler JNDI-Dienst ein solches Binding besitzt, erscheint "
-"schließlich die Meldung <literal>NameNotFoundException</literal>."
+"Falls kein lokaler JNDI-Dienst ein solches Binding besitzt, wird"
+"schließlich die Ausnahme <literal>NameNotFoundException</literal> ausgegeben."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:113
@@ -249,14 +248,14 @@
 "their proxies are always bound in local JNDI, not HA-JNDI. So, an EJB home "
 "lookup done through HA-JNDI will always be delegated to the local JNDI "
 "instance."
-msgstr "In der Praxis sind Objekte selten an den clusterweiten JNDI-Tree gebunden, sondern meist an den lokalen JNDI-Tree gebunden. Wenn z. B. EJBs deployt werden, sind ihre Proxys immer an die lokale JNDI gebunden, nicht JA-JNDI. Also wird ein EJB Home Lookup durch HA-JNDI immer an die lokale JNDI-Instanz delegiert werden."
+msgstr "In der Praxis sind Objekte selten an den clusterweiten JNDI-Tree gebunden, sondern meist an den lokalen JNDI-Tree. Wenn z. B. EJBs deployt werden, sind ihre Proxys immer an die lokale JNDI gebunden, nicht an HA-JNDI. Ein EJB-Home-Lookup mittels HA-JNDI wird also immer an die lokale JNDI-Instanz weitergeleitet."
 
 #. Tag: title
 #: Clustering_Guide_JNDI.xml:117 Clustering_Guide_JNDI.xml:124
 #: Clustering_Guide_JNDI.xml:130
 #, no-c-format
 msgid "Note"
-msgstr "Anmerkungen"
+msgstr "Anmerkung"
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:118
@@ -273,10 +272,9 @@
 "that across the cluster different names are used for logically different "
 "bindings."
 msgstr ""
-"Falls unterschiedliche Beans (auch wenn sie zu "
-"demselben Bean-Typ gehören, jedoch Teil verschiedener Cluster sind) "
+"Falls unterschiedliche Beans (auch wenn sie zu demselben Bean-Typ gehören, jedoch Teil verschiedener Cluster sind) "
 "denselben JNDI-Namen verwenden, so bedeutet dies, dass jeder JNDI-Server "
-"eine andere \"Target\"-Verbindung hat (JNDI an Node 1 besitzt ein Binding "
+"eine andere \"Ziel\"-Verbindung hat (JNDI an Node 1 besitzt ein Binding "
 "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-Anfrage für diesen Namen "
 "durchführt, wird diese an einem beliebigen JNDI-Server des Clusters "
@@ -293,7 +291,7 @@
 "JNDI federation using the ExternalContext MBean to bind non-JBoss JNDI trees "
 "into the JBoss JNDI namespace. Furthermore, nothing prevents you using one "
 "centralized JNDI server for your whole cluster and scrapping HA-JNDI and JNP."
-msgstr "Wenn Sie HA-JNDI verwenden möchten, können Sie zur Zeit keine nicht-JNP JNDI-Implementierung (d.h. LDAP) für Ihre lokale JNDI-Implementierung benutzen. Sie können jedoch JNDI-Federation mit dem ExternalContext MBean verwenden, um nicht-JBoss JNDI-Trees in den JBoss JNDI-Namespace (\"Namensraum\") einzubinden. Desweiteren können Sie einen zentralisierten JNDI-Server für Ihren gesamten Cluster einsetzen und anstelle von HA-JNDI und JNP verwenden."
+msgstr "Wenn Sie HA-JNDI verwenden möchten, können Sie zur Zeit keine nicht-JNP JNDI-Implementierung (d. h. LDAP) für Ihre lokale JNDI-Implementierung benutzen. Sie können jedoch JNDI-Federation mit dem ExternalContext-MBean verwenden, um nicht-JBoss JNDI-Trees in den JBoss JNDI-Namensraum einzubinden. Desweiteren können Sie einen zentralisierten JNDI-Server für Ihren gesamten Cluster einsetzen und anstelle von HA-JNDI und JNP verwenden."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:131
@@ -307,12 +305,12 @@
 "than if the binding would have been available locally. Moral of the story: "
 "as much as possible, cache the result of your JNDI queries in your client."
 msgstr ""
-"Falls ein Binding nur an wenigen Nodes des Clusters verfügbar ist (z.B. weil "
+"Falls ein Binding nur an wenigen Nodes des Clusters verfügbar ist (z. B. weil "
 "ein Bean nur an einem kleinen Teilsatz von Nodes im Cluster deployt wird), "
 "ist die Wahrscheinlichkeit, einen HA-JNDI Server zu finden, der dieses "
 "Binding nicht besitzt, höher, und der Lookup wird an alle Nodes im Cluster "
 "weitergeleitet werden müssen. Die Anfrage wird folglich mehr Zeit "
-"beanspruchen als wenn das Binding lokal verfügbar gewesen wäre. Es ist daher "
+"beanspruchen, als wenn das Binding lokal verfügbar gewesen wäre. Es ist daher "
 "sinnvoll, die Ergebnisse Ihrer JNDI-Anfragen möglichst oft in Ihrem Client "
 "zu speichern."
 
@@ -331,16 +329,15 @@
 "correct stub that the client is expecting to receive!"
 msgstr ""
 "Ein EJB-Home-Lookup mittels HA-JNDI wird also immer an die lokale JNDI-"
-"Instanz weitergeleitet. Falls unterschiedliche Beans (auch wenn sie zu "
-"demselben Bean-Typ gehören, jedoch Teil verschiedener Cluster sind) "
+"Instanz weitergeleitet. Falls unterschiedliche Beans (auch wenn sie zu demselben Bean-Typ gehören, jedoch Teil verschiedener Cluster sind) "
 "denselben JNDI-Namen verwenden, so bedeutet dies, dass jeder JNDI-Server "
-"eine andere \"Target\"-Verbindung hat (JNDI an Node 1 besitzt ein Binding "
+"eine andere \"Ziel\"-Verbindung hat (JNDI an Node 1 besitzt ein Binding "
 "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-Anfrage 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 "
 "möglich, dass es sich dabei nicht um den korrekten Stub handelt, den der "
-"Client zu erhalten erwartet!"
+"Client zu erhalten erwartet! Daher ist die beste Vorgehensweise, sicherzustellen, dass im Cluster durchweg verschiedene Namen für logisch verschiedene Bindings verwendet werden."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:147
@@ -352,7 +349,7 @@
 "non-JBoss JNDI trees into the JBoss JNDI namespace. Furthermore, nothing "
 "prevents you though of using one centralized JNDI server for your whole "
 "cluster and scrapping HA-JNDI and JNP."
-msgstr "Wenn Sie HA-JNDI verwenden möchten, können Sie zur Zeit keine nicht-JNP JNDI-Implementierung (d.h. LDAP) für Ihre lokale JNDI-Implementierung benutzen. Sie können jedoch JNDI-Federation mit dem <literal>ExternalContext</literal>-MBean verwenden, um nicht-JBoss JNDI-Trees in den JBoss JNDI-Namespace (\"Namensraum\") einzubinden. Desweiteren können Sie einen zentralisierten JNDI-Server für Ihren gesamten Cluster einsetzen und anstelle von HA-JNDI und JNP verwenden."
+msgstr "Wenn Sie HA-JNDI verwenden möchten, können Sie zur Zeit keine nicht-JNP JNDI-Implementierung (d. h. LDAP) für Ihre lokale JNDI-Implementierung benutzen. Sie können jedoch JNDI-Federation mit dem ExternalContext-MBean verwenden, um nicht-JBoss JNDI-Trees in den JBoss JNDI-Namensraum einzubinden. Desweiteren können Sie einen zentralisierten JNDI-Server für Ihren gesamten Cluster einsetzen und anstelle von HA-JNDI und JNP verwenden."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:154
@@ -366,12 +363,12 @@
 "would have been available locally. Moral of the story: as much as possible, "
 "cache the result of your JNDI queries in your client."
 msgstr ""
-"Falls ein Binding nur an wenigen Nodes des Clusters verfügbar ist (z.B. weil "
+"Falls ein Binding nur an wenigen Nodes des Clusters verfügbar ist (z. B. weil "
 "ein Bean nur an einem kleinen Teilsatz von Nodes im Cluster deployt wird), "
 "ist die Wahrscheinlichkeit, einen HA-JNDI Server zu finden, der dieses "
 "Binding nicht besitzt, höher, und der Lookup wird an alle Nodes im Cluster "
 "weitergeleitet werden müssen. Die Anfrage wird folglich mehr Zeit "
-"beanspruchen als wenn das Binding lokal verfügbar gewesen wäre. Es ist daher "
+"beanspruchen, als wenn das Binding lokal verfügbar gewesen wäre. Es ist daher "
 "sinnvoll, die Ergebnisse Ihrer JNDI-Anfragen möglichst oft in Ihrem Client "
 "zu speichern."
 
@@ -385,7 +382,7 @@
 #: Clustering_Guide_JNDI.xml:168
 #, no-c-format
 msgid "For clients running inside the application server"
-msgstr "Für Clients, die innerhalb des Anwendungsservers laufen"
+msgstr "Für Clients, die innerhalb des Anwendungsservers ausgeführt werden"
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:169
@@ -424,7 +421,7 @@
 msgid ""
 "The Context.PROVIDER_URL property points to the HA-JNDI service configured "
 "in the HANamingService MBean (see the section called “JBoss configuration”)."
-msgstr "Die Context.PROVIDER_UR-Eigenschaft zeigt auf den im HANamingService-MBean (siehe Abschnitt \"Die JBoss-Konfiguration\") konfigurierten HA-JNDI-Dienst."
+msgstr "Die Context.PROVIDER_UR-Eigenschaft zeigt auf den im HANamingService-MBean (siehe Abschnitt \"Die JBoss Konfiguration\") konfigurierten HA-JNDI-Dienst."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:176
@@ -434,7 +431,7 @@
 "homed cluster (several JBoss instances on one machine bound to different "
 "IPs). A safer method is not to specify the Context.PROVIDER_URL (which does "
 "not work in all scenarios) but the partition name property:"
-msgstr "Allerdings funktioniert dies nicht in jedem Fall, insbesondere bei Verwendung von \"Multi-Home\"-Clustern (mehrere JBoss-Instanzen auf einer Maschine, gebunden an verschiedene IPs). Eine sichereres Verfahren ist es, nicht die Context.PROVIDER_URL (die nicht in allen Szenarien funktioniert) zu spezifizieren, sondern die Namenseigenschaft der Partition:"
+msgstr "Allerdings funktioniert dies nicht in jedem Fall, insbesondere bei Verwendung von \"Multi-Home\"-Clustern (mehrere JBoss Instanzen auf einer Maschine, gebunden an verschiedene IPs). Eine sichereres Verfahren ist es, nicht die Context.PROVIDER_URL (die nicht in allen Szenarien funktioniert) zu spezifizieren, sondern die Namenseigenschaft der Partition:"
 
 #. Tag: programlisting
 #: Clustering_Guide_JNDI.xml:179
@@ -461,6 +458,7 @@
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:180
 #, no-c-format
+#, fuzzy
 msgid ""
 "Do not attempt to simplify things by placing a jndi.properties file in your "
 "deployment or by editing the AS's conf/jndi.properties file. Doing either "
@@ -469,13 +467,16 @@
 "configuration, one approach is to deploy a properties file not named jndi."
 "properties, and then programatically create a Properties object that loads "
 "that file's contents."
-msgstr "Versuchen Sie nicht, die Dinge zu vereinfachen, indem Sie eine jndi.properties-Datei in Ihr Deployment platzieren oder indem Sie die AS's conf/jndi.properties-Datei bearbeiten. Beides würde mit größter Wahrscheinlichkeit schwerwiegende Fehler in Ihrer Anwendung verursachen, sowie möglicherweise im Anwendungsserver. Wenn Sie Ihre Client-Konfiguration externalisieren möchten, besteht eine Herangehensweise darin, eine Eigenschaftsdatei zu deployen, die nicht jndi.properties heißt, und anschließend mithilfe eines Programms ein Eigenschaftsobjekt zu erstellen, das die Inhalte dieser Datei lädt."
+msgstr ""
+"Versuchen Sie nicht, die Dinge zu vereinfachen, indem Sie eine jndi.properties-Datei in Ihr Deployment platzieren oder indem Sie die conf/jndi.properties-Datei des AS bearbeiten. Beides würde mit größter Wahrscheinlichkeit Ihre Anwendung beschädigen, möglicherweise auch den Anwendungsserver. Wenn Sie Ihre Client-Konfiguration externalisieren möchten, besteht eine Herangehensweise darin, eine Eigenschaftsdatei zu deployen, die nicht jndi.properties heißt, und anschließend mithilfe eines Programms ein Eigenschaftsobjekt zu erstellen, das die Inhalte dieser Datei lädt. "
+"externalize = expose, accessible from the outside? (offenlegen)"
+"externalize = take it out, place it somewhere out of the system (ausgliedern)"
 
 #. Tag: title
 #: Clustering_Guide_JNDI.xml:187
 #, no-c-format
 msgid "For clients running outside the application server"
-msgstr "Für Clients, die außerhalb des Anwendungsservers laufen"
+msgstr "Für Clients, die außerhalb des Anwendungsservers ausgeführt werden"
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:189
@@ -488,7 +489,7 @@
 "its IP address and the JNDI port number. The server nodes are separated by "
 "commas (see <xref linkend=\"clustering-jndi-jboss\"/> for how to configure "
 "the servers and ports)."
-msgstr "Der JNDI-Client muss Kenntnis vom HA-JNDI Cluster haben. Sie können eine Auflistung der JNDI-Server (d. h. den Nodes im HA-JNDI-Cluster) an die<literal>java.naming.provider.url</literal> JNDI-Einstellung der <literal>jndi.properties</literal>-Datei senden. Jeder Server-Node wird anhand seiner IP-Adresse und der JNDI-Portnummer identifiziert. Die einzelnen Server-Nodes sind durch Kommas getrennt (siehe <xref linkend=\"clustering-jndi-jboss\"/> zur Konfiguration von Servern und Ports)."
+msgstr "Der JNDI-Client muss Kenntnis vom HA-JNDI Cluster haben. Sie können eine Auflistung der JNDI-Server (d. h. den Nodes im HA-JNDI-Cluster) an die<literal>java.naming.provider.url</literal> JNDI-Einstellung der <literal>jndi.properties</literal>-Datei übergeben. Jeder Server-Node wird anhand seiner IP-Adresse und der JNDI-Port-Nummer identifiziert. Die einzelnen Server-Nodes sind durch Kommas getrennt (siehe <xref linkend=\"clustering-jndi-jboss\"/> zur Konfiguration von Servern und Ports)."
 
 #. Tag: programlisting
 #: Clustering_Guide_JNDI.xml:191
@@ -507,7 +508,7 @@
 msgstr ""
 "Bei der Initialisierung versucht der JNP-Client Code mit jedem der "
 "gelisteten Server-Nodes in Verbindung zu treten. Er probiert dies bei einem "
-"nach dem anderen bis er einen der Server erreicht hat. Anschließend lädt er "
+"nach dem anderen, bis er einen der Server erreicht hat. Anschließend lädt er "
 "den HA-JNDI Stub dieses Nodes herunter."
 
 #. Tag: para
@@ -518,7 +519,7 @@
 "It just goes through the provider lists and uses the first available server "
 "to obtain the stub. The HA-JNDI provider list only needs to contain a subset "
 "of HA-JNDI nodes in the cluster."
-msgstr "Beim JNP-Client Lookup-Prozess selbst wird keine Lastverteilung verwendet. Die Providerliste wird einfach durchgegangen und der erste verfügbare Server benutzt, um den Stub zu erhalten. Die HA-JNDI-Providerliste muss lediglich einen Teilsatz von HA-JNDI-Nodes im Cluster enthalten."
+msgstr "Beim JNP-Client Lookup-Prozess selbst wird keine Lastverteilung verwendet. Die Provider-Liste wird einfach durchgegangen und der erste verfügbare Server benutzt, um den Stub zu erhalten. Die HA-JNDI-Provider-Liste muss lediglich einen Teilsatz von HA-JNDI-Nodes im Cluster enthalten."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:199
@@ -529,7 +530,7 @@
 "if necessary. Furthermore, each time a JNDI invocation is made to the "
 "server, the list of targets in the proxy interceptor is updated (only if the "
 "list has changed since the last call)."
-msgstr "Der heruntergeladene \"Smart Proxy\" beinhaltet eine Liste der aktuell laufenden Nodes sowie die Logik zur Lastverteilung von Benennungsanfragen und um im Problemfall auf andere Nodes auszuweichen falls nötig. Desweiteren wird jedes Mal, wenn ein JNDI-Aufruf beim Server eingeht, die Liste der Targets im Stub-Interzeptor aktualisiert (jedoch nur wenn sich die Liste seit dem letzten Aufruf verändert hat)."
+msgstr "Der heruntergeladene \"Smart Proxy\" beinhaltet neben einer Liste der aktuell laufenden Nodes auch die Logik, um Lastverteilung von Naming-Anfragen durchzuführen, und um im Problemfall auf andere Server auszuweichen. Desweiteren wird jedes Mal, wenn ein JNDI-Aufruf beim Server eingeht, die Liste der Ziele im Stub-Interzeptor aktualisiert (jedoch nur wenn sich die Liste seit dem letzten Aufruf verändert hat)."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:203
@@ -545,7 +546,7 @@
 "server cluster must be configured to propagate such multicast datagrams."
 msgstr ""
 "Falls der Eigenschafts-String java.naming.provider.url leer ist oder keiner der aufgeführten Server erreichbar ist, "
-"versucht der JNP-Client mittels Multicast-Call am Netzwerk (Auto-Discovery) einen HA-JNDI Server zu finden. Zur Konfiguration von Auto-Discovery auf den JNDI-Server-Nodes werfen Sie bitte einen Blick auf den Abschnitt \"Die JBoss-Konfiguration\". Mit Auto-Discovery ist es möglich, dass der Client einen gültigen HA-JNDI-Server-Node ohne Konfiguration findet. "
+"versucht der JNP-Client mittels Multicast-Call am Netzwerk (Auto-Discovery) einen HA-JNDI Server zu finden. Zur Konfiguration von Auto-Discovery auf den JNDI-Server-Nodes lesen Sie bitte den Abschnitt \"Die JBoss Konfiguration\". Mit Auto-Discovery ist es möglich, dass der Client einen gültigen HA-JNDI-Server-Node ohne Konfiguration findet. "
 "Natürlich müssen die Netzwerksegmente zwischen dem Client und dem Server-Cluster so konfiguriert sein, dass derartige Multicast-Datagramme fortgepflanzt werden, damit Auto-Discovery funktioniert."
 
 #. Tag: para
@@ -568,7 +569,7 @@
 msgstr ""
 "Neben der <literal>java.naming.provier.url</literal>-Eigenschaft können Sie "
 "auch einen Satz anderer Eigenschaften festlegen. Die folgende Liste zeigt alle "
-"Clustering-bezogenen, clientbasierten Eigenschaften, die Sie bei der Erstellung eines neuen InitialContext festlegen können. (Alle standardmäßigen, nicht-Clustering-bezogenen Umgebungseigenschaften zur Verwendung mit regulären JNDI sind ebenfalls verfügbar.)"
+"clientbasierten Eigenschaften bezüglich Clustering, die Sie bei der Erstellung eines neuen InitialContext festlegen können. (Alle nicht auf Clustering bezogenen Standardumgebungseigenschaften, die mit regulären JNDI verwendet werden, sind ebenfalls verfügbar.)"
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:212
@@ -577,7 +578,7 @@
 "<literal>java.naming.provider.url</literal>: Provides a list of IP addresses "
 "and port numbers for HA-JNDI provider nodes in the cluster. The client tries "
 "those providers one by one and uses the first one that responds."
-msgstr "<literal>java.naming.provider.url</literal>: Liefert eine Liste von IP-Adressen und Portnummern für HA-JNDI-Provider-Nodes im Cluster. Der Client probiert diese Provider einen nach dem anderen durch und verwendet den zuerst reagierenden."
+msgstr "<literal>java.naming.provider.url</literal>: Liefert eine Liste von IP-Adressen und Port-Nummern für HA-JNDI-Provider-Nodes im Cluster. Der Client probiert diese Provider einen nach dem anderen durch und verwendet den zuerst reagierenden."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:217
@@ -588,8 +589,7 @@
 "<literal>false</literal>."
 msgstr ""
 "<literal>jnp.disableDiscovery</literal>: Wenn die Einstellung <literal>true</"
-"literal> vorliegt, deaktiviert diese Property das Automatic-Discovery-"
-"Feature. Der voreingestellte Wert lautet <literal>false</literal>."
+"literal> vorliegt, deaktiviert diese Eigenschaft das Automatic-Discovery-Feature. Der voreingestellte Wert lautet <literal>false</literal>."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:222
@@ -603,7 +603,7 @@
 "property is not used. By default, this property is not set and the automatic "
 "discovery select the first HA-JNDI server that responds, irregardless of the "
 "cluster partition name."
-msgstr "<literal>jnp.partitionName</literal>: In einer Umgebung, in der mehrere, an eindeutige Cluster (d.h. Partitionen) gebundene HA-JNDI-Dienste gestartet werden, haben Sie mit dieser Eigenschaft die Möglichkeit sicherzustellen, dass Ihr Client ausschließlich Automatic-Discovery-Antworten von Servern der gewünschten Partition akzeptiert. Falls Sie das Automatic-Discovery Feature nicht verwenden (d. h. jnp.disableDiscovery ist \"true\"), so wird diese Eigenschaft nicht benutzt. Diese Property ist nicht als Standard eingestellt, und Automatic-Discovery wählt den ersten HA-JNDI-Server der reagiert, ganz unabhängig vom Partitionsnamen des Clusters."
+msgstr "<literal>jnp.partitionName</literal>: In einer Umgebung, in der mehrere, an eindeutige Cluster (d. h. Partitionen) gebundene HA-JNDI-Dienste gestartet werden, haben Sie mit dieser Eigenschaft die Möglichkeit sicherzustellen, dass Ihr Client ausschließlich Automatic-Discovery-Antworten von Servern der gewünschten Partition akzeptiert. Falls Sie das Automatic-Discovery Feature nicht verwenden (d. h. jnp.disableDiscovery ist \"true\"), so wird diese Eigenschaft nicht benutzt. Diese Eigenschaft ist nicht als Standard eingestellt, und Automatic-Discovery wählt den ersten HA-JNDI-Server, der reagiert, ganz unabhängig vom Partitionsnamen des Clusters."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:225
@@ -614,7 +614,7 @@
 "is 5000 ms."
 msgstr ""
 "<literal>jnp.discoveryTimeout</literal>: Bestimmt, wie lange der Context auf "
-"Antwort auf sein Automatic-Discovery-Packet wartet. Der voreingestellte Wert "
+"Antwort auf sein Automatic-Discovery-Paket wartet. Der voreingestellte Wert "
 "ist 5000 ms."
 
 #. Tag: para
@@ -625,7 +625,7 @@
 "address is used for the automatic discovery. Default is 230.0.0.4. Must "
 "match the value of the AutoDiscoveryAddress configured on the server side HA-"
 "JNDI service."
-msgstr "<literal>jnp.discoveryGroup</literal>: Bestimmt, welche Multicast-Gruppenadresse für Automatic-Discovery verwendet wird. Der voreingestellte Wert ist 230.0.0.4. Muss dem Wert der AutoDiscoveryAddress entsprechen, der auf dem serverseitigen HA-JNDI-Dienst eingestellt ist."
+msgstr "<literal>jnp.discoveryGroup</literal>: Bestimmt, welche Multicast-Gruppenadresse für Automatic-Discovery verwendet wird. Der voreingestellte Wert ist 230.0.0.4. Muss dem Wert der AutoDiscoveryAddress entsprechen, der auf dem serverbasierten HA-JNDI-Dienst konfiguriert ist."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:232
@@ -634,7 +634,7 @@
 "<literal>jnp.discoveryPort</literal>: Determines which multicast group port "
 "is used for the automatic discovery. Default is 1102. Must match the value "
 "of the AutoDiscoveryPort configured on the server side HA-JNDI service."
-msgstr "<literal>jnp.discoveryPort</literal>: Bestimmt welcher Multicast-Gruppenport für Automatic-Discovery verwendet wird. Der voreingestellte Wert ist 1102. Muss dem Wert des AutoDiscoveryPort entsprechen, der auf dem serverseitigen HA-JNDI-Dienst eingestellt ist."
+msgstr "<literal>jnp.discoveryPort</literal>: Bestimmt, welcher Multicast-Gruppen-Port für Automatic-Discovery verwendet wird. Der voreingestellte Wert ist 1102. Muss dem Wert des AutoDiscoveryPort entsprechen, der auf dem serverbasierten HA-JNDI-Dienst konfiguriert ist."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:235
@@ -645,15 +645,13 @@
 "network hops a multicast packet can be allowed to propagate before "
 "networking equipment should drop the packet. Despite its name, it does not "
 "represent a unit of time."
-msgstr ""
-"<literal>jnp.discoveryTTL</literal>: Spezifiziert die TTL (time-to-live, \"Lebenszeit\") für Autodiscovery IP Multicast-Pakete. Dieser Wert stellt die Anzahl der Netzwerksprünge dar, die ein Multicast-Paket fortpflanzen darf, bevor die Netzwerkgeräte das Paket fallenlassen sollten. Trotz seines Namens stellt es keine Zeiteinheit dar. "
-"(vgl 69)"
+msgstr "<literal>jnp.discoveryTTL</literal>: Spezifiziert die TTL (time-to-live, \"Lebenszeit\") für Autodiscovery-IP-Multicast-Pakete. Dieser Wert repräsentiert die Anzahl der Router (\"Network Hops\"), über die ein Multicast-Paket weitergereicht werden darf, bevor die Netzwerkgeräte das Paket fallenlassen sollten. Trotz seines Namens stellt es keine Zeiteinheit dar."
 
 #. Tag: title
 #: Clustering_Guide_JNDI.xml:246
 #, no-c-format
 msgid "JBoss configuration"
-msgstr "Die JBoss-Konfiguration"
+msgstr "Die JBoss Konfiguration"
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:247
@@ -661,10 +659,7 @@
 msgid ""
 "The <literal>cluster-service.xml</literal> file in the <literal>all/deploy</"
 "literal> directory includes the following MBean to enable HA-JNDI services."
-msgstr ""
-"Die <literal>cluster-service.xml</literal> Datei im <literal>all/deploy</"
-"literal>-Verzeichnis enthält das folgende MBean zur Aktivierung von HA-NDI "
-"Diensten."
+msgstr "Die <literal>cluster-service.xml</literal>-Datei im <literal>all/deploy</literal>-Verzeichnis enthält das folgende MBean zur Aktivierung von HA-JNDI-Diensten."
 
 #. Tag: programlisting
 #: Clustering_Guide_JNDI.xml:249
@@ -714,7 +709,7 @@
 "communication."
 msgstr ""
 "Bei <emphasis role=\"bold\">Cluster Partition</emphasis> handelt es sich um ein "
-"erforderliches Attribut, um den HAPartition-Dienst, den HA-HNDI verwendet, für intra-Cluster-Kommunikation einzuspeisen."
+"erforderliches Attribut, um den HAPartition-Dienst einzuspeisen, den HA-JNDI für intra-Cluster-Kommunikation verwendet."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:259
@@ -728,7 +723,7 @@
 "is set if the -b command line switch is used when JBoss is started."
 msgstr ""
 "Bei <emphasis role=\"bold\">BindAddress</emphasis> handelt es sich um ein optionales Attribut zur Bestimmung der Adresse, mit der sich der HA-JNDI-Server verbindet, während er auf JNP-Clients wartet. Dies ist nur bei "
-"\"Multi-Home\"-Computern sinnvoll. Der Standardwert ist der Wert der jboss.bind.address-Systemeigenschaft, oder, falls diese Eigenschaft nicht gesetzt ist, die Standardadresse des Hosts. Die jboss.bind.address-Systemeigenschaft wird gesetzt, wenn der -b Befehlszeilenschalter beim Start von JBoss angewendet wird."
+"\"Multi-Home\"-Computern sinnvoll. Der Standardwert entspricht dem Wert der jboss.bind.address-Systemeigenschaft, oder, falls diese Eigenschaft nicht gesetzt ist, der Standardadresse des Hosts. Die jboss.bind.address-Systemeigenschaft wird gesetzt, wenn der -b Befehlszeilenschalter beim Start von JBoss angewendet wird."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:262
@@ -739,8 +734,8 @@
 "default value is <literal>1100</literal>."
 msgstr ""
 "Bei <emphasis role=\"bold\">Port</emphasis> handelt es sich um ein "
-"optionales Attribut mit dem der Port festgelegt wird, mit dem sich der HA-"
-"JNDI Server verbindet, während er auf JNP-Clients wartet. Die "
+"optionales Attribut, mit dem der Port festgelegt wird, mit dem sich der HA-"
+"JNDI-Server verbindet, während er auf JNP-Clients wartet. Die "
 "Standardeinstellung lautet <literal>1100</literal>."
 
 #. Tag: para
@@ -789,7 +784,7 @@
 "system property, or 230.0.0.4 if that is not set. The jboss.partition."
 "udpGroup system property is set if the -u command line switch is used when "
 "JBoss is started."
-msgstr "Bei <emphasis role=\"bold\">AutoDiscoveryAddress</emphasis> handelt es sich um ein optionales Attribut zur Bestimmung der Multicast-Adresse, die auf JNDI-Automatic-Discovery lauscht. Der Standardwert ist der Wert der jboss.partition.udpGroup-Systemeigenschaft, oder 230.0.0.4, falls diese nicht gesetzt ist. Die jboss.partition.udpGroup-Systemeigenschaft wird gesetzt, wenn der -u Befehlszeilenschalter beim Start von JBoss angewendet wird."
+msgstr "Bei <emphasis role=\"bold\">AutoDiscoveryAddress</emphasis> handelt es sich um ein optionales Attribut zur Bestimmung der Multicast-Adresse, auf die für JNDI-Automatic-Discovery gelauscht wird. Der Standardwert entspricht dem Wert der jboss.partition.udpGroup-Systemeigenschaft, oder 230.0.0.4, falls diese nicht gesetzt ist. Die jboss.partition.udpGroup-Systemeigenschaft wird gesetzt, wenn der -u Befehlszeilenschalter beim Start von JBoss angewendet wird."
 
 #. Tag: para
 #: Clustering_Guide_JNDI.xml:284