On 11/14/13 9:58 AM, Heiko Braun wrote:
> *
> *
> While working on the console extension mechanism [1], I discovered thatIt's not bogus. It's a per-spec description of an attribute with
> 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.
>
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*
>> */server-group=**
>
> "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"
> }
>
>
> _______________________________________________>
> "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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev