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”]} ] } } So a standard response header whose value is a list of ModelNode, different messages using different node structures, but the norm being a simple string. Probably OperationContext would need to add a method addResponseWarning to take the details of constructing the header out of the hands of the handler authors. We’d have to make sure these headers propogate properly through the domain, so the effort is more than simply getting standalone. If the operation is a composite, there are no per-step response headers so the warning should not assume that the context of the warning is obvious. Warning authors forgetting that point is a possible source of UX issues. Is this worth the effort? This is driven by this one WFCORE-1987 issue, which is a bit unusual and in an ideal world would go away. But here’s the general pattern involved: 2 attributes in separate parts of the model should be consistent or you wil get bad runtime behavior User can use a CLI batch to set them both atomically, but web console users can’t do that, so even if the user will do the right thing there will be a moment where they are inconsistent So, failing is not good (forces users to use CLI + batch) For the same reason a WARN in the log is not great, as unrelated users may be required to react to log warns, and will be annoyed by seeing them just because their colleague didn’t use a batch Is that last statement enough reason to add this functionality vs just using the server log to warn, or just not warning at all? 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. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat

Yes. I think that was the right approach there, as those warnings were a pretty fundamental part of the result of the operation. I was going to say that the private API usage warnings we log couldn’t fit nicely, as they are done via MSC threads that don’t know about any management op. But thinking a bit more I think that’s probably solvable. It would be interesting if there were a nice way to integrate such keys with our existing i18n message infrastructure. Really we’d have to do that, or else have the keys unambiguously different from the message ids. It could be controllable via a request-header as well, allowing clients to declare what they want, overriding any server-side settings.. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat

Thanks Brian. ----- Original Message ----- Most likely. I have very little experience with mgmt ops code in domain mode. In such case I think either warning has to be very explicit(detailed what/where/why) or it would become complex type: { “outcome”=>”success”, “result”=>”foo”, “response-headers”=> { “warnings”=> { warning => { operation => { address,name,parameters} message = [""] }, warning => { operation => { address,name,parameters} message = [""] } } } } or { “outcome”=>”success”, “result”=>”foo”, “response-headers”=> { “warnings”=> { warning => { step => ["1"] message = [""] }, warning => { step => ["2"] message = [""] } } } } Though second option might be too cryptic for console users, unless it is well supported. No warning at all is a bad thing. Unless user is very experienced, such UX will be perceived as a bad design - well, unless exception/failure will be descriptive enough. Imagine that you change one tiny detail and server fails to boot up some, seemingly unrelated service. So as is, it seem to be a question of fixing current failure message( which for instance , in case of WFCORE-1987, does not seem viable) vs standardized warning mechanism.