6:27 a.m.
[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
}
8:38 a.m.
It can be set on the server-group.
On 3/23/11 6:27 AM, Heiko Braun wrote:
[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
8:41 a.m.
That means any property that can be inherited will default to UNDEFINED
if set somewhere higher in the tree?
On Mar 23, 2011, at 2:38 PM, Brian Stansberry wrote:
It can be set on the server-group.
On 3/23/11 6:27 AM, Heiko Braun wrote:
>
>
> [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
9:01 a.m.
Yes. The model is storing the user's configuration; not any
manipulations we might eventually do.
I can sense a feature request coming...
On 3/23/11 8:41 AM, Heiko Braun wrote:
That means any property that can be inherited will default to UNDEFINED
if set somewhere higher in the tree?
On Mar 23, 2011, at 2:38 PM, Brian Stansberry wrote:
> It can be set on the server-group.
>
> On 3/23/11 6:27 AM, Heiko Braun wrote:
>>
>>
>> [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
9:15 a.m.
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
9:57 a.m.
/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
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
2 p.m.
I know. At this stage we probably shouldn't introduce major changes.
But then, on the other hand, it might hit us later on.
Think about it, I cannot clearly see all implications.
On Mar 23, 2011, at 3:57 PM, Brian Stansberry wrote:
/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
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
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
9:19 a.m.
Question from Andy Miller: when do you see JVM config support coming
into the console?
On 3/23/11 6:27 AM, Heiko Braun wrote:
[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
2:43 p.m.
You mean the ability to configure JVM settings for a host?
I.e. one of these:
[localhost:9999 /] /host=local/jvm=default:read-operation-names
{
"outcome" => "success",
"result" => [
"add",
"add-jvm-option",
"add-system-property",
"read-attribute",
"read-children-names",
"read-children-types",
"read-operation-description",
"read-operation-names",
"read-resource",
"read-resource-description",
"remove",
"remove-jvm-option",
"remove-system-property",
"write-attribute"
],
"compensating-operation" => undefined
}
Don't know. I didn't look into this yet.
On Mar 23, 2011, at 3:19 PM, Brian Stansberry wrote:
Question from Andy Miller: when do you see JVM config support coming
into the console?
On 3/23/11 6:27 AM, Heiko Braun wrote:
>
>
> [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
5000
days inactive
5007
days old
9 comments
3 participants
participants (3)
-
Brian Stansberry -
Heiko Braun -
Max Rydahl Andersen