<div dir="ltr"><div><div><div><div><div>To be fair it is bit worse than only examples Heiko showed.<br><br>we currently have around 4 or even maybe 5 different ways properties are represented in the model.<br><br></div>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"<br>
<br></div>so narrow it down we now have <br>1) PropertiesAttributeDefinition, basicly complex attribute with key & value<br></div>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<br>
</div>3) custom ListAttributeDefinition based attributes, <br></div><div><div>4) custom complex object implementations for example ModuleOptions referenced up, which btw is deprecated and was replaced with solution described under #2<br>
</div><div><br>and some hybrids in between<br><br></div><div>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.<br>
</div><div><br></div><div>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.<br></div><div>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,<br>
</div><div>most obvious case of this would be security subsystem.<br><br>--<br></div><div>tomaz<br></div><div><div><br><div><div><div><br></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Nov 14, 2013 at 6:45 PM, Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11/14/13 9:58 AM, Heiko Braun wrote:<br>
> *<br>
> *<br>
<div class="im">> While working on the console extension mechanism [1], I discovered that<br>
> we don't use a common representation of properties within the management<br>
> model. Below are two descriptions of properties (name/value pairs) taken<br>
> from security domains and server-groups. Server-groups use a addressable<br>
> resource representations for name value pairs, while security domains<br>
> use some (bogus?) definition of type=object and value-type=String.<br>
><br>
<br>
</div>It's not bogus. It's a per-spec description of an attribute with<br>
Map<String, String> semantics. This is a conceptually valid construct if<br>
the resource involved consumes the map as a unit.<br>
<br>
A set of system properties is not an attribute with Map<String, String><br>
semantics. Each individual property has a largely independent nature.<br>
The JDK exposes a map API for dealing with them, but that's not really<br>
fundamental to what a system property is.<br>
<br>
Take the above as an FYI historical explanation. I don't pretend that<br>
every name/value pair case in our management model is handled<br>
consistently based on that rationale.<br>
<br>
> /Is it possible to make resources rely on the same representation for<br>
> properties? /<br>
><br>
<br>
It's a matter of resourcing. How critical is this problem? I'd like to<br>
convert all the type=OBJECT,value-type=STRING ones to a<br>
resource-per-entry approach, but it's a lot of work. We'd still have to<br>
support passing the entire map as an attribute to :add (both for<br>
compatibility and because it's often for more usable for CLI users) and<br>
for compatibility we'd also have to support the existing attribute as an<br>
alternate view.<br>
<div class="im"><br>
> I don't even know how it's currently possible to define a login module<br>
> option using the CLI today. Non addressable resources cannot be<br>
> *:add()'ed, can't they?<br>
</div>> *<br>
<br>
The CLI parser can read complex parameter values<br>
<br>
:add(module-options={a=b,c=d})<br>
<br>
> *<br>
> */profile=default/subsystem=security/security-domain=other/authentication=classic/login-module=RealmDirect*<br>
<div class="im">><br>
><br>
> "module-options" => {<br>
> "type" => OBJECT,<br>
> "description" => "List of module options containing a<br>
> name/value pair.",<br>
> "expressions-allowed" => true,<br>
> "nillable" => true,<br>
> "value-type" => STRING,<br>
> "access-type" => "read-write",<br>
> "storage" => "configuration",<br>
> "restart-required" => "no-services"<br>
> }<br>
><br>
><br>
</div>> */server-group=**<br>
<div><div class="h5">><br>
> "system-property" => {<br>
> "description" => "A list of system properties to<br>
> set on all servers in this server-group.",<br>
> "model-description" => {"*" => {<br>
> "description" => "A system property to set on<br>
> all servers in this server-group.",<br>
> "access-constraints" => {"sensitive" =><br>
> {"system-property" => {"type" => "core"}}},<br>
> "attributes" => {<br>
> "value" => {<br>
> "type" => STRING,<br>
> "description" => "The value of the<br>
> system property.",<br>
> "expressions-allowed" => true,<br>
> "nillable" => true,<br>
> "min-length" => 0L,<br>
> "max-length" => 2147483647L,<br>
> "access-type" => "read-write",<br>
> "storage" => "configuration",<br>
> "restart-required" => "no-services"<br>
> },<br>
> "boot-time" => {<br>
> "type" => BOOLEAN,<br>
> "description" => "If true the system<br>
> property is passed on the command-line to the started server jvm. If<br>
> false, it will be pushed to the server as part of the startup sequence.",<br>
> "expressions-allowed" => true,<br>
> "nillable" => true,<br>
> "default" => true,<br>
> "access-type" => "read-write",<br>
> "storage" => "configuration",<br>
> "restart-required" => "no-services"<br>
> }<br>
> },<br>
> "operations" => undefined,<br>
> "children" => {}<br>
> }}<br>
> }<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Brian Stansberry<br>
Principal Software Engineer<br>
JBoss by Red Hat<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</font></span></blockquote></div><br></div>