[
https://issues.apache.org/jira/browse/OLINGO-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15176523#comment-15176523
]
Michael Bolz commented on OLINGO-894:
-------------------------------------
Hello [~gira1],
with _re-package_ I mean the possibility to _copy_ the classes of a dependency
in your own _jar/war/.._ and during this step you could exclude classes (or
packages).
With maven there is the _shade_ plugin which provides support for this:
https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
As a idea for a workaround you could configure your application server to not
scan specific _jars/packages_ for annotations, so that the
{{ODataExceptionMapperImpl}} is not loaded by default.
For the IBM WebSphere I found this: [Reducing annotation searches during
application
deployment|http://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/trun_app_reduce_annot.html?lang=en].
For the issue I have to admit that the whole {{JAX-RS}} related parts should
all be in a separate maven module and not in the _core_ library module.
However such a change (extraction of the JAX-RS from the core) would be a
little bit _tricky_ if the backward compatibility should be kept.
And both of your suggestions are IMHO no good solutions.
_(b)_ for the from you mentioned security aspect and _(a)_ is a common _bad
practice_, instead a correct error handling should be done.
And in the case of Olingo where the {{ExceptionMapper}} is used as the very
last instance of exception handling the creation of a response with a 500
internal server error is acceptable (IMHO).
The fault and issue of Olingo is that the {{JAX-RS}} related parts are in the
core library.
However as mentioned before normally ever JEE application server has a way to
configure the _auto discovery/scanning_ for annotations. And IMHO this could be
the best solution for your issue.
It would be really nice if you could try this and give feedback.
Kind 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)
