On 5/2/13 7:28 AM, David M. Lloyd wrote:
It seems like the more useful distinction is "operations which
are
always available" and "operations which are only available in runtime
mode" i.e. not in management mode.
Yes, this is the practical effect. An operation with the RUNTIME_ONLY
flag is basically stating it doesn't effect the persistent configuration
model, and would be useless in management mode.
Every other case seems like "read" versus "write"
to me. You either
query the container state, or you modify it.
On 05/02/2013 07:24 AM, Brian Stansberry wrote:
> There is a flag that can be associated with an operation, RUNTIME_ONLY,
> that indicates an op only affects runtime. It isn't used much, largely
> because there hasn't been a consistent use case. The access control
> stuff will lead to consistent use though.
>
> I'm not sure if that's your question though. Almost all operations
> affect runtime state, either immediately or by putting the process in
> reload-required/restart-required. And there's metadata describing those
> effects.
>
> I say almost all because of a couple oddities like
> add/remove-namespace/schema-location which only affect the config model
> and the xml file.
>
> On 5/2/13 7:17 AM, Heiko Braun wrote:
>>
>>
>> Is it possible to identify operations that affect the runtime state (i.e.
start/stop services) ?
>>
>> I was looking at a datasource example, but couldn't find any metadata related
to that:
>>
>> [standalone@localhost:9999 /]
/subsystem=datasources/data-source=ExampleDS:read-operation-description(name=enable)
>> {
>> "outcome" => "success",
>> "result" => {
>> "operation-name" => "enable",
>> "description" => "Enable the data-source",
>> "request-properties" => {"persistent" => {
>> "type" => BOOLEAN,
>> "description" => "if true enable attribute is
persisted",
>> "expressions-allowed" => false,
>> "required" => true,
>> "nillable" => false,
>> "default" => true
>> }},
>> "reply-properties" => {},
>> "read-only" => false
>> }
>> }
>>
>>
>>
>> Regards, Heiko
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat