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

From: "Jaikiran Pai" <jpai(a)redhat.com&gt; To: "Bartosz Baranowski" <bbaranow(a)redhat.com&gt; Cc: wildfly-dev(a)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/sr.... 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/j... > 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(a)redhat.com&gt; >>> To: "Bartosz Baranowski" <bbaranow(a)redhat.com&gt; >>> Cc: wildfly-dev(a)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... >>>> [2] >>>> http://docs.oracle.com/javase/7/docs/api/javax/naming/InitialContext.html... >>>> [3] >>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-... >>>> [4] >>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-... >>>> [5] >>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-... >>>> [6] >>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-... >>>> [7] >>>> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-... >>>> [8] >>>> https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/j... >>>> [9] https://github.com/wildfly/wildfly/pull/4477 >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev