[wildfly-dev] Property Representation (name/value) pairs in Management model
Tomaž Cerar
tomaz.cerar at gmail.com
Thu Nov 14 17:30:26 EST 2013
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 at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20131114/44a93e64/attachment.html
More information about the wildfly-dev
mailing list