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
>