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

[Rebecca Searls]

> 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 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
>