As JAX-RS implementations go, I suppose Apache CXF is as good as any. But among all the conveniences, it certainly has its share of surprises. For example, although I follow a typical REST resource URI scheme, I had to write a custom ResourceComparator to get certain lookups to work across multiple service beans. I’m over that now, but today’s bug was really weird.
In this case, I’m handling basic authentication in an upstream inInterceptor, pulling credentials from the message. This has several benefits, including simpler service beans. If credentials are missing or invalid, I do the usual 401 / 403 thing, but if authenticated, I inject a SecurityPolicy containing my Principal, like so:
message.put(SecurityContext.class, new BasicSecurityContext(userProfile));
.. with the hopes of my service bean having access via:
@Context SecurityContext securityContext
Trouble is, that came out null. Turns out, this is a known issue with CXF, and the work-around (barring unwanted extra plumbing) is to use javax.ws.rs.core.SecurityContext, not org.apache.cxf.security.SecurityContext. So much for polymorphism.