I'm fine with updating the logic as indicated in the patch to look for the last ':'.   The JBPAPP-2941 issue is marked against EAP 5, but the patch is against naming in 4.3. The naming project used in EAP 5 is coming from the standalone naming release. Does this need to be fixed for EAP? If so, I'll integrate the change in https://jira.jboss.org/jira/browse/JBNAME-39. I don't suppose it hurts to keep the parsing to strip leading and trailing [] even though they don't need to be used?

David M. Lloyd wrote: 
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development

      
_______________________________________________
jboss-development mailing list
jboss-development@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
    
_______________________________________________
jboss-development mailing list
jboss-development@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development