[ 
https://issues.apache.org/jira/browse/OLINGO-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15176280#comment-15176280
 ] 

Hans Schuell commented on OLINGO-894:
-------------------------------------

Hello Michael,

I am not sure, what you meant by _re-package_. If I build by own smaller 
olingo-odata2-core JAR, I have to do this on every fix you make.

Adding extra code for a feature that I currently do not use is also a bit 
weird. When I look at the code of 
{{org.apache.olingo.odata2.core.rest.ODataExceptionMapperImpl}}, I would say 
the catch clause is not very DevOps friendly:

{code}
    } catch (Exception e) {
      response = ODataResponse.entity("Exception during error handling 
occured!")
          .contentHeader(ContentType.TEXT_PLAIN.toContentTypeString())
          .status(HttpStatusCodes.INTERNAL_SERVER_ERROR).build();
    }
{code}

All what is left is, that there was an exception! Message and stack trace is 
gone. I cannot imagine that this helpful. When I first had the problem, I 
simply changed the code to:

{code}
    } catch (Exception e) {
      e.printStackTrace();  // (a) Do not hide unknown exceptions!
      // (b) Return some hints on the error
      response = ODataResponse.entity("Exception during Olingo OData error 
handling occured: " + e.getMessage())
          .contentHeader(ContentType.TEXT_PLAIN.toContentTypeString())
          .status(HttpStatusCodes.INTERNAL_SERVER_ERROR).build();
    }
{code}

It was OK for me, but as I mentioned, I did not want to rebuild the 
olingo-odata2-core JAR and put a copy to our project maven repository. But now 
I spread my code and everybody, who is using it, gets now in deep trouble, when 
server errors occur. They simply have no clue where it comes from!

So please think about the above code part. I am fully aware, that code (b) is 
from a security perspective not the best solution - the error message might 
help an attacker, but something like (a) is a must - because leaving no trace 
at the server side does not help in a real application. 

Best regards,
Hans

> 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)

Reply via email to