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

[Brian Stansberry]

On 9/17/15 5:02 AM, Darran Lofthouse wrote:
> 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.
>

That is fine; we should stop. This work was driven by 
https://issues.jboss.org/browse/WFCORE-949 / 
https://issues.jboss.org/browse/JBEAP-980 neither of which are scheduled 
for WF 10. WFCORE-949 isn't truly a regression, as doing a similar thing 
in EAP 6 by removing the native interface will also fail. But still, if 
we could have fixed 949 for WF 10 by adding a no-brainer child resource 
I would have liked to do so.

But it's clear that the design of that child resource is not a 
no-brainer, so we should stop.

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