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

[Emmanuel Hugonnet]

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 ?


-------------- 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/20150916/792556f2/attachment.bin