I see your point grouping similar attributes as one ObjectType attribute. For HAL it's always easier to work with simple attributes. This is especially true for automatically generated UIs.

OTOH attributes tuples like {path, relative-to} are quite common. The logging subsystem uses them in various resources. So adding support for those tuples seems reasonable (in fact we already support them in HAL.next). So keeping them for /subsystem=elytron/properties-realm=* is ok for me.

What we should avoid though are deeply nested attributes. (e.g. lists inside objects)

On Wed, Sep 28, 2016 at 1:16 PM, Darran Lofthouse <darran.lofthouse@jboss.com> wrote:
A number of resources have been flagged within the Elytron subsystem
requesting that we review the use of ObjectTypes (and similar) within
the resource definitions.

Some I know we can simplify but others I would like to get a second
opinion on, firstly I wanted to look at the 'properties-realm' resource.


This is a realm implemented to make use of the legacy properties files
users of AS7 through WF10 will be familiar with so we need to reference
two different properties files with the group-properties being optional.

Where a file is referenced it is common to reference both a path and a
relative-to, rather than looking to find unique names for two path
attributes and unique names for two relative-to attributes I have
wrapped in specific OBJECT type attributes.

I could achieve a similar grouping by flattening and using attribute
groups but then the path and relative-to attributes would require unique
names.  Personally I just felt that for two attributes always used as a
pair it was cleaner to wrap them into one.

Note:  Checking the output myself the path should not be nillable and
the relative-to should not allow expressions so those two will be corrected.

Darran Lofthouse.
wildfly-dev mailing list

Harald Pehl
JBoss by Red Hat