On Mon, Oct 22, 2012 at 3:16 PM, Brian Stansberry <brian.stansberry@redhat.com> wrote:

It's a reasonable thing to look at in AS 8. There are really two
concerns I have with it:

1) It can't become another complex coding requirement that subsystem
developers have to add into what they do. It needs to be something that
the infrastructure can handle for the subsystems.

2) Boot speed. I'm concerned about a lot of logic during boot to
generate the resource metadata and then compare each "add" ops to it in
order to figure out how to split up the add op.

BTW in case it's helpful, have a look at
GenericSubsystemDescribeHandler. It's a class that takes a subsystem
model (in the Host Controller) and converts it into a series of
operations (for execution on a server during boot). It assumes a
"default" subsystem model, where the set of writable attributes exposed
by each resource in the subsystem tree matches the set of params exposed
by the resource's "add" operation. Subsystems, however, aren't required
to follow that pattern.

Best way to get this operations would be just to call :describe operation for a subsystem, that gives you list of operations to (re)generate resource structure.
GenericSubsystemDescribeHandler is just default one and does not work for few exceptions.
Also output of that operation is tested in subsystem tests so you can relay on it to produce proper operations.

On 10/22/12 4:38 AM, Heiko Braun wrote:
>
> Yes, right. I meant to ask:
> Does this sound like a reasonable feature to add? The ability to
> recursively invoke add operations?
>
> I.e. operation=add, recursive=true, [...]
>
> So that the management layer takes care of breaking it up into multiple
> "add" invocations?
>
>
> On Oct 22, 2012, at 11:31 AM, Tomaž Cerar <tomaz.cerar@gmail.com

> <mailto:tomaz.cerar@gmail.com>> wrote:
>
>> Hi,
>>
>> given example below, your problem is that you are calling one add
>> operation where you should be calling many. for example provided it
>> should be something like this (not tested)
>>
>> {
>> "operation" => "add",
>> "address" => [
>> ("host" => "master"),
>> ("server-config" => "prod_copy")
>> ],
>> "auto-start" => true,
>> "cpu-affinity" => undefined,
>> "group" => "production-1",
>> "interface" => undefined,
>> "path" => undefined,
>> "priority" => undefined,
>> "socket-binding-group" => "full-sockets",
>> "socket-binding-port-offset" => 150
>> }
>>
>> {
>> "operation" => "add",
>> "address" => [
>> ("host" => "master"),
>> ("server-config" => "prod_copy")
>> ("jvm" => "default")
>> ],
>> "agent-lib" => undefined,
>> "agent-path" => undefined,
>> "debug-enabled" => false,
>> "debug-options" => undefined,
>> "env-classpath-ignored" => undefined,
>> "environment-variables" => undefined,
>> "heap-size" => "256m",
>> "java-agent" => undefined,
>> "java-home" => undefined,
>> "jvm-options" => undefined,
>> "max-heap-size" => "256m",
>> "max-permgen-size" => undefined,
>> "permgen-size" => undefined,
>> "stack-size" => undefined,
>> "type" => undefined
>> }
>>
>> {
>> "operation" => "add",
>> "address" => [
>> ("host" => "master"),
>> ("server-config" => "prod_copy")
>> ("system-property" => "test")
>> ],
>> "boot-time" => false,
>> "value" => "value"
>> }
>>
>> basicly every resource needs its own add operation
>>
>> --
>> tomaz
>>
>> On Mon, Oct 22, 2012 at 11:17 AM, Heiko Braun <hbraun@redhat.com

>> <mailto:hbraun@redhat.com>> wrote:
>>
>>
>>
>>
>> I am working on a use cases that enables people to "copy"
>> resources. I.e. creating a clone of a server configuration under a
>> new name. I've realised that recursive add operations, covering a
>> larger resource tree don't seem to work (see example below). Is
>> there any "switch" that I am not aware of, or this simply not work
>> due to the design of the operation handlers?
>>
>>
>> [INFO] {
>> [INFO] "operation" => "add",
>> [INFO] "address" => [
>> [INFO] ("host" => "master"),
>> [INFO] ("server-config" => "prod_copy")
>> [INFO] ],
>> [INFO] "auto-start" => true,
>> [INFO] "cpu-affinity" => undefined,
>> [INFO] "group" => "production-1",
>> [INFO] "interface" => undefined,
>> [INFO] "path" => undefined,
>> [INFO] "priority" => undefined,
>> [INFO] "socket-binding-group" => "full-sockets",
>> [INFO] "socket-binding-port-offset" => 150,
>> [INFO] "jvm" => {"default" => {
>> [INFO] "agent-lib" => undefined,
>> [INFO] "agent-path" => undefined,
>> [INFO] "debug-enabled" => false,
>> [INFO] "debug-options" => undefined,
>> [INFO] "env-classpath-ignored" => undefined,
>> [INFO] "environment-variables" => undefined,
>> [INFO] "heap-size" => "256m",
>> [INFO] "java-agent" => undefined,
>> [INFO] "java-home" => undefined,
>> [INFO] "jvm-options" => undefined,
>> [INFO] "max-heap-size" => "256m",
>> [INFO] "max-permgen-size" => undefined,
>> [INFO] "permgen-size" => undefined,
>> [INFO] "stack-size" => undefined,
>> [INFO] "type" => undefined
>> [INFO] }},
>> [INFO] "system-property" => {"test" => {
>> [INFO] "boot-time" => false,
>> [INFO] "value" => "value"
>> [INFO] }}
>> [INFO] }
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list

>> jboss-as7-dev@lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

>>
>>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev