I will continue discussion here, to have broader audience. Seems most of you are in favor of new map-* list-* operations but not all of you like idea of enhanced read/write-attribute ops. To shed bit of light on this. Complex attributes are here to stay and will always be around. They are/will be used in lesser extend as in original AS7 code but in any case there are here to stay. With extended syntax for write/read-attribute operations I was mostly thinking of simplifying complex attributes read/write Also keeping in mind that every object is also a map and can be addressed and updated as such. having syntax like we could support simple things like this: :write-attribute(name=timeout.unit, value="MINUTES) which we are in dare need of. as current approach for that is :write-attribute(name=timeout, value="{value=10, unit=MINUTES}") where we need to know/change whole object instead of just part of it. I think having this syntax wouldn't change anything for console at all. It would however require some work in CLI area, especially if we would want to have tab completion. Even today there is metadata that tells what complex attributes are and how are they structured, we just don't utilize this info. As it goes for introducing ModelType.MAP I am all in favor of. As it would allow us also few more things when it comes to types of map as currently we only have support for Map<String,?> where key can only be String. Introducing ModelType.MAP would also require us to introduce few new model metadata constructs such as key-type. I discussed ModelType.MAP with Brian a bit, but he was not big fan as that would require us move all map attributes to use this which would be a big change (100+ attributes) and this would be big compatibility issue. The biggest problem with introducing it is that any object can be used/addressed as map and as such having extra type bit redundant. However we could probably introduce it for WildFly 10 (maybe 9) with jboss-dmr 2.x series. -- tomaz On Mon, Aug 18, 2014 at 10:01 AM, Heiko Braun <hbraun(a)redhat.com&gt; wrote:

On Mon, Aug 18, 2014 at 6:34 PM, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: Maybe I wasn't clear enough what I meant here. I only implied that we would add ModelType.MAP to jboss-dmr. All other changes would be part of WildFly management, with introducing new model key "key-type" and alike. But I can see what you meant and I am leaning more and more on *not* adding ModelType.MAP. All we need can be handled as part of wildfly mgmt apis to hide as much of "map internal impl" and as long people would use that api it wouldn't matter what impl is. Once we move to annotation driven model most of this will be hidden anyway.

On 8/18/14, 3:01 AM, Heiko Braun wrote: We couldn't do this for compatibility reasons, even if the only complex attributes left were legacy aliases for resources. I want a resource to have some meaning to an end user as an independent manageable entity. An internal data structure that's simply part of the configuration of some other entity isn't an independently manageable entity. So, a big part of Tomaz's brief in this task is to: a) Drive a better clarification of the boundaries of what an "independent manageable entity" is. In the "squatter resource" discussion for example, David had what looked like a pretty limited take on what was "independent". The other end of the spectrum would be something that should be added/removed from the config as a unit but doesn't actually result in any distinct services. Heiko, you're on this end of the spectrum. I want Tomaz to find and illustrate the cases in between and see if we can come up with some concrete criteria. You guys have already done a great service here with your analysis of the model. b) See where we have complex attributes that really are independent manageable entities, and thus should be resources. (We'll fix these, but that's not part of the immediate requirements/design task.) c) See where we have resources that aren't indepedent and thus should be represented as attributes. (We *may* fix these, but that's not part of the immediate task.) d) If we end up with any complex attributes left (besides simple lists and maps), sort out with your team what API support you need to be able to deal with them. If converting something that's not independent to a child resource makes your life easier because you can use read-resource-definition etc, then we need equivalent ops for complex attributes. In the past we've had some complex attributes that exist primarily to support changing multiple fields in an atomic step. For example "time" and "unit" combined in single attribute.[1] Since the CLI batch command and the underlying composite op let users make multiple changes atomically, this kind of thing is IMHO an insufficient reason for a complex attribute or a child resource. Simple conceptual grouping of related attributes is an insufficient reason for either a child resource or a complex attribute. We'll introduce a new bit of metadata to use for grouping. [1] Side note: I don't think 'time' and 'unit' are very compelling as an complex attribute; I just mention it as an understandable example. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat