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