/me ponders implications of this idea.
Interesting but has major repurcussions. :-)
On 3/23/11 9:15 AM, Heiko Braun wrote:
Feature request? Not yet.
But food for thought.
It is very difficult to work with the current model, because you cannot easily
distinguish
the structural information (server-config has a property called 'jvm') from the
actual state (the jvm value is 'default')
Furthermore there is no way to identify inherited properties, or to put it another way:
the inherited state.
Just take the :read-resource outcome as an example.
I would think 'oh, the JVM property is not set'. But actually it is, just at some
other place in tree.
This makes it very hard to work with the current model.
Maybe it would help to introduce a 'reference' value type?
I.e.
{
"jvm" => {ref:<address>}
}
This could actually turn into:
{
"jvm" => {ref:[
"server-group":"default"
]}
}
So you would know that it is an inherited property that's derived from a resource
at<address>
My 2 cents.
>>>>
>>>> [localhost:9999 /] /host=local/server-config=server-three:read-resource
>>>> {
>>>> "outcome" => "success",
>>>> "result" => {
>>>> "path" => undefined,
>>>> "system-property" => undefined,
>>>> "interface" => undefined,
>>>> "jvm" => undefined,
>>>> "name" => "server-three",
>>>> "group" => "other-server-group",
>>>> "socket-binding-group" =>
"standard-sockets",
>>>> "socket-binding-port-offset" => 250,
>>>> "auto-start" => false
>>>> },
>>>> "compensating-operation" => undefined
>>>> }
>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat