Update CHANGELOG and docs to more accurately reflect the necessarily imperfect detection of the locality of JNDI names.

Author: swaldman

CHANGELOG

@@ -10,8 +10,9 @@
 	   custom environment. Define properties-style config parameter
 	   com.mchange.v2.naming.acceptDeserializedInitialContextEnvironment, defaulting to false,
 	   to manage this dangerous functionality.
-	-- Disable by default JNDI lookups of nonlocal names (conservatively, names we cannot prove to be local).
-	   For now only String names beginning with "java:" are considered provably local.
+	-- Disable by default JNDI lookups of nonlocal names (conservatively, names that do not seem to be local).
+	   For now only String names beginning with "java:" or Name objects whose first component starts with
+	   "java:" are considered to be local.
 	   Define properties-style config parameter com.mchange.v2.naming.permitNonlocalJndiNames, defaulting
 	   to false, to manage this dangerous functionality.
 	-- Disable by default support for loading of javax.naming.spi.ObjectFactory from remote locations

doc/docsrc/index.html

@@ -1956,7 +1956,9 @@ <h3>
 	<dd>
 	  <div class="propdesc">
             <tt>false</tt> by default. If reset to <tt>true</tt>, utilities like <tt>JndiRefForwardingDataSource</tt> will be permitted
-            to look up resources from remote name services. Otherwise JNDI lookups are restricted to the local <tt>java:</tt> namespace.
+            to make lookups that are suspected of being to remote name services. When false, JNDI lookups are restricted to names beginning
+            with "<tt>java:</tt>" JNDI is too malleable to make strong guarantees about this: Any name can be interpreted any way, depending
+            on how JNDI is configured. But under most common configurations <tt>java:</tt> prefixed names should be to local resources.
 	  </div>
 	</dd>
 	<dt><a name="com.mchange.v2.naming.acceptDeserializedInitialContextEnvironment"></a>com.mchange.v2.naming.acceptDeserializedInitialContextEnvironment</dt>