Re: [wildfly-dev] Metrics & runtime attribute registration

I agree it's better to be uniform. There are a few things we need to resolve though before making this the policy. 1) An attribute description includes the 'nillable' field, which indicates whether a client can expect ModelType.UNDEFINED as the attribute value. With this change, every metric may return ModelType.UNDEFINED, since there cannot be a value if the process is in --admin-only mode. I see two options: a) For every metric we automatically record 'true' as the value for 'nillable'. The downside here is there is no way for a client to know if ModelType.UNDEFINED is a valid value when the process isn't in --admin-only. b) We leave things as is, but clients can check if the 'access-type' field has a value of 'metric' and use that to understand that the value may sometimes be ModelType.UNDEFINED regardless of what 'nillable' says. As I typed this I've formed a strong preference for a). To me b) is voodoo. 2) We reuse the same ResourceDefinition class on both a HostController and on a server. The use on a HostController is to define the domain level resource (e.g. /profile=*/subsystem=foo). When a normal extension is running on a host controller, it *should not* register metrics.[1] Just because we reuse a ResourceDefinition class doesn't mean the resource is the same, and a /profile=*/subsystem=foo resource is not the same as /subsystem=foo on a server. It's just a chunk of config and does not have metrics. The ExtensionContext has methods that can be used by extensions to figure out this kind of state stuff. As part of implementing this policy we'd change the behavior of the isRuntimeOnlyRegistrationValid() method so hopefully this kind of change would be transparent to existing extensions. 3) There a difference between registering a resource's definition and actually handling a request for the metric. I expect most metric read handlers are not written to function properly if the underlying services are not there. Hopefully most will "just work" based on extending some of our base handler classes, which will bypass execution in an --admin-only server. But we should expect that this change will result in some breakage that will have to be cleaned up as part of the work. Cheers, Brian [1] Unless it's a host extension; which we can get into if anyone cares. On 7/14/15 6:13 AM, Tristan Tarrant wrote: -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat