[jboss-dev] https://jira.jboss.org/jira/browse/JBPAPP-2941

[David M. Lloyd]

That one looks to me like "not a bug", since the [] are only for URI usage 
and are not really valid for IPv6 addresses in general.  I'd say the 
nonstandard use of [] and @ is the unnecessary notation, though I may be 
missing something else here.

All I can say about the cookie thing is what RFC 2965 says: "Host name (HN) 
means either the host domain name (HDN) or the numeric Internet Protocol 
(IP) address of a host.  The fully qualified domain name is preferred; use 
of numeric IP addresses is strongly discouraged."  It doesn't seem to 
mention IPv6 at all...

Tracking back the cookie exception to the underlying service, and requiring 
that service to be configured with a proper domain name, seems like the 
logical step to me.

(I'll copy this into the ticket...)

- DML

On 10/26/2009 08:05 PM, Richard Achmatowicz wrote:
> Is it really necessary to introduce a new notation? Under the assumption
> that the address
> passed in as a Context.PROVIDER_URL is well formed, its easy to separate
> the host from the
> (optional) port. With a few extra lines of code to do this, the original
> failures no longer appear
> when running the testsuite.
>
> In fact, the whole of the EAP 4.2.GA_CP testsuite now seems to run clean
> against IPv6, with the fixes
> to JNDI, aside from the clustering tests where there seems to be a
> problem with explicit IPv6 addresses
> and the use of cookies (https://jira.jboss.org/jira/browse/JBPAPP-3008).
>
> David M. Lloyd wrote:
>> On 10/26/2009 06:39 PM, Scott Stark wrote:
>>
>>> Regarding the IPV6 issue in JBPAPP-2941, there was a change in JBNAME-25
>>> to support an alternate syntax using '@' as the host/port separator:
>>>
>>> "jnp://[3ffe:ffff:100:f101::1]@1099"
>>>
>>> Does this not work for the EAP usage?
>>>
>>
>> A couple problems with this fix - first, it uses InetSocketAddress as a
>> hash key, which contains InetAddress, which can trigger DNS lookups on
>> equals/hashCode; you might get away with this if you only store addresses
>> which you know to be fully resolved, but it's still a bit iffy if you ask
>> me.  I don't know if this was among the fixes that Jason made for the
>> InetAddress-as-key situation.
>>
>> Second, this isn't really RFC compliant at all and will cause URI parsing
>> to crap out.  Is there a problem with using the RFC syntax?  I couldn't
>> find any discussion in the JIRA but I might just be blind
>>
>> - DML
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development