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

[Brian Stansberry]

On 9/17/15 2:58 AM, Emmanuel Hugonnet wrote:
>
>
> Le 16/09/2015 20:11, Brian Stansberry a écrit :
>> 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?
>
> I agree so something along 'native-support=on'.
>

This is a resource, not an attribute. The existence of the resource 
itself implies "on".

Resources should have a name following a pattern like 
"category_of_the_thing=specific_name_of_the_thing".

There are some cases where the resource is a singleton and 
"category_of_the_thing" becomes kind of pointless, so we use generic 
terms like 'service' or 'configuration' in that part. But we still 
follow the pattern. It's not clear though that this is even that kind of 
case. A key goal of an API design discussion like this is to identify 
the key characteristics of the thing in question and then decide if 
there's a meaningful "category_of_the_thing" into which other resources 
may fall.

>
>>
>>> 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.
>
> Yes of course
>
>>
>>>    - 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. :(
>
> Yes and in the model itself
>
>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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