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

[Darran Lofthouse]

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