Hi there,
i oftentimes have the situation that when i made a mistake while developing a CUBA app with studio (which happens fairly often 
) which leads to an exception in the app.log file, i would like get faster to the root cause of the problem. Currently i have the following options: Open the app.log in studio. Now what i see is a list of logging entries, that contain a whole lot of information. There are the information about something like FtsScheduler and RdbmsStore etc. that fly across the logging-screen in studio. When i scroll for a long time, i find my own exception. But oftentimes it is not the root cause of the exception, but rather the exception that gets thrown because of the original one (e.g. when the exception occurs in core and i see the one from the frontend). So i scroll even more. In case of groovy, the stacktraces get even longer. So basically it often takes more time that it should to track down the line of code that did not work out.
I know that i could solve the problem in a lot of different ways (that are not studio related):
- adjust logback.xml so that see only the “relevant” information in the app.log
- adjust logback.xml so that i create two files: app.log and app-detailed.log e.g. with different settings
- adjust logback.xml so that i log into something that will allow me to search better through the logs (like ELK installed locally e.g.)
- adjust the running log configuration through CUBA and see the logs in the CUBA screens
- write more integration tests in a TDD style
But actually i have trouble with all of those approaches. Changing the logback.xml manually mean that if i remove the deploy directory, my changes are gone (which would be ok since it is my own fault but anyway). But if i’m working on ten different CUBA applications i have to adjust all these logback.xml files. Using ELK is probably somewhat heaviweight, although i would end up in the best solution, because i am most flexible in looking at the log entries i’m interested in.
Using the CUBA screens for looking at the logs is a very good way in prod, but when i’m in dev mode i have studio open anyway, so it feels somewhat wrong to look at the screens. Additionally sometimes i can’t navigate to the CUBA screen anymore because the error would not let me to.
So what i would like to have is the possibility to switch the degree of details that i want to see in the log section of studio. Normally i’m not very interested in the stuff the frameworks logs when i want to debug my own stuff.
So here’s my wishlist for the logging output in studio:
- Change the logging information directly in studio
- save “logging configuration” that can be switched directly in studio
- persist these logging configurations independent of the CUBA project
- give the user the ability to express something along those lines of “cat app.log | grep -i ERROR” for drilling down further
- notify users in studio in a particular part of the logging screens when an exception occurs and offer them only the exception (with optional stacktrace)
I would be interested to hear from other people if they find themselfs in the same situation and if so, if the above mentioned solution would help.
Bye
Mario
See the following issue in our bug tracker: