Taken to its logical conclusion, this would become a full-fledged query
You could just create a client-side library for it and use that as the
"language" develops. I think that would be a safe thing to do before
committing it as part of the supported server side interface.
How much of a problem would this be if it were not for GWT's
callback-hell? It's my understanding that GWT is fixing that?
On 10/31/2014 11:35 AM, Harald Pehl wrote:
For management clients it is tedious and awkward to read resources /
attributes in big domains (e.g. return the state of all running
servers across all hosts which are part of server group "foo"). Today
this requires to setup multiple composite operations *on the
client* which need to be executed in a specific order. This proposal
suggests a new operation which collects all relevant information *on
the server* and returns only the relevant data in one go to the client.
In the admin console we often need to read specific attributes across
a domain or across a deeply nested resource:
- List all enabled data sources of the current profile
- Show the port offset of all running servers across all hosts
- Get all users which belong to role Operator
Even for small domains with two server groups and a small number of
servers this procedure is awkward and error prone. What makes it even
more difficult is the asynchronous nature of the admin console. Soon
you end up in a deeply nested callback-hell. Besides that these
'queries' lead to poor performance for big domains with tens of
groups, hosts and servers.
# Proposal / Prototype
The GitHub repository at  contains a more detailed description of
the problem statement and a working prototype. This includes details
such as how to address the requested resources, how the information is
retrieved and how to handle errors.
The proposal also includes a way to filter and reduce the resources
against a list of attributes and values *before* the response is sent
to the client.
JBoss by Red Hat
wildfly-dev mailing list