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

Fri Sep 6 03:56:13 EDT 2013

Just had a look at how the JNP naming server used to handle this and 
indeed it used to parse it to a CompoundName 
http://anonsvn.jboss.org/repos/jbossas/projects/naming/trunk/jnpserver/src/main/java/org/jnp/interfaces/NamingParser.java. 
Does that change fix the issue you are running into?

-Jaikiran
On Friday 06 September 2013 01:21 PM, Jaikiran Pai wrote:
> I think this
> https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/jboss/as/naming/util/NameParser.java#L49
> should be returning a javax.naming.CompoundName instead of a
> javax.naming.CompositeName.
>
> -Jaikiran
> On Friday 06 September 2013 12:58 PM, Bartosz Baranowski wrote:
>> Yes, they dont behave in the same way. InitialContext.lookup(Name) is called from InitialContext.lookup(String)(from NamingContext):
>>
>>
>> public Object lookup(final String name, boolean dereference) throws NamingException {
>>           return lookup(parseName(name), dereference);
>> }
>>
>> Carlo pointed that this is wrong, since parseName return CompositeName which does not recognize URL types properly - it just cuts what it gets and allows to access pieces. This is why lookup(Name) fails. it just expects proper implementation of javax.naming.Name interface ie. LdapName in case of LDAP context etc. However NamingContext provides CompositeName for any type of context.
>>
>> It would seem that WFLY implementation of lookup(String...) shouldnt use CompositeName or any impl of Name interface unless it can supply proper implementation.
>>
>>
>> ----- Original Message -----
>>> From: "Jaikiran Pai" <jpai at redhat.com>
>>> To: "Bartosz Baranowski" <bbaranow at redhat.com>
>>> Cc: wildfly-dev at lists.jboss.org
>>> Sent: Friday, September 6, 2013 7:30:23 AM
>>> Subject: Re: [wildfly-dev] WFLY-261 & inconsistency in JDK code
>>>
>>> Sorry, I don't understand the problem. Are you saying
>>> InitialContext.lookup(String) and InitialContext.lookup(Name) for the
>>> same JNDI name aren't behaving the same? If yes, then how exactly are
>>> you constructing the Name instance that you pass to the lookup method?
>>>
>>> -Jaikiran
>>> On Tuesday 03 September 2013 05:15 PM, Bartosz Baranowski wrote:
>>>> 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
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev