[ https://issues.jboss.org/browse/AS7-1299?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-1299: --------------------------------------- Some details. First, an update may or may not be immediately applicable to the runtime. If not, the model should be updated and context.reloadRequired() invoked. The simplest way to determine whether reload is required is to check whether the MSC service behind the interface is State.UP. It's an on-demand service, The service that should demand an interface, the SocketBinding, is also on-demand, so the interface service shouldn't be started unless something needs it. Second, the value for the criteria attribute is a complex dmr structure; potentially very complex. So, while adding a write-attribute handler for this attribute is necessary, by itself it's not highly user friendly. More user friendly is to add operations to handle the most common use cases; the handlers for those would behind the scenes create the appropriate dmr node representing the criteria. Common use cases: 1) <inet-address value="..."/> 2) <any-address/> 3) <any-ipv4-address/> 4) <any-ipv6-address/> 5) <loopback/> 6) <loopback address="127.0.0.2"/> I thought about whether those could just be handled via quasi-runtime-attributes, read via read-attribute and set via write-attribute. But I don't think the semantic could be made clean/consistent with other attributes. Perhaps <any-[ipvX-]address/> and <loopback/> could be if the description made it clear that, e.g. :read-attribute(name=loopback) would only return true if the criteria was <loopback/>, not if it was <inet-address value="127-0.0.1"/>. Otherwise knowing whether to return true or false would require starting the service and resolving the criteria. Alternatives: 1) :set-inet-address(value=10.0.0.1) 2) :set-any-address 3) :set-any-ipv4-address 4) :set-any-ipv6-address 5) :set-loopback 6) :set-loopback(address="127.0.0.2") I'm not thrilled with using "set" in the operation names; we've discussed elsewhere using "read" and "write" in the API. Using "write" in those names reads funny though. Another alternative: 1) write-criteria(inet-address=10.0.0.1) 2) write-criteria(any-address=true) 3) write-criteria(any-ipv4-address=true) 4) write-criteria(any-ipv6-address=true) 5) write-criteria(loopback=true) 6) write-criteria(loopback=true,inet-address=127.0.0.2) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-1299?page=com.atlassian.jira.plugin.s... ] Heiko Rupp commented on AS7-1299: --------------------------------- I would be fine with write-criteria or even a complex set of write-attribute. The killer here is the current (arbitrary) nesting of stuff to describe an interface; that should just be a flat list of key-values like you described above. I don't mind the name of the operation that much. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-1299?page=com.atlassian.jira.plugin.s... ] Heiko Rupp commented on AS7-1299: --------------------------------- The question is how deep the nesting really has to be. Flattened out would be best, but already restricting the level of nesting could help. Do people really use those complex criteria? I would expect that just giving a specific IP address would be the case used most often. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-1299?page=com.atlassian.jira.plugin.s... ] Jason Greene updated AS7-1299: ------------------------------ Fix Version/s: 7.1.0.Alpha1 (was: 7.0.1.Final) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-1299?page=com.atlassian.jira.plugin.s... ] Emanuel Muckenhuber resolved AS7-1299. -------------------------------------- Resolution: Done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira