[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