[wildfly-dev] Property Representation (name/value) pairs in Management model

Brian Stansberry brian.stansberry at redhat.com
Thu Nov 14 12:45:59 EST 2013


On 11/14/13 9:58 AM, Heiko Braun wrote:
> *
> *
> While working on the console extension mechanism [1], I discovered that
> we don't use a common representation of properties within the management
> model. Below are two descriptions of properties (name/value pairs) taken
> from security domains and server-groups. Server-groups use a addressable
> resource representations for name value pairs, while security domains
> use some (bogus?) definition of type=object and value-type=String.
>

It's not bogus. It's a per-spec description of an attribute with 
Map<String, String> semantics. This is a conceptually valid construct if 
the resource involved consumes the map as a unit.

A set of system properties is not an attribute with Map<String, String> 
semantics. Each individual property has a largely independent nature. 
The JDK exposes a map API for dealing with them, but that's not really 
fundamental to what a system property is.

Take the above as an FYI historical explanation. I don't pretend that 
every name/value pair case in our management model is handled 
consistently based on that rationale.

> /Is it possible to make resources rely on the same representation for
> properties? /
>

It's a matter of resourcing. How critical is this problem? I'd like to 
convert all the type=OBJECT,value-type=STRING ones to a 
resource-per-entry approach, but it's a lot of work. We'd still have to 
support passing the entire map as an attribute to :add (both for 
compatibility and because it's often for more usable for CLI users) and 
for compatibility we'd also have to support the existing attribute as an 
alternate view.

> I don't even know how it's currently possible to define a login module
> option using the CLI today. Non addressable resources cannot be
> *:add()'ed, can't they?
> *

The CLI parser can read complex parameter values

:add(module-options={a=b,c=d})

> *
> */profile=default/subsystem=security/security-domain=other/authentication=classic/login-module=RealmDirect*
>
>
> "module-options" => {
>                  "type" => OBJECT,
>                  "description" => "List of module options containing a
> name/value pair.",
>                  "expressions-allowed" => true,
>                  "nillable" => true,
>                  "value-type" => STRING,
>                  "access-type" => "read-write",
>                  "storage" => "configuration",
>                  "restart-required" => "no-services"
>              }
>
>
> */server-group=**
>
>   "system-property" => {
>                      "description" => "A list of system properties to
> set on all servers in this server-group.",
>                      "model-description" => {"*" => {
>                          "description" => "A system property to set on
> all servers in this server-group.",
>                          "access-constraints" => {"sensitive" =>
> {"system-property" => {"type" => "core"}}},
>                          "attributes" => {
>                              "value" => {
>                                  "type" => STRING,
>                                  "description" => "The value of the
> system property.",
>                                  "expressions-allowed" => true,
>                                  "nillable" => true,
>                                  "min-length" => 0L,
>                                  "max-length" => 2147483647L,
>                                  "access-type" => "read-write",
>                                  "storage" => "configuration",
>                                  "restart-required" => "no-services"
>                              },
>                              "boot-time" => {
>                                  "type" => BOOLEAN,
>                                  "description" => "If true the system
> property is passed on the command-line to the started server jvm. If
> false, it will be pushed to the server as part of the startup sequence.",
>                                  "expressions-allowed" => true,
>                                  "nillable" => true,
>                                  "default" => true,
>                                  "access-type" => "read-write",
>                                  "storage" => "configuration",
>                                  "restart-required" => "no-services"
>                              }
>                          },
>                          "operations" => undefined,
>                          "children" => {}
>                      }}
>                  }
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list