Description of problem: BZ900315 tighten up the interface creation procedure. User cannot create any new interface with any-ipv6-address=true if java.net.preferIPv4Stack is set to true now, but he is still able to configure existing interfaces with this property. We also found a few use cases where this fix is too strict. We should allow user to create this interface, but fail the operations which tries to make it actually do some work. Version-Release number of selected component (if applicable): EAP 6.4.0.DR3 How reproducible: Always Steps to Reproduce: 1. start OOB standalone and connect to CLI Actual results: CASE1: /interface=myIPv6:add(any-ipv6-address=true) "outcome" => "failed" /socket-binding-group=standard-sockets:write-attribute(name=default-interface, value=myIPv6) ... we don't make this far CASE2: /interface=public:undefine-attribute(name=inet-address) "outcome" => "success" /interface=public:write-attribute(name=any-ipv6-address, value=true) "outcome" => "success" after reload we get the same bunch of errors as in BZ900315 Expected results: CASE1: /interface=myIPv6:add(any-ipv6-address=true) "outcome" => "success" /socket-binding-group=standard-sockets:write-attribute(name=default-interface, value=myIPv6) "outcome" => "failed" CASE2: /interface=public:undefine-attribute(name=inet-address) "outcome" => "success" /interface=public:write-attribute(name=any-ipv6-address, value=true) "outcome" => "failed"
(In reply to Petr Kremensky from comment #0) > > We also found a few use cases where this fix is too strict. Please provide details.
Use case I can think of is following: User on dual stack machine wants to pre-configure an IPv6 interface before restarting the server and removing the java.net.preferIPv4Stack property. However after investigating a bit further I believe that the fix introduced for BZ900315 is in fact not valid (and thus we don't even need to think about some use case) because: 1) it prevents user to set up *new and unused* interface with any-ipv6-address. Such setting is harmless -- thus there is no reason to prevent it. Additionally this can be set-up directly in XML config and server will start just fine. 2) it still allows user to change the setting of *existing interface* (including the any-ipv6-address). This setting can lead to invalid configuration after server reload (e.g. setting any-ipv6-address for public interface). To verify the second point execute this in CLI: /interface=public:write-attribute(name=inet-address, value=undefined) /interface=public:write-attribute(name=any-ipv6-address, value=true) :reload Now check the server log.
Verified on EAP 6.4.0.DR9