Hi,
yes I'm aware the check is no longer needed, in fact we dropped it in
HSEARCH-860, where you can find a short explanation too [1].
So since v.4 it won't prevent IPv6 anymore. Versions 3.x are expected
to be compatible with Java5 so backporting the same patch as
HSEARCH-860 would not be the best option; the solution you propose to
add a system property to give the user a "I know what I'm doing"
option sounds great: if you could send a pull request I'll apply it,
just keep in mind it's needed for 3.4.x only.
1 -
https://hibernate.onjira.com/browse/HSEARCH-860
Sanne
On 29 September 2011 18:41, Zachary Kurey <pushedbytime(a)gmail.com> wrote:
The app I work on needs to bind to ipv6 addresses and to communicate
with
other network nodes using ipv6. The library component that does this
communication breaks if I set 'preferIPV4Stack=true'. I've had to remove
the code that forces this from hibernate-search and
hibernate-search-infinispan and maintain custom libraries in order to use
infinispan. After doing so, everything works fine binding to an ipv6
multicast address. My environment is RHEL4 + JDK 1.6.0.7 + Hibernate Search
3.4.1. I've used jgroups on other applications without having to set
preferIPV4Stack=true(apps that also use ipv6), with no issues other than
needing to ensure that both mcast port, and mcast address are different per
'group'.
Is there any reason to keep this validation in? I understand there are JDK
issues with some OS environments where ipv6 won't work, and this probably
saves a lot of troubleshooting time. Maybe something can be added to allow
an override so the majority of applications are forced to use ipv4, but if
someone really wants ipv6 they can override:
'-Dforce.hibernate.search.ipv6=true'?
ZK
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev