[
https://issues.apache.org/jira/browse/OLINGO-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173247#comment-15173247
]
Michael Bolz commented on OLINGO-894:
-------------------------------------
Hello [~gira1],
I think the problem is the use of the {{javax.ws.rs.ext.ExceptionMapper}} in
the Olingo {{org.apache.olingo.odata2.core.rest.ODataExceptionMapperImpl}}.
Some JEE application servers scans all available code for {{ExceptionMapper}}
implementations even when the implementation is not used.
A workaround if you do not want to use the
{{org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet}} is that you
_re-package_ Olingo and exclude the {{org.apache.olingo.odata2.core.rest.*}}
package.
Another workaround could be that you use the customised error response handling
of Olingo.
There you can return an {{ODataErrorCallback}} implementation (e.g.
{{MyOwnErrorCallback}}) in the {{getCallback(..)}} method in your
{{ServiceFactory}} implementation.
Within the {{ODataErrorCallback}} implementation you can then handle the
exception as you wish.
Below some sample code snippets:
In `ServiceFactory`:
{code}
public <T extends ODataCallback> T getCallback(final Class<T>
callbackInterface) {
if(callbackInterface.isAssignableFrom(ODataErrorCallback.class)) {
return (T) new MyOwnErrorCallback();
}
return super.getCallback(callbackInterface);
}
{code}
In `ODataErrorCallback` implementation (e.g. “`MyOwnErrorCallback`”)
{code}
@Override
public ODataResponse handleError(final ODataErrorContext context) throws
ODataApplicationException {
if (context.getHttpStatus() == HttpStatusCodes.INTERNAL_SERVER_ERROR) {
return … // some self created ODataResponse
} else {
return EntityProvider.writeErrorDocument(context);
}
}
{code}
It would be nice to hear whether one of the workarounds fit for your use case.
Actual I do not think that the not so perfect use of the
{{javax.ws.rs.ext.ExceptionMapper}} can be changed easily.
However I will take a look into and give feedback.
Best Regards,
Michael
> Olingo 2 hides all JEE7 execption handling
> ------------------------------------------
>
> Key: OLINGO-894
> URL: https://issues.apache.org/jira/browse/OLINGO-894
> Project: Olingo
> Issue Type: Bug
> Components: odata2-core
> Affects Versions: V2 2.0.6
> Environment: JEE7 compliant application server. We use IBM WebSphere
> Liberty 8.5.5.8.
> Reporter: Hans Schuell
> Assignee: Michael Bolz
> Priority: Critical
>
> We are using "olingo-odata2-core" in a JEE7 application for parsing OData
> filter expressions. Whenever a runtime exception in the application is not
> catched, the Olingo component supresses all error information (cause, stack
> trace, ...) and reduce the information to "Exception during error handling
> occured!". This is very annoying and we always have to remove Olingo from the
> build to get the real error.
> We have made a sample project to show this. See
> https://github.com/giraone/olingo-bug. It is a totally simple JAX-RS
> implementation, which does not use Olingo, but it has a dependency on it in
> the pom.xml. This is sufficient to produce the problem. Please look at the
> readme.md and run the simple test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
