4:30 p.m.
To be fair it is bit worse than only examples Heiko showed.
we currently have around 4 or even maybe 5 different ways properties are
represented in the model.
also the system properties part is bit of exception as it has 3rd attribute
"boot-time" not just key & value, so they do not officially belong into
category of "properties"
so narrow it down we now have
1) PropertiesAttributeDefinition, basicly complex attribute with key & value
2) sub resources, where key = name of resource and there is only one
attribute under it with value, for example see PropertyResourceDefinition
and its usage. This is quite common
3) custom ListAttributeDefinition based attributes,
4) custom complex object implementations for example ModuleOptions
referenced up, which btw is deprecated and was replaced with solution
described under #2
and some hybrids in between
my intent is/was to unify most of this under #1 & #2, there are some good
use cases for #2 but in most cases when you need any special handling of
each and every property #1 works best and is simplest to use.
So i would say that if we only support first two in consoles we are good to
go, there should not be many exceptions to this anymore but if there is
they should be fixed.
Knowing most of the codebase there are only few exception still present and
most of them ware already replaced but still there only to preserve
backward compatibility,
most obvious case of this would be security subsystem.
--
tomaz
On Thu, Nov 14, 2013 at 6:45 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev