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

[Emmanuel Hugonnet]

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'.


> 
>> 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
>>
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150917/04941df6/attachment.bin