[wildfly-dev] WFLY-261 & inconsistency in JDK code

[Bartosz Baranowski]

Hey guys.

There seems to be inconsistency in GenericURLContext wrt how it handles lookup. This breaks lookups done from AS7/Wfly. Said lookup methods [1] & [2].
The wrongdoer is code in GenericURLContext(so this probably has impact on all URL contexts). 

In case of argument like "rmi://127.0.0.1:1190/jmxrmi" there are two different results. 

If [2] is invoked with above argument it works as expected. It goes down into getURLContext which parse URL part: "rmi://127.0.0.1:1190"
create proper stub( according to URL part ) and gives back ResolveResult.
After above, it nicely asks ResolveResult for context and "remainingName" [4] - in this case, its last bit of original URL: "jmxrmi". This call does not fail.

However if the [1] is used, it goes wrong. Lookup method calls "getContinuationContext" which strips part of URL and call lookup(String) with only "rmi:" [5].
This creates URL stub with default values( in case of RMI for instance ) since implementation assume that if there is no host:port pair, it sets
those values to localhost:1090(which may be different in URL).
This leads to [6] ( since context lookup on remainingName does not give result ). The suffix, which is argument of this call has three parts ["","127.0.0.1:1199","jmxrmi"].
Trick is that object on which [6] is invoked takes only first part of this name, which is empty string. Code which does that [7]. This results in exception which indicates 
that URL is not accessible, while the lookup(String) will return valid object.




Initial stack trace for [1]:
rmiURLContext.getRootURLContext(String, Hashtable) line: 63	
rmiURLContext(GenericURLContext).lookup(String) line: 200	
rmiURLContext(GenericURLContext).getContinuationContext(Name) line: 192	
rmiURLContext(GenericURLContext).lookup(Name) line: 213	
InitialContext.lookup(Name, boolean) line: 112	



Current wildfly code calls the lookup(Name) method[8], which will fail as described above. This PR [9] has testcase which reproduce problem.
Im not quite sure if we can wait for JDK fix( if ever ) since this piece of code is present in JDK7 and 6. Either this piece of code in WFLY remains as is, failing for non localhost:1090 or
there will be nasty Name.toString() in WFLY InitialContext impl( as in [9]).

Any thoughts on this?



[1] http://docs.oracle.com/javase/7/docs/api/javax/naming/InitialContext.html#lookup(javax.naming.Name)
[2] http://docs.oracle.com/javase/7/docs/api/javax/naming/InitialContext.html#lookup(java.lang.String)
[3] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/com/sun/jndi/toolkit/url/GenericURLContext.java#GenericURLContext.lookup%28java.lang.String%29
[4] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/com/sun/jndi/toolkit/url/GenericURLContext.java#203
[5] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/com/sun/jndi/toolkit/url/GenericURLContext.java#192
[6] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/com/sun/jndi/toolkit/url/GenericURLContext.java#215
[7] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/com/sun/jndi/rmi/registry/RegistryContext.java?av=f#114
[8] https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/jboss/as/naming/InitialContext.java#L112
[9] https://github.com/wildfly/wildfly/pull/4477