Hi The NPE you are seeing has definitely been fixed but I'm curious why JSONProvider ends up creating a context for File - I'll add a test. Perhaps there's a bug where a JAX-RS method has actually been invoked and then the custom ExceptionMapper sets a custom Response entity and thus JAXRSOutInterceptor becomes confused about the actual type of the Response entity - it may have been already fixed - but I'll verify just in case
cheers, Sergey On Fri, Dec 31, 2010 at 1:13 AM, ssen <[email protected]> wrote: > > Sergey, > > I stepped through the JAXRSOutInterceptor.handleMessage and found the > cause. > > The issue is that if I do not wrap the java object in a GenericEntity, the > code first tries to find the JAXBContext of the object and in this case it > cannot. > > Then it tries to find the context (in AbstractJAXBProvider.getJAXBContext) > of the return type of the method, which in this case is a java.io.File. > Here > when it tries to instantiate a JAXBContext, the classloader returned is > null > and hence a NPE is thrown, which is caught by the interceptor and a generic > 500 error code is returned. The relevant code is JAXBContext.newInstance > call in AbstractJAXBProvider.getPackageContext - the type.getClassLoader() > returns null when the type is java.io.File. > > Looks like a bug to me. > > As a workaround, I wrapped the returned object in a GenericEntity instance, > and then it works since if the returned object is of GenericEntity, it is > happy and never tries to find the JAXBContext of the return type of the > method. > > Thanks for your help. > Shantanu > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/JAX-RS-Custom-Exception-not-getting-progagated-tp3322048p3323129.html > Sent from the cxf-user mailing list archive at Nabble.com. >
