[wildfly-dev] Add a warning if some configuration change has wider impact and could cause error?

[Bartosz Baranowski]

----- Original Message -----
> From: "Jeff Mesnil" <jmesnil at redhat.com>
> To: "Brian Stansberry" <brian.stansberry at redhat.com>
> Cc: "Bartosz Baranowski" <bbaranow at redhat.com>, wildfly-dev at lists.jboss.org
> Sent: Friday, January 6, 2017 5:48:11 PM
> Subject: Re: [wildfly-dev] Add a warning if some configuration change has wider impact and could cause error?
> 
> 
> > On 6 Jan 2017, at 17:24, Brian Stansberry <brian.stansberry at redhat.com>
> > wrote:
> > 
> > Any opinions? This is basically a proposal to provide a formal way of
> > including warning data in operations responses.
> > 
> > If we did it it would probably be something like:
> > 
> > {
> >  “outcome”=>”success”,
> >  “result”=>”foo”,
> >  “response-headers”=> {
> >    “warnings”=[
> >        “blah blah blah”,
> >       { “some_complex_issue: details”>[“x”,”y”,’z”]}
> >    ]
> >  }
> > }
> 
> We had a similar discussion while implementing :migrate operations for legacy
> subsystems and ended up using a "notification-warnings” parameter in the
> result node (as opposed to the response-headers node).
> 
> > 
> > Is that last statement enough reason to add this functionality vs just
> > using the server log to warn, or just not warning at all?
> 
> It’s nice to have for sure and would help having a consistent reporting
> systems in our management clients (we can imagine having flash warnings in
> the web console and special text in the CLI written to syserr for example).
> 
> In an ideal world, I think that any WARN logged in the server console that is
> caused by a management operation should be reported to the invoker.

Yes, in a way. But difference here is that WARN could come from any place, so we would have to intercept logger.
Rather than rely on dev to be through and be aware of implications of mgmt ops. Just guessing that it might become quite complicated.
For initial implementation I would just stick to original problem.

> I’d go a step further to constrain the warnings model as a dictionary where
> each key is a registered logger ID (e.g. XNIO001007) and a value a i18ned
> string (or a more complex i18ned structure).
> 
> Something like:
> 
> {
>  “outcome”=>”success”,
>  “result”=>”foo”,
>  “response-headers”=> {
>    “warnings” => {
>        “XNIO00107” => “some thing happens”,
>        “WFCORE1234” => { “some_complex_issue” => [“x”,”y”,’z”]}
>    }
>  }
> }
> 
> That’d be very helpful to build our knowledge base and report issues.
> 
> > In theory we could use the same facility to report management API
> > deprecation warnings back. Doing that might be annoying though. Those are
> > a less serious problem than this WFCORE-1987 thing.
> 
> If you go that way, you could somehow configure the level of reported
> warnings and let the admin configure the level of reported warnings:
> 
> addResponseWarning(String id, int level, String)
> addResponseWarning(String id, int level, ModelNode data)

Most likely level could be equal to logging.Level.

> 
> We now have a nice new core-management subsystem where the admin could change
> the reported warning level (defaulting to something corresponding to serious
> warnings, as opposed to minor warnings such as API deprecation).

Where? Or are you talking about above example?

> 
> jeff
> 
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
> 
>