10:58 a.m.
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.
Is it possible to make resources rely on the same representation for properties?
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?
/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" => {}
}}
}
12:45 p.m.
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
5: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
3:58 a.m.
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
Consolidation on these two would already be a great help. But I would even take it
further:
Why do we have complex attributes (ModelType.Object, your case 1) at all? IMO the most
straight forward approach would be to only allow for attributes to be simple types
(ModelType.<String|Int,Bool,etc>) and enforce any ModelType.Object to become a sub
resources (addressable).
Mangling complex types into attributes creates a lot of ambiguity and is the main driver
for creating edge cases and workarounds.
A word on backwards compatibility:
We've done a fine job so far, but if we get a chance (WF.Next) we should try to
correct the model and if necessary break compatibility.
regards, Heiko
On 14 Nov 2013, at 23:30, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
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.
9:32 a.m.
I'm for consistency, mostly because when we use resources and when we
use map attributes is pretty arbitrary now.
But I don't understand why a properly described map attribute would be
problematic for a console. I don't see why any attribute, no matter how
complex, should be problematic for a console so long as it is fully and
properly described.
I'm concerned about it because breaking compatibility by completely
removing the ability to treat things as a coherent map is a major
reduction in usability:
type=foo:add(things={a=1,b=2})
vs
batch
type=foo:add
type=foo/thing=a:add(value=1)
type=foo/thing=b:add(value=2)
run-batch
We get usability bug reports all the time when users need to do the
latter, mostly because people omit batch/run-batch. The solution being
to add a "things" param to type=foo so people can do the whole thing in
one go.
I'm fine with moving to consistently having subresource representation
if it's critical for the console, but only if we can still support
"things" as an optional param.
This is also much easier:
type=foo:write-attribute(name=things,value={a=2,c=3})
vs
batch
type=foo/thing=a:write-attribute(name=value,value=2)
type=foo/thing=b:remove
type=foo/thing=c:add(value=3)
run-batch
On 11/15/13 2:58 AM, Heiko Braun wrote:
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
Consolidation on these two would already be a great help. But I would
even take it further:
Why do we have complex attributes (ModelType.Object, your case 1) at
all? IMO the most straight forward approach would be to only allow for
attributes to be simple types (ModelType.<String|Int,Bool,etc>) and
enforce any ModelType.Object to become a sub resources (addressable).
Mangling complex types into attributes creates a lot of ambiguity and is
the main driver for creating edge cases and workarounds.
A word on backwards compatibility:
We've done a fine job so far, but if we get a chance (WF.Next) we should
try to correct the model and if necessary break compatibility.
regards, Heiko
On 14 Nov 2013, at 23:30, Tomaž Cerar <tomaz.cerar(a)gmail.com
<mailto:tomaz.cerar@gmail.com>> wrote:
> 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.
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
9:50 a.m.
On 15/11/13 14:32, Brian Stansberry wrote:
I'm for consistency, mostly because when we use resources and
when we
use map attributes is pretty arbitrary now.
Not sure if I would go that far, I know recently I have used resources
where I really wanted the properties to be manageable independently of
each other.
But I don't understand why a properly described map attribute
would be
problematic for a console. I don't see why any attribute, no matter how
complex, should be problematic for a console so long as it is fully and
properly described.
I'm concerned about it because breaking compatibility by completely
removing the ability to treat things as a coherent map is a major
reduction in usability:
type=foo:add(things={a=1,b=2})
vs
batch
type=foo:add
type=foo/thing=a:add(value=1)
type=foo/thing=b:add(value=2)
run-batch
We get usability bug reports all the time when users need to do the
latter, mostly because people omit batch/run-batch. The solution being
to add a "things" param to type=foo so people can do the whole thing in
one go.
I'm fine with moving to consistently having subresource representation
if it's critical for the console, but only if we can still support
"things" as an optional param.
This is also much easier:
type=foo:write-attribute(name=things,value={a=2,c=3})
vs
batch
type=foo/thing=a:write-attribute(name=value,value=2)
type=foo/thing=b:remove
type=foo/thing=c:add(value=3)
run-batch
On 11/15/13 2:58 AM, Heiko Braun wrote:
>
>
> 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
>
> Consolidation on these two would already be a great help. But I would
> even take it further:
>
> Why do we have complex attributes (ModelType.Object, your case 1) at
> all? IMO the most straight forward approach would be to only allow for
> attributes to be simple types (ModelType.<String|Int,Bool,etc>) and
> enforce any ModelType.Object to become a sub resources (addressable).
>
> Mangling complex types into attributes creates a lot of ambiguity and is
> the main driver for creating edge cases and workarounds.
>
> A word on backwards compatibility:
>
> We've done a fine job so far, but if we get a chance (WF.Next) we should
> try to correct the model and if necessary break compatibility.
>
> regards, Heiko
>
> On 14 Nov 2013, at 23:30, Tomaž Cerar <tomaz.cerar(a)gmail.com
> <mailto:tomaz.cerar@gmail.com>> wrote:
>
>> 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.
>>
>
11:24 a.m.
On 11/15/13 8:50 AM, Darran Lofthouse wrote:
On 15/11/13 14:32, Brian Stansberry wrote:
> I'm for consistency, mostly because when we use resources and when we
> use map attributes is pretty arbitrary now.
Not sure if I would go that far, I know recently I have used resources
where I really wanted the properties to be manageable independently of
each other.
It's pretty arbitrary. :) That doesn't mean there's no rationale for
anything. Just that you won't find consistent application of a rationale
across the server.
> But I don't understand why a properly described map attribute
would be
> problematic for a console. I don't see why any attribute, no matter how
> complex, should be problematic for a console so long as it is fully and
> properly described.
>
> I'm concerned about it because breaking compatibility by completely
> removing the ability to treat things as a coherent map is a major
> reduction in usability:
>
> type=foo:add(things={a=1,b=2})
>
> vs
>
> batch
> type=foo:add
> type=foo/thing=a:add(value=1)
> type=foo/thing=b:add(value=2)
> run-batch
>
> We get usability bug reports all the time when users need to do the
> latter, mostly because people omit batch/run-batch. The solution being
> to add a "things" param to type=foo so people can do the whole thing in
> one go.
>
> I'm fine with moving to consistently having subresource representation
> if it's critical for the console, but only if we can still support
> "things" as an optional param.
>
> This is also much easier:
>
> type=foo:write-attribute(name=things,value={a=2,c=3})
>
> vs
>
> batch
> type=foo/thing=a:write-attribute(name=value,value=2)
> type=foo/thing=b:remove
> type=foo/thing=c:add(value=3)
> run-batch
>
>
>
> On 11/15/13 2:58 AM, Heiko Braun wrote:
>>
>>
>> 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
>>
>> Consolidation on these two would already be a great help. But I would
>> even take it further:
>>
>> Why do we have complex attributes (ModelType.Object, your case 1) at
>> all? IMO the most straight forward approach would be to only allow for
>> attributes to be simple types (ModelType.<String|Int,Bool,etc>) and
>> enforce any ModelType.Object to become a sub resources (addressable).
>>
>> Mangling complex types into attributes creates a lot of ambiguity and is
>> the main driver for creating edge cases and workarounds.
>>
>> A word on backwards compatibility:
>>
>> We've done a fine job so far, but if we get a chance (WF.Next) we should
>> try to correct the model and if necessary break compatibility.
>>
>> regards, Heiko
>>
>> On 14 Nov 2013, at 23:30, Tomaž Cerar <tomaz.cerar(a)gmail.com
>> <mailto:tomaz.cerar@gmail.com>> wrote:
>>
>>> 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.
>>>
>>
>
>
_______________________________________________
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
9:50 a.m.
On 15 Nov 2013, at 14:32, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
I'm for consistency, mostly because when we use resources and
when we
use map attributes is pretty arbitrary now.
But I don't understand why a properly described map attribute would be
problematic for a console. I don't see why any attribute, no matter how
complex, should be problematic for a console so long as it is fully and
properly described.
I'm concerned about it because breaking compatibility by completely
removing the ability to treat things as a coherent map is a major
reduction in usability:
type=foo:add(things={a=1,b=2})
vs
batch
type=foo:add
type=foo/thing=a:add(value=1)
type=foo/thing=b:add(value=2)
run-batch
We get usability bug reports all the time when users need to do the
latter, mostly because people omit batch/run-batch. The solution being
to add a "things" param to type=foo so people can do the whole thing in
one go.
I'm fine with moving to consistently having subresource representation
if it's critical for the console, but only if we can still support
"things" as an optional param.
This is also much easier:
type=foo:write-attribute(name=things,value={a=2,c=3})
vs
batch
type=foo/thing=a:write-attribute(name=value,value=2)
type=foo/thing=b:remove
type=foo/thing=c:add(value=3)
run-batch
Also, in the transformers it is a total nightmare moving from:
type=foo:write-attribute(name=things,value={a=2,c=3})
to
type=foo/thing=a:write-attribute(name=value,value=2)
type=foo/thing=b:remove
type=foo/thing=c:add(value=3)
i.e. transforming from the latter to the first
On 11/15/13 2:58 AM, Heiko Braun wrote:
>
>
> 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
>
> Consolidation on these two would already be a great help. But I would
> even take it further:
>
> Why do we have complex attributes (ModelType.Object, your case 1) at
> all? IMO the most straight forward approach would be to only allow for
> attributes to be simple types (ModelType.<String|Int,Bool,etc>) and
> enforce any ModelType.Object to become a sub resources (addressable).
>
> Mangling complex types into attributes creates a lot of ambiguity and is
> the main driver for creating edge cases and workarounds.
>
> A word on backwards compatibility:
>
> We've done a fine job so far, but if we get a chance (WF.Next) we should
> try to correct the model and if necessary break compatibility.
>
> regards, Heiko
>
> On 14 Nov 2013, at 23:30, Tomaž Cerar <tomaz.cerar(a)gmail.com
> <mailto:tomaz.cerar@gmail.com>> wrote:
>
>> 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.
>>
>
--
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
11:18 a.m.
New subject: Property Representation (name/value) pairs in Management model
We've done a fine job so far, but if we get a chance (WF.Next) we
should try
to correct the model and if necessary break compatibility.
If breaking compatibility is really necessary, then also provide some sort of tool or
script or Windup rules
to make it as easy as possible to move from old to new. Where automation is not possible
provide clear instructions
for doing it manually. These components should all be part of the deliverable for such a
change.
----- Original Message -----
> From: "Heiko Braun" <hbraun(a)redhat.com>
> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
> Cc: wildfly-dev(a)lists.jboss.org
> Sent: Friday, November 15, 2013 3:58:55 AM
> Subject: Re: [wildfly-dev] Property Representation (name/value) pairs in Management
model
>
>
>
> 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
>
> Consolidation on these two would already be a great help. But I would even
> take it further:
>
> Why do we have complex attributes (ModelType.Object, your case 1) at all? IMO
> the most straight forward approach would be to only allow for attributes to
> be simple types (ModelType.<String|Int,Bool,etc>) and enforce any
> ModelType.Object to become a sub resources (addressable).
>
> Mangling complex types into attributes creates a lot of ambiguity and is the
> main driver for creating edge cases and workarounds.
>
> A word on backwards compatibility:
>
We've done a fine job so far, but if we get a chance (WF.Next) we
should try
to correct the model and if necessary break compatibility.
>
> regards, Heiko
>
> On 14 Nov 2013, at 23:30, Tomaž Cerar < tomaz.cerar(a)gmail.com > wrote:
>
>
>
>
> 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.
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
11:23 a.m.
New subject: Property Representation (name/value) pairs in Management model
On 11/15/13 10:18 AM, Rebecca Searls wrote:
> We've done a fine job so far, but if we get a chance (WF.Next) we should try
> to correct the model and if necessary break compatibility.
If breaking compatibility is really necessary, then also provide some sort of tool or
script or Windup rules
to make it as easy as possible to move from old to new. Where automation is not possible
provide clear instructions
for doing it manually. These components should all be part of the deliverable for such a
change.
Beaking compatibility really shouldn't be necessary, IMHO. It's just
more work to make it easy to manipulate a set of properties as a unit
while also making it easy to manipulate individual properties. It can be
done; it just takes quite a bit of effort.
----- Original Message -----
> From: "Heiko Braun" <hbraun(a)redhat.com>
> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
> Cc: wildfly-dev(a)lists.jboss.org
> Sent: Friday, November 15, 2013 3:58:55 AM
> Subject: Re: [wildfly-dev] Property Representation (name/value) pairs in Management
model
>
>
>
> 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
>
> Consolidation on these two would already be a great help. But I would even
> take it further:
>
> Why do we have complex attributes (ModelType.Object, your case 1) at all? IMO
> the most straight forward approach would be to only allow for attributes to
> be simple types (ModelType.<String|Int,Bool,etc>) and enforce any
> ModelType.Object to become a sub resources (addressable).
>
> Mangling complex types into attributes creates a lot of ambiguity and is the
> main driver for creating edge cases and workarounds.
>
> A word on backwards compatibility:
>
> We've done a fine job so far, but if we get a chance (WF.Next) we should try
> to correct the model and if necessary break compatibility.
>
> regards, Heiko
>
> On 14 Nov 2013, at 23:30, Tomaž Cerar < tomaz.cerar(a)gmail.com > wrote:
>
>
>
>
> 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.
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
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
3813
days inactive
3814
days old
9 comments
6 participants
participants (6)
-
Brian Stansberry -
Darran Lofthouse -
Heiko Braun -
Kabir Khan -
Rebecca Searls -
Tomaž Cerar