11:25 a.m.
I'm still a noob when it comes to the domain model but
I just want to reflect Heiko's concerns from a tooling and user perspective -
it seems that for using the http/cli API you not only need to be super aware of these
details;
you also have to do multiple queries to actually resolve the information you as a user,
tools or management console
write would need to get a full picture.
And as far as I can see; you will need to consult that not-yet-existing wiki page
constantly to actually figure out
if a undefined means undefined or inherited (and then where that is inherited from).
I can just imagine the many different implementations that will occur to try and interpret
this lowlevel model ...
management console, jopr, jboss tools, user scripts ....seems to get very error prone very
quickly.
Some way to actually "materialize" the model would be very useful, and possible
even required for sensible external usage IMO.
I believe this were discussed some months ago, but I never saw any real conclusion on it
then.
/max
On Mar 23, 2011, at 15:15, 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
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen