On 9/16/15 12:33 PM, Emmanuel Hugonnet wrote: > Hi, > This is for management interfaces only. > We need a capability to cover the fact that some management interfaces may provides jboss-remoting endpoints to be used by JMX. > The native-interface provides this capability at the resource level, so this is nice and straightforward. > Currently making an http-interface http-upgrade-enabled is done through the well named 'http-upgrade-enabled' attribute. > But because of the use of an attribute we have no nice standard way to register the capability. > One way to do that would be to use a child resource, "http-upgrade-support=on" to define the fact that this http-interface supports upgrade. We need a different name for this. Address elements should be of the form category=specific_name. This resource is the logical encapsulation of some sort of functionality. So we need to brainstorm and define what exactly that functionality is and what it may become and then hopefully the name for the resource will fall out of that. For example, I believe http-upgrade is an implementation detail. What the resource is really about is providing JBoss Remoting-based management in an HTTP environment. We refer to that elsewhere as "native" (i.e. in /core-service=management/management-interface=native-interface) So is this resource primarily about native management?

> We could then move the code and services associated with this support to the addHandler and removeHandler. > To keep backward compatibility : > - for the add / remove of current resource : > it is easy to add a new step to add the new resource on the http-interface addHandler, and do the same for removal. The removal should require reload, to encourage the user to understand that they may lose their connection to the server, and to avoid creating another situation where executing an op can result in an unclean execution from the client's point of view due to the connection closing.

> - for the beloved http-upgrade-enabled attribute which is writeable but doesn't really do anything until the interface is restarted. > Of course it could get deprecated but we would still have a writeable attribute that represents a duplicate state of the child resource. > We may want to use the write-attribute handler on this attribute to call the resource ops without impacting the services, just changing the > model. If they set the value to 'false', yes. If they set it to true, putting the server into reload required is enough, as the boot handling should be adding the child resource when http-upgrade-enabled is 'true'. > > What do you think ? > There's the fact that http-upgrade-enabled currently supports expressions. We need to define all the semantics around that. Some thoughts: 1) If the user stores the expression value in the vault, that just can't work, as the evaluation of the expression in order to decide whether to add the child resource has to happen before the vault is available. I have no problem with that constraint, since using a vault expression here would be a real corner case. And this attribute has never been in EAP where we might have a greater requirement to continue to support old weird corner cases. 2) If the value doesn't have an expression, we can drop the attribute when marshaling, and just write the child element. But if it does have an expression we have to marshal the attribute back to xml. Unfortunately this precludes dropping the attribute from the current version of the xsd. :(

> > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

For example, I believe http-upgrade is an implementation detail. What the resource is really about is providing JBoss Remoting-based management in an HTTP environment. We refer to that elsewhere as "native" (i.e. in /core-service=management/management-interface=native-interface) So is this resource primarily about native management?

On 09/17/2015 05:18 AM, Darran Lofthouse wrote: > On 16/09/15 19:11, Brian Stansberry wrote: >> For example, I believe http-upgrade is an implementation detail. What >> the resource is really about is providing JBoss Remoting-based >> management in an HTTP environment. We refer to that elsewhere as >> "native" (i.e. in >> /core-service=management/management-interface=native-interface) So is >> this resource primarily about native management? > > That sounds like where I was starting to come from regarding a new > design to move this into a subsystem - we actually have a bit of a > mixture when it comes to defining how different interfaces are exposed. > > I was considering that at the top level we have a resource that > represents the protocol being exposed. > > I was then considering attributes to define how it is exposed, from > subsequent capability related discussions those would probably have to > be child resources. > > In XML terms it would be something like: - > > <native-interface sasl-authentication="..."> > <remoting /> > <direct socket-binding="..." /> > <http-upgrade use-http-binding="..." undertow-listener="..." /> > </native-interface> > <http-interface http-authentication="..."> > <direct http-socket-binding="..." https-socket-binding="..."/> > <undertow-listener name="..." context="/management" /> > </http-interface> > > Names chosen were just to illustrate the hierarchy but general principal > was the parent is what is exposed, the child is how it is exposed. Assuming that we are still planning following through with moving everything into subsystems/enabling HC subsystems like we discussed last January, and given cap/req, shouldn't we seriously consider making it something more closely approximating this: <subsystem xmlns="...remoting..."> <endpoint id="management" name="${jboss.node.name}-management"> <http-connector name="blah" sasl-authentication="rem-sasl" connector-ref="mgmt-connect" .../> </endpoint> </subsystem> <subsystem xmlns="...network..."> <interface name="management"> <inet-address value="127.0.0.1"/> </interface> <socket-binding-group name="standard-sockets"> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/> ...boring stuff here... </socket-binding-group> </subsystem> <subsystem xmlns="...sec-elytron..."> <security-domain name="main-domain"> <sasl-authentication name="rem-sasl"> ...boring stuff here... </sasl-authentication> ...boring realm stuff here... </security-domain> </subsystem> <subsystem xmlns="...undertow..."> <server name="mgmt-server"> <http-listener name="default" socket-binding="management-http" .../> ...boring stuff here... </server> ...boring stuff here... </subsystem> <subsystem xmlns="...management..."> <remoting endpoint="management"/> // this is an attribute, not a sub-resource <security-domain name="main-domain"/> // this is an attribute, not a sub-resource ...boring stuff here... </subsystem> That said if we're not making the move to subsystems, I guess I don't really care how it's all laid out too much, but using cap/req whenever possible will make any such future move go more smoothly, IMO.

Has this code been already written or not? I was told the other day that this code was almost complete but now it is back to a design discussion. I have also been told that this is not urgent for WildFly 10. If this is still being designed and is not critical for WildFly 10 can I please ask that this is stopped and we pick this up later - this directly conflicts with changes I have already made to integrate Elytron. In general my opinion is that instead of spending any effort on redesigning the current interfaces we should put the effort into the design of a new subsystem to contain these interfaces and that should start from the beginning where we can remodel the relationship between the two interface types.

Regards, Darran Lofthouse. On 16/09/15 18:33, Emmanuel Hugonnet wrote: > Hi, > This is for management interfaces only. > We need a capability to cover the fact that some management interfaces may provides jboss-remoting endpoints to be used by JMX. > The native-interface provides this capability at the resource level, so this is nice and straightforward. > Currently making an http-interface http-upgrade-enabled is done through the well named 'http-upgrade-enabled' attribute. > But because of the use of an attribute we have no nice standard way to register the capability. > One way to do that would be to use a child resource, "http-upgrade-support=on" to define the fact that this http-interface supports upgrade. > We could then move the code and services associated with this support to the addHandler and removeHandler. > To keep backward compatibility : > - for the add / remove of current resource : > it is easy to add a new step to add the new resource on the http-interface addHandler, and do the same for removal. > - for the beloved http-upgrade-enabled attribute which is writeable but doesn't really do anything until the interface is restarted. > Of course it could get deprecated but we would still have a writeable attribute that represents a duplicate state of the child resource. > We may want to use the write-attribute handler on this attribute to call the resource ops without impacting the services, just changing the > model. > > What do you think ? > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev