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

Darran Lofthouse darran.lofthouse at jboss.com
Thu Sep 17 06:18:06 EDT 2015


On 16/09/15 19:11, Brian Stansberry wrote:
> 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?

That sounds like where I was starting to come from regarding a new 
design to move this into a subsystem - we actually have a bit of a 
mixture when it comes to defining how different interfaces are exposed.

I was considering that at the top level we have a resource that 
represents the protocol being exposed.

I was then considering attributes to define how it is exposed, from 
subsequent capability related discussions those would probably have to 
be child resources.

In XML terms it would be something like: -

<native-interface sasl-authentication="...">
     <remoting />
     <direct socket-binding="..." />
     <http-upgrade use-http-binding="..." undertow-listener="..." />
</native-interface>
<http-interface http-authentication="...">
     <direct http-socket-binding="..." https-socket-binding="..."/>
     <undertow-listener name="..." context="/management" />
</http-interface>

Names chosen were just to illustrate the hierarchy but general principal 
was the parent is what is exposed, the child is how it is exposed.



More information about the wildfly-dev mailing list