[jboss-as7-dev] Recursive "add" operations
Brian Stansberry
brian.stansberry at redhat.com
Mon Oct 22 09:53:52 EDT 2012
On 10/22/12 8:28 AM, Tomaž Cerar wrote:
> Inline...
>
> On Mon, Oct 22, 2012 at 3:16 PM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at 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.
Good point; thanks Tomaz.
A few other details about the ":describe" op:
1) It will only be found on the root resource of a *subsystem*. Nowhere
else.
2) It's a "private" op, meaning it was designed for internal use and
isn't a long-term supported end user API. So its description doesn't
show up in the metadata.
3) It's not required to be registered on a server. It's only required on
a Host Controller. I'm not aware of any subsystems *not* registering it
on a server (doing that would require a trivial if test before
registering) but it's possible a subsystem might not register it.
>
>
>
> 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>
> > <mailto: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>
> >> <mailto: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>
> <mailto: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 <mailto: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
> _______________________________________________
> 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
>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
More information about the jboss-as7-dev
mailing list