Scott Stark wrote:
> 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
change.
Can't comment about the removal of [], except that if URLs are later
formed, they will probably need to be
reinstated.
> 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@...
> >>>
https://lists.jboss.org/mailman/listinfo/jboss-development> >>>
> >>>
> >> _______________________________________________
> >> jboss-development mailing list
> >>
jboss-development@...
> >>
https://lists.jboss.org/mailman/listinfo/jboss-development> >>
> > _______________________________________________
> > jboss-development mailing list
> >
jboss-development@...
> >
https://lists.jboss.org/mailman/listinfo/jboss-development> >
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jboss-development mailing list
>
jboss-development@...
>
https://lists.jboss.org/mailman/listinfo/jboss-development>
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development
