[wildfly-dev] Metrics & runtime attribute registration

[Kabir Khan]

Could these be added to the registry with some special flag?
My vague thought is that they would then be ‘hidden’ in admin-only mode, unless r-r-d is called with some new parameter.
In normal mode they are visible.

> On 14 Jul 2015, at 20:59, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> One thing that came up yesterday is generating code based on the model 
> description. If you're doing that you want as much data as possible. You 
> don't want to bring up an -admin-only process (say one embedded in the 
> code generation tool) just to read and generate, and then find out you 
> missed a bunch of attributes.
> 
> On 7/14/15 1:52 PM, James R. Perkins wrote:
>> 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>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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> --
>> James R. Perkins
>> JBoss by Red Hat
>> 
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev