[wildfly-dev] Redesigning http-upgrade configuration for management

[Brian Stansberry]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat