On 20/05/14 18:41, Brian Stansberry wrote:
On 5/20/14, 12:13 PM, Darran Lofthouse wrote:
> Just pulling together some related HTTP management interface changes and
> I see this one is still pending: -
>
>
https://issues.jboss.org/browse/WFLY-907
>
> Are we interested in addressing this one?
>
Yes.
> Personally I am not convinced we need to be going beyond just using
> appropriate codes from the existing set of status codes, anything else
> would mean HTTP users get specific information that native users do not.
>
> However one thought, could we add some form of category to the actual
> failure response? That way we would have something we can use to map a
> status code, we already have another case in the code base that checks
> the error code to decide which status code to use!! If we added a
> category to a failure clients would then also potentially be able to use
> this themselves.
>
That's fine, so long as it does not alter the structure of the
response's "failure-description" field. IOW it would need to be a
sibling field to "failure-description", not a child.
+1 that is what I was thinking, a new field so existing clients that
don't query for it will not need to handle it.
I'm not happy at all with some of the stuff I've done using
message ids
in failure descriptions to decide what to do about failures, so I'd be
happy to see a better mechanism.
> Regards,
> Darran Lofthouse.
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>