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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Bartosz Baranowski
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Jaikiran Pai
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Bartosz Baranowski
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" <[hidden email]>
> To: "Bartosz Baranowski" <[hidden email]>
> Cc: [hidden email]
> 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
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Jaikiran Pai
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" <[hidden email]>
>> To: "Bartosz Baranowski" <[hidden email]>
>> Cc: [hidden email]
>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Jaikiran Pai
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" <[hidden email]>
>>> To: "Bartosz Baranowski" <[hidden email]>
>>> Cc: [hidden email]
>>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Bartosz Baranowski
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" <[hidden email]>
> To: "Bartosz Baranowski" <[hidden email]>
> Cc: [hidden email]
> 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" <[hidden email]>
> >>> To: "Bartosz Baranowski" <[hidden email]>
> >>> Cc: [hidden email]
> >>> 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
> >>>> [hidden email]
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

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

Carlo de Wolf
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" <[hidden email]>
>> To: "Bartosz Baranowski" <[hidden email]>
>> Cc: [hidden email]
>> 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" <[hidden email]>
>>>>> To: "Bartosz Baranowski" <[hidden email]>
>>>>> Cc: [hidden email]
>>>>> 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
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev