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

Fri Sep 6 07:07:41 EDT 2013

It should be a CompositeName as the URL part points to another namespace.

JNDI 1.3:
"Another example is the Internet URL 
http://www.moon.org/public/index.html, which is a composite name 
representation made up of the scheme-id http from the “URL scheme-id” 
namespace, www.moon.org which is the DNS name of the machine on which 
the web server is running, and public/index.html which is a file name 
from a file namespace."

In the above example "public/index.html" is a CompoundName, consisting 
of "public" and "index.html".

Carlo

On 09/06/2013 11:20 AM, Bartosz Baranowski wrote:
> Yeah, I gave it a chance, since its one of (iirc) 3 available implementations of Name interface. It seems that for this case it makes no difference.
>
> CompositeName vs CompoundName - those are quite the same. Both treat each, separated part of string arg as a ... leaf in directory, so in case of urls:
>
> http://jboss.org:80/dir -> "http:","",jboss.org:80","dir".  Instead of:
> http://jboss.org:80/dir -> "http://jboss.org:80","dir".
>
> Possibly this could be solved by proper syntax to skip to next separator if there are two separators present, but that would be a hack, plus ATM Im not sure if its possible.
>
> ----- 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 9:56:13 AM
>> Subject: Re: [wildfly-dev] WFLY-261 & inconsistency in JDK code
>>
>> 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
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev