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

Petri Tuomola commented on FINERACT-1168:
-----------------------------------------

Hmmm... definitely agree with the problem, just wondering how to best fix this. 
Trying to get all the right information back to the client in all the error 
cases in test - but not in prod - could be quite difficult, unless as you say 
there's a switch somewhere. 

Maybe instead it might be possible to do the following: for testing, configure 
the Cargo Tomcat to log only ERROR and above to stdout, and then get Gradle to 
show the stdout from Tomcat when executing the ITs?

Not sure if that's possible - but if it is, then that would also have the added 
benefit of forcing us to sort out our logging, so that nothing is logged at 
level ERROR during successful operation. And also require us to route all the 
other things currently logged directly to stdout (e.g. OpenJPA, Jersey, 
Connector/J) to slf4j at appropriate log level...

 

> Integration Tests failure due to internal server errors should show server 
> side failure stack trace
> ---------------------------------------------------------------------------------------------------
>
>                 Key: FINERACT-1168
>                 URL: https://issues.apache.org/jira/browse/FINERACT-1168
>             Project: Apache Fineract
>          Issue Type: Improvement
>            Reporter: Michael Vorburger
>            Priority: Blocker
>
> IT failures like FINERACT-1167, already raised in FINERACT-927, are a PITA 
> (impossible) to debug.
> This is an IT failure due to a #500 means "something internal went wrong on 
> the server" - but we don't know what...
> To know what the problem was, the server should return the exception in the 
> HTTP body of the 500 response. The IT should then capture that, and include 
> it in the JUnit test failure.
> But in production, 500 errors should NOT show the stack trace - that is 
> typically considered a security problem. So we need some env var / sys prop 
> to enable it, just for debugging. Spring Boot probably actually already has 
> some... knob, for this?
> [~ptuomola] thought this may interest you.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to