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

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

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(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 > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev