3:42 a.m.
TL;DR: A proposal for improving parts of the management API that deal with static
resource definitions
Background:
For future Wildfly versions we plan to re-architect the management console to make better
use the existing meta data. The goal is to provide a data binding layer that automates
much of the retrieval and update of the configuration and runtime data. To achieve this
goal, we need to remove some of the roadblocks that prevent further automation. This is
the first of a series of posts that explains some of the challenges we facing and a
proposal to improve the situation.
Problem:
Typically we deal with resources that addressable through a key value pair, where the key
of the tuple depicts the type of the resource and the value the name or identify of a
specific resource instance, i.e.:
/subsystem=datasources/data-source=ExampleDS
In this case 'ExampleDS' is the name of a resource of type 'data-source'.
The type is associated with a specific resource definition, that's typically retrieved
through the :read-resource-description operation. In the following sections I am going to
refer to these resource as 'regular' resources.
In some situations, it seems more feasible (and valid) to construct a model representation
without instance names, i.e.:
/subsystem=ejb3/service=[async | remote | timer-service]
In this case each resource under /subsystem=ejb3/service has a different type and only a
single instance can exist:
/service=async
/service=remote
/service=timer-service
Lacking a better alternative, I coined the term 'squatter' resources, because
these resources squat a specific address slots. Squatter resources can be pre-registered
or non-exisiting when the management layer is started.
In order to provide a data binding layer for the management console, we need to access the
definition of a resource (:read-resource-description). With squatter resources this is
basically impossible, because the existence of these types is hidden in the general API.
I.e. sticking to the previous example, when querying the resource definition for the ejb3
subsystem, it pretends only single type 'service' exists, although it's
actually three different 'service' types
./subsystem=ejb3:read-children-types
{
"outcome" => "success",
"result" => [
[...],
"service",
[...]
]
}
Proposal:
After a chat with Brian yesterday, we are proposing a new request parameter to the
:read-children-types operations, that augments the result to reveal the existence of
squatter resources:
./subsystem=ejb3:read-children-types(include-squatters=true)
{
"outcome" => "success",
"result" => [
[...],
"service=async",
"service=remote",
"service=timer-service"
[...]
]
}
This works in a backwards compatible way and allows us to identify squatter resources and
get to their resource definition.
Thoughts and comments welcome.
If you can think of better term than 'squatter' resources, please let me know as
well.
Regards, Heiko