3:07 p.m.
Provide IP version checking based on @Property processing
---------------------------------------------------------
Key: JGRP-1070
URL: https://jira.jboss.org/jira/browse/JGRP-1070
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.8
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 2.8
With the advent of IPv6 suppport, JGroups needs to be IP version aware, in order to
provide checks such as:
* ensuring that JGroups peers are started us using a set of bind and multicast addresses
which are of a single IP version
* in the case of IPv6 link-local addresses, checking that link-local scopes are present to
eliminate interface ambiguity
Managing many InetAddress and related addresses (such as IpAddress and InetSocketAddress)
which are used in many stack layers within a JGroups stack
is difficult. Especially so when a decision (siuch as which IP version to use) depends
upon having access to all InetAddresses at one point in time.
One way to achieve this is to delay all InetAddress creation until the init() layer of
each protocol, so that initial values for InetAddresses which have been passed in by the
user (or not) may be inspected and a decition made. However, decitions made in one iinit()
layer need to be communicated to the other layers - this is true in trying to assign a
common IP version across all layers.
Another approach is to intercept all InetAddress fields and setter methods during protocol
stack creation, and after properties have been processed. This allows us access to the
entire stack and its InetAddress variables by way of java.lang.reflect.Field and
java.lang.reflect.Method processing.
This is the approach to IP version checking (and other InetAddress related checks) which
will be taken for JGroups.
This approach also makes a nice stack creation-time companion to @Property processing
(including the processing of dependencies and defaults).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:09 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-1070) Provide IP version checking based on @Property processing
[
https://jira.jboss.org/jira/browse/JGRP-1070?page=com.atlassian.jira.plug...
]
Richard Achmatowicz commented on JGRP-1070:
-------------------------------------------
Implemented first version of IP version checking based on Field and Method processing.
All implementation details in Configurator.
Added test case InetAddressChecksTest to check tests for IP version determination and IPv6
scope testing.
Committed to JGroups 2.8 branch.
Provide IP version checking based on @Property processing
---------------------------------------------------------
Key: JGRP-1070
URL: https://jira.jboss.org/jira/browse/JGRP-1070
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.8
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 2.8
With the advent of IPv6 suppport, JGroups needs to be IP version aware, in order to
provide checks such as:
* ensuring that JGroups peers are started us using a set of bind and multicast addresses
which are of a single IP version
* in the case of IPv6 link-local addresses, checking that link-local scopes are present
to eliminate interface ambiguity
Managing many InetAddress and related addresses (such as IpAddress and InetSocketAddress)
which are used in many stack layers within a JGroups stack
is difficult. Especially so when a decision (siuch as which IP version to use) depends
upon having access to all InetAddresses at one point in time.
One way to achieve this is to delay all InetAddress creation until the init() layer of
each protocol, so that initial values for InetAddresses which have been passed in by the
user (or not) may be inspected and a decition made. However, decitions made in one iinit()
layer need to be communicated to the other layers - this is true in trying to assign a
common IP version across all layers.
Another approach is to intercept all InetAddress fields and setter methods during
protocol stack creation, and after properties have been processed. This allows us access
to the entire stack and its InetAddress variables by way of java.lang.reflect.Field and
java.lang.reflect.Method processing.
This is the approach to IP version checking (and other InetAddress related checks) which
will be taken for JGroups.
This approach also makes a nice stack creation-time companion to @Property processing
(including the processing of dependencies and defaults).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:17 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-1070) Provide IP version checking based on @Property processing
[
https://jira.jboss.org/jira/browse/JGRP-1070?page=com.atlassian.jira.plug...
]
Richard Achmatowicz commented on JGRP-1070:
-------------------------------------------
The key issue of JGRP-978 is that JGroups does not presently assign IP version specific
defaults to InetADdresses it makes use of, such as diagnostics_addr.
This problem has been solved by way of @Property default processing and IP version
checking.
During protocol stack creation, after all @Properties have been through their basic
processing, we build up a map of all InetAddresses (and related IpAddress,
InetSocketAddress) fields and methods in the stack which have a user specified value. This
map is them used to determine the JGroups IP version: IPv4 or IPv6. Once the version is
determined, the default values for @Properties are processed.
The @Proeprty default processing will now have a version to work with. Because
diagnostics_addr is an InetAddress, processing will check the @Prpeprty annotation for
defaultValueIPv4() or defaultValueIPv6(), and the correct version specific default is
assigned.
Provide IP version checking based on @Property processing
---------------------------------------------------------
Key: JGRP-1070
URL: https://jira.jboss.org/jira/browse/JGRP-1070
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.8
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 2.8
With the advent of IPv6 suppport, JGroups needs to be IP version aware, in order to
provide checks such as:
* ensuring that JGroups peers are started us using a set of bind and multicast addresses
which are of a single IP version
* in the case of IPv6 link-local addresses, checking that link-local scopes are present
to eliminate interface ambiguity
Managing many InetAddress and related addresses (such as IpAddress and InetSocketAddress)
which are used in many stack layers within a JGroups stack
is difficult. Especially so when a decision (siuch as which IP version to use) depends
upon having access to all InetAddresses at one point in time.
One way to achieve this is to delay all InetAddress creation until the init() layer of
each protocol, so that initial values for InetAddresses which have been passed in by the
user (or not) may be inspected and a decition made. However, decitions made in one iinit()
layer need to be communicated to the other layers - this is true in trying to assign a
common IP version across all layers.
Another approach is to intercept all InetAddress fields and setter methods during
protocol stack creation, and after properties have been processed. This allows us access
to the entire stack and its InetAddress variables by way of java.lang.reflect.Field and
java.lang.reflect.Method processing.
This is the approach to IP version checking (and other InetAddress related checks) which
will be taken for JGroups.
This approach also makes a nice stack creation-time companion to @Property processing
(including the processing of dependencies and defaults).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:20 p.m.
New subject: [JBoss JIRA] Closed: (JGRP-1070) Provide IP version checking based on @Property processing
[
https://jira.jboss.org/jira/browse/JGRP-1070?page=com.atlassian.jira.plug...
]
Richard Achmatowicz closed JGRP-1070.
-------------------------------------
Resolution: Done
Completed initial implementation.
Provide IP version checking based on @Property processing
---------------------------------------------------------
Key: JGRP-1070
URL: https://jira.jboss.org/jira/browse/JGRP-1070
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.8
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 2.8
With the advent of IPv6 suppport, JGroups needs to be IP version aware, in order to
provide checks such as:
* ensuring that JGroups peers are started us using a set of bind and multicast addresses
which are of a single IP version
* in the case of IPv6 link-local addresses, checking that link-local scopes are present
to eliminate interface ambiguity
Managing many InetAddress and related addresses (such as IpAddress and InetSocketAddress)
which are used in many stack layers within a JGroups stack
is difficult. Especially so when a decision (siuch as which IP version to use) depends
upon having access to all InetAddresses at one point in time.
One way to achieve this is to delay all InetAddress creation until the init() layer of
each protocol, so that initial values for InetAddresses which have been passed in by the
user (or not) may be inspected and a decition made. However, decitions made in one iinit()
layer need to be communicated to the other layers - this is true in trying to assign a
common IP version across all layers.
Another approach is to intercept all InetAddress fields and setter methods during
protocol stack creation, and after properties have been processed. This allows us access
to the entire stack and its InetAddress variables by way of java.lang.reflect.Field and
java.lang.reflect.Method processing.
This is the approach to IP version checking (and other InetAddress related checks) which
will be taken for JGroups.
This approach also makes a nice stack creation-time companion to @Property processing
(including the processing of dependencies and defaults).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5579
days inactive
5579
days old
3 comments
1 participants
participants (1)
-
Richard Achmatowicz (JIRA)