Re: [wildfly-dev] Redesigning http-upgrade configuration for management
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev