[jboss-as7-dev] Recursive "add" operations

[Brian Stansberry]

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.


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 at gmail.com
> <mailto:tomaz.cerar at 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 at redhat.com
>> <mailto:hbraun at 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 at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat