9:46 a.m.
On 8/5/14, 2:42 AM, Heiko Braun wrote:
> 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.
We also have form of subtyping that's something we should explore as we
sort this. We allow a "squatter" resource description to override a
non-squatter definition. When it does this it can add attributes or
child types. The use case this was added for is where different
implementations of the service underlying a resource are possible and we
register the subtype when we install the service and learn what it supports.
For example, start the server with the ExampleDS *disabled* and read the
resource description tree for the datasources subsystem:
[standalone@localhost:9990 subsystem=datasources]
:read-resource-description(recursive=true)
{
....
"children" => {
...
"data-source" => {
"description" => "A JDBC data-source configuration",
"model-description" => {
"*" => {...}
}
}
}
}
But once you enable the datasource, another child description is
registered, for "ExampleDS":
standalone@localhost:9990 subsystem=datasources]
:read-resource-description(recursive=true)
{
....
"children" => {
...
"data-source" => {
"description" => "A JDBC data-source configuration",
"model-description" => {
"ExampleDS" => {...},
"*" => {...}
}
}
}
}
The ExampleDS registration includes statistics attributes provided by
the underlying datasource.
So, how should we clarify this? Does
:read-children-types(include-squatters=true) include
"datasource=ExampleDS" in the result? How do we disambiguate this
"subtype" case from the "singleton" case?
I'll think about this a bit. One vague thought I have is the
:read-resource-description output is a bit too terse if you don't add
recursive=true. It's structure really assumes the non-squatter case:
[standalone@localhost:9990 subsystem=datasources] :read-resource-description
{
"outcome" => "success",
"result" => {
"description" => "The data-sources subsystem, used to declare JDBC
data-sources",
"attributes" => {...}},
"operations" => undefined,
"notifications" => undefined,
"children" => {
"jdbc-driver" => {
"description" => "Service that make a JDBC driver available for
use in the runtime",
"model-description" => undefined
},
"xa-data-source" => {
"description" => "A JDBC XA data-source configuration",
"model-description" => undefined
},
"data-source" => {
"description" => "A JDBC data-source configuration",
"model-description" => undefined
}
}
}
}
It might be ok to just expand that '"model-description" => undefined'
part with a bit more data. It's a change in the output for an existing
op, which could be a compatibility issue, but why would a client care
about that? The existing '"model-description" => undefined' is just
useless noise that a client wouldn't process anyway.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat