[wildfly-dev] Management Model: Squatter Resources

[Brian Stansberry]

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