Provide an optional endpoint for logging Javascript errors

[sdeleuze]

When you are building a Java + Javascript based application with a significant complexity on client side (Angular, Ember or React application), a big issue is that you have no idea of the errors that occur on client side.

A good solution I have already experimented on big projects is composed of 2 parts:

• Client side: a Javascript file intercept invocations to functions like console.log() to send an HTTP request/websocket message to the server with the error
• Server side: A REST/Websocket endpoint receive the error message (usually a JSON object), parse it and print it to the log with the same level (DEBUG, INFO, etc.) used on the client.

It should be possible to change the client log level you send to the server dynamically.

This is a little bit more a client/server integration thing than usual, but on the projects I tested that it was just hugely useful some I think we should provide this in Boot. I will be happy to contribute a PR if you think this is something interesting.

[jchesterpivotal]

This would definitely be helpful for us. We have a large suite of Selenium tests. We've not found a happy and stable way to fail the tests when a javascript error occurs.

[jeanbza]

👍 this would be hugely helpful. As @jchesterpivotal said, we also have selenium tests, and we also have no great way other than to try and replicate locally.

[sdeleuze]

Please find in this gist a sample client side implementation. I do not expect we reuse it exactly as it is, but it is IMO a nice starting point for experimenting and discussing.

Any thoughts?

[philwebb]

@sdeleuze I think we should look at this for 1.4 as we're close to feature freeze on 1.3. It's a really nice idea but I think we're just going to run out of time for 1.3.x :(

[dsyer]

Someone could take Sebastien's code and publish it as a jar that anyone can consume in 1.3 (like I did with Jersey in 1.1). Then we can get people using it and build the features up for 1.4.

[snicoll]

👍

[sdeleuze]

I totally agree, any javascript code provided with Spring Boot will require a lot of testing with many browsers, so targeting 1.4 will allow us to get feedbacks, improve this draft implementation, etc.