[jboss-cvs] JBossAS SVN: r77409 - in projects/docs/enterprise: 4.3.3/Server_Configuration_Guide/en-US and 1 other directory.

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

Author: irooskov at redhat.com
Date: 2008-08-25 01:54:49 -0400 (Mon, 25 Aug 2008)
New Revision: 77409

Modified:
   projects/docs/enterprise/4.2.5/Server_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
Log:
updated Clustering Section of Server Configuration Guide in Clustering_Guide_JNDI.xml (newly reworked clustering section) with JBPAPP-1003 fix


Modified: projects/docs/enterprise/4.2.5/Server_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
===================================================================
--- projects/docs/enterprise/4.2.5/Server_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml	2008-08-25 05:34:05 UTC (rev 77408)
+++ projects/docs/enterprise/4.2.5/Server_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml	2008-08-25 05:54:49 UTC (rev 77409)
@@ -181,6 +181,16 @@
 The Context.PROVIDER_URL property points to the HA-JNDI service configured in the HANamingService MBean (see the section called “JBoss configuration”).
 </para>
 <para>
+	However, this does not work in all cases, especially when running a multi-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:
+</para>
+<programlisting>
+	Properties p = new Properties();
+	p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
+	p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces");
+	p.put("jnp.partitionName", "DefaultPartition"); // partition name.
+	return new InitialContext(p);
+</programlisting>
+<para>
 	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 will almost certainly break things for your application and quite possibly across the application server. If you want to externalize your client 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.
 </para>
 

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml	2008-08-25 05:34:05 UTC (rev 77408)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml	2008-08-25 05:54:49 UTC (rev 77409)
@@ -181,6 +181,16 @@
 The Context.PROVIDER_URL property points to the HA-JNDI service configured in the HANamingService MBean (see the section called “JBoss configuration”).
 </para>
 <para>
+	However, this does not work in all cases, especially when running a multi-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:
+</para>
+<programlisting>
+	Properties p = new Properties();
+	p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
+	p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces");
+	p.put("jnp.partitionName", "DefaultPartition"); // partition name.
+	return new InitialContext(p);
+</programlisting>
+<para>
 	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 will almost certainly break things for your application and quite possibly across the application server. If you want to externalize your client 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.
 </para>