If the attribute is going to be undefined what is the benefit of having it in the model? If the tooling is looking for an attribute that doesn't exist wouldn't they just check for the existence with ModelNode.has()?

I don't write any tooling so maybe I'm off :) I just don't see the benefit of adding an attribute that will always be UNDEFINED though.

On 07/13/2015 02:26 PM, Tomaž Cerar wrote:
Hey guys,

We had interesting discussion with Brian on https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986
about how we register runtime/metric attribute on resources.

There are many cases where subsystems only register attributes / resources only when server is booting into normal mode.
but if it server is booted only to "admin mode" all that runtime/metrics attributes are not registered and as such not seen in the model.

Registering runtime attributes only in normal mode can cause that results of :read-resource-description/read-resource
wouldn't return attributes that are on resources if server is started in admin mode or even CLI standalone.
Our metadata already provides information if attributes is runtime/metric/configuration.

This can cause problems for tooling that relies on output of those two operations.

Looking at current state of the code, we do use both ways of registering attributes either conditionally or always.
This probably originates from times where there was no good api/way to mark attribute/resource as runtime.

I am personally am in favor of always registering runtime attributes as this makes sure that user isn't surprised by some extra/missing
attributes based on fact how it is starting the server.


What do you guys think? Should we always register it or have it conditionally?

--
tomaz




_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
JBoss by Red Hat