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(a)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&g...
>>
>> 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
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev