Thanks Alex, that is helpful context. I will keep returning raw ints as agreed, and address any remaining review comments on the PR.
Harshita On Mon, Aug 3, 2026 at 10:17 AM Alexandre Dutra <[email protected]> wrote: > Hi Harshita, > > Thanks for the PR, I left some comments. > > In fact, the Jax-RS API is present in polaris-core, but declared in > implementation scope in Gradle. So in short, I agree it's better to > return raw ints, but nothing prevents you from using the Jax-RS API > constants in the code. > > I also agree it's OK to have it in polaris-core rather than in the > service layer. > > Thanks, > Alex > > On Sat, Aug 1, 2026 at 7:43 AM Harshita Joshi <[email protected]> > wrote: > > > > Hi, > > > > I opened PR #5206 to address issue #5167, which moves HTTP status mapping > > from PolarisExceptionMapper into the PolarisException hierarchy via a > > default httpStatusCode() method returning an int. @flyrain approved the > > code but raised a fair > > question: This puts an HTTP/transport concept into polaris-core, which is > > usually transport-neutral. The method uses plain int (no jakarta.ws > > dependency), but semantically it still represents an HTTP status code. > > Would the community prefer to keep this in polaris-core, or should the > > status mapping stay entirely in the service layer? > > > > PR: https://github.com/apache/polaris/pull/5206 > > > > Thanks, > > Harshita >
