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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat