7:03 a.m.
is the 'server' node the element that contains server instances?
{
"address" => [("host" => "local")],
"operation" => "read-resource"
}
outcome' : 'success',
'result' :
{
[...]
'server-config' :
{
'server-one' :
{
},
'server-two' :
{
},
'server-three' :
{
}
},
[...]
'server' :
{
}
},
'compensating-operation' :
{
}
9:45 a.m.
On 3/18/11 7:03 AM, Heiko Braun wrote:
is the 'server' node the element that contains server instances?
Yes; that's where you access the actual running server.
The operations to actually start/stop/restart the server and check their
status are under "server-config" which I'm not happy about. Not
intuitive. It's that way because of a kind of chicken-and-egg problem.
Emanuel, WDYT about a more sophisticated ProxyController for the
servers? Installed by the ServerAddHandler. It handles the lifecycle and
status ops directly; proxies the rest. Where it gets complicated is
things like read-resource, read-resource-description, read-attribute,
all of which would require custom handling. It also make a server
resource an odd duck, since it's resource description varies depending
on whether the server is started.
{
"address" => [("host" => "local")],
"operation" => "read-resource"
}
outcome' : 'success',
'result' :
{
[...]
'server-config' :
{
'server-one' :
{
},
'server-two' :
{
},
'server-three' :
{
}
},
[...]
'server' :
{
}
},
'compensating-operation' :
{
}
_______________________________________________
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
10:01 a.m.
On 03/18/2011 03:45 PM, Brian Stansberry wrote:
On 3/18/11 7:03 AM, Heiko Braun wrote:
>
> is the 'server' node the element that contains server instances?
Yes; that's where you access the actual running server.
The operations to actually start/stop/restart the server and check their
status are under "server-config" which I'm not happy about. Not
intuitive. It's that way because of a kind of chicken-and-egg problem.
Emanuel, WDYT about a more sophisticated ProxyController for the
servers? Installed by the ServerAddHandler. It handles the lifecycle and
status ops directly; proxies the rest. Where it gets complicated is
things like read-resource, read-resource-description, read-attribute,
all of which would require custom handling. It also make a server
resource an odd duck, since it's resource description varies depending
on whether the server is started.
Yes, we could think of doing something like that - maybe we should just
create a ManagedServer for all configured servers and make it the proxy.
It should be aware of the lifecyle/state of the server anyway and also
holds the associated managed connection.
10:10 a.m.
On 3/18/11 10:01 AM, Emanuel Muckenhuber wrote:
On 03/18/2011 03:45 PM, Brian Stansberry wrote:
> On 3/18/11 7:03 AM, Heiko Braun wrote:
>>
>> is the 'server' node the element that contains server instances?
>
> Yes; that's where you access the actual running server.
>
> The operations to actually start/stop/restart the server and check their
> status are under "server-config" which I'm not happy about. Not
> intuitive. It's that way because of a kind of chicken-and-egg problem.
>
> Emanuel, WDYT about a more sophisticated ProxyController for the
> servers? Installed by the ServerAddHandler. It handles the lifecycle and
> status ops directly; proxies the rest. Where it gets complicated is
> things like read-resource, read-resource-description, read-attribute,
> all of which would require custom handling. It also make a server
> resource an odd duck, since it's resource description varies depending
> on whether the server is started.
>
Yes, we could think of doing something like that - maybe we should just
create a ManagedServer for all configured servers and make it the proxy.
It should be aware of the lifecyle/state of the server anyway and also
holds the associated managed connection.
Yes, that sounds like the right way to implement it.
Heiko/Ike/Emanuel/anyone -- any concerns about the "resource description
varies" issue?
What I mean is, for all other resources, read-resource-description will
return fixed content. For host=x,server=y it will vary depending on
whether the server is actually started. If not running, it will just
provide the operation to start the server and a "status" attribute,
which will tell you it's stopped. Once you start the server, then
read-resource-description will provide that, plus ops to stop and
restart the server, plus all the normal attributes and operations
exposed by the root resource of a server.
_______________________________________________
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
3:12 p.m.
On Mar 18, 2011, at 4:10 PM, Brian Stansberry wrote:
What I mean is, for all other resources, read-resource-description
will
return fixed content. For host=x,server=y it will vary depending on
whether the server is actually started. If not running, it will just
provide the operation to start the server and a "status" attribute,
which will tell you it's stopped. Once you start the server, then
read-resource-description will provide that, plus ops to stop and
restart the server, plus all the normal attributes and operations
exposed by the root resource of a server.
can there be more then one server instance per server-config?
Ike
3:13 p.m.
On 3/18/11 3:12 PM, Heiko Braun wrote:
On Mar 18, 2011, at 4:10 PM, Brian Stansberry wrote:
> What I mean is, for all other resources, read-resource-description will
> return fixed content. For host=x,server=y it will vary depending on
> whether the server is actually started. If not running, it will just
> provide the operation to start the server and a "status" attribute,
> which will tell you it's stopped. Once you start the server, then
> read-resource-description will provide that, plus ops to stop and
> restart the server, plus all the normal attributes and operations
> exposed by the root resource of a server.
can there be more then one server instance per server-config?
No.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
3:20 p.m.
well, in that case it makes sense.
does it mean the current 'server' element will go?
On Mar 18, 2011, at 9:13 PM, Brian Stansberry wrote:
On 3/18/11 3:12 PM, Heiko Braun wrote:
>
> On Mar 18, 2011, at 4:10 PM, Brian Stansberry wrote:
>
>> What I mean is, for all other resources, read-resource-description will
>> return fixed content. For host=x,server=y it will vary depending on
>> whether the server is actually started. If not running, it will just
>> provide the operation to start the server and a "status" attribute,
>> which will tell you it's stopped. Once you start the server, then
>> read-resource-description will provide that, plus ops to stop and
>> restart the server, plus all the normal attributes and operations
>> exposed by the root resource of a server.
>
>
> can there be more then one server instance per server-config?
>
No.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4:46 p.m.
I'm not sure what you're asking. So I'll just blather on. :-)
There's really 2 things:
1) The host.xml <server> element. That tells a HostController the
information it needs to launch a server. That info needs to be stored in
the model as part of the host's configuration, and is stored under
host=x,server-config=y. That suggests the XML element should be named
<server-config>. I didn't change it mostly because it's less intuitive
for people only concerned with XML.
2) The host=x,server=y resource, which represents an actual running
server. What I proposed was moving some operations related to
starting/stopping/restarting a server from host=x,server-config=y to
host=x,server=y. Those ops are only loosely related to "server-config".
Combining host=x,server-config=y and host=x,server=y would be pretty
messy. (And would add a fair bit of implementation complexity.) Under
host=x,server-config=y there can be server-specific overrides of stuff
stored elsewhere in domain.xml and host.xml (paths, interfaces, system
properties). We'd have to give those overrides different names in the
tree to distinguish them from the merged values on the running server.
For example, in domain.xml, we might have some domain-wide defaults:
<system-properties>
<system-property name="foo" value="foo"/>
<system-property name="bar" value="bar"/>
</system-properties>
In host xml there might be
<server name="x"...>
<system-properties>
<!-- Override the domain value -->
<system-property name="bar" value="xyz"/>
</system-properties>
</server>
That override needs to be accessible and changeable via the management
API, at the host controller level.
But if you did this from the cli:
/host=local/server=x:read-attribute(name="system-properties")
you'd want to get all properties that exist in the running server, i.e.
{
"outcome"=>"success",
"result"=>[
{"foo"=>"foo"},
{"bar=>"xyz"}
],
"compensating-operation"=>undefined
}
On 3/18/11 3:20 PM, Heiko Braun wrote:
well, in that case it makes sense.
does it mean the current 'server' element will go?
On Mar 18, 2011, at 9:13 PM, Brian Stansberry wrote:
> On 3/18/11 3:12 PM, Heiko Braun wrote:
>>
>> On Mar 18, 2011, at 4:10 PM, Brian Stansberry wrote:
>>
>>> What I mean is, for all other resources, read-resource-description will
>>> return fixed content. For host=x,server=y it will vary depending on
>>> whether the server is actually started. If not running, it will just
>>> provide the operation to start the server and a "status"
attribute,
>>> which will tell you it's stopped. Once you start the server, then
>>> read-resource-description will provide that, plus ops to stop and
>>> restart the server, plus all the normal attributes and operations
>>> exposed by the root resource of a server.
>>
>>
>> can there be more then one server instance per server-config?
>>
>
> No.
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4:43 a.m.
I've created an issue for it:
https://issues.jboss.org/browse/JBAS-9130
On Mar 18, 2011, at 4:10 PM, Brian Stansberry wrote:
On 3/18/11 10:01 AM, Emanuel Muckenhuber wrote:
> On 03/18/2011 03:45 PM, Brian Stansberry wrote:
>> On 3/18/11 7:03 AM, Heiko Braun wrote:
>>>
>>> is the 'server' node the element that contains server instances?
>>
>> Yes; that's where you access the actual running server.
>>
>> The operations to actually start/stop/restart the server and check their
>> status are under "server-config" which I'm not happy about. Not
>> intuitive. It's that way because of a kind of chicken-and-egg problem.
>>
>> Emanuel, WDYT about a more sophisticated ProxyController for the
>> servers? Installed by the ServerAddHandler. It handles the lifecycle and
>> status ops directly; proxies the rest. Where it gets complicated is
>> things like read-resource, read-resource-description, read-attribute,
>> all of which would require custom handling. It also make a server
>> resource an odd duck, since it's resource description varies depending
>> on whether the server is started.
>>
>
> Yes, we could think of doing something like that - maybe we should just
> create a ManagedServer for all configured servers and make it the proxy.
> It should be aware of the lifecyle/state of the server anyway and also
> holds the associated managed connection.
>
Yes, that sounds like the right way to implement it.
Heiko/Ike/Emanuel/anyone -- any concerns about the "resource description
varies" issue?
What I mean is, for all other resources, read-resource-description will
return fixed content. For host=x,server=y it will vary depending on
whether the server is actually started. If not running, it will just
provide the operation to start the server and a "status" attribute,
which will tell you it's stopped. Once you start the server, then
read-resource-description will provide that, plus ops to stop and
restart the server, plus all the normal attributes and operations
exposed by the root resource of a server.
> _______________________________________________
> 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
5030
days inactive
5036
days old
8 comments
3 participants
participants (3)
-
Brian Stansberry -
Emanuel Muckenhuber -
Heiko Braun