[wildfly-dev] Property Representation (name/value) pairs in Management model

[Brian Stansberry]

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 at redhat.com>
>> To: "Tomaž Cerar" <tomaz.cerar at gmail.com>
>> Cc: wildfly-dev at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> 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