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?
I believe the same issue arises in all EAP versions (4.2 CP, 4.3 CP and
EAP 5) and so needs
to be fixed in all three. I'm sorry for the confusion on the versioning.
I believe I was looking at
EAP 5 when I first logged the bug, and then moved to EAP 4.2 and 4.3
where the source code
for JNDI was more readily accessible. However, i've been busy with 4.2
and 4.3 and haven't been
able to look at the naming project of EAP 5 yet.
Also, please take note that the patch I initially included on the issue
JBPAPP-2941 does not include the
additional one line change for JNDI autodiscovery which Brian mentions
in the comments
section. I've attached a second patch file (for 4.2) which shows the
Can't comment about the removal of , except that if URLs are later
formed, they will probably need to be
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
>> 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
>>>> to support an alternate syntax using '@' as the host/port
>>>> 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
>>> 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
>>> 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 mailing list
> jboss-development mailing list
jboss-development mailing list