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

Fri Sep 6 05:20:07 EDT 2013

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
> 
> 