Cleanup / reduce verbosity of diagnostic output in Eclipse logs

[kdvolder]

There have been some complaints that STS 4 eclipse language server dumps a lot of verbose diagnostic output into Eclipse logs.

Much of this information is not at all interesting to an end-user and interferes with their ability to find other error messages they are interested among the clutter.

For an example of the kinds of output we are talking about:

!ENTRY org.springframework.tooling.ls.eclipse.commons 1 0 2022-07-13 12:33:58.236
!MESSAGE buffering callback sts4.classpath.ImzevIsc spring-boot-smoke-test-websocket-tomcat false 80

!ENTRY org.springframework.tooling.ls.eclipse.commons 1 0 2022-07-13 12:33:58.236
!MESSAGE exists = true open = true => deleted = false

!ENTRY org.springframework.tooling.ls.eclipse.commons 1 0 2022-07-13 12:33:58.238
!MESSAGE classpath=89 entries

!ENTRY org.springframework.tooling.ls.eclipse.commons 1 0 2022-07-13 12:33:58.239
!MESSAGE buffering callback sts4.classpath.ImzevIsc spring-boot-smoke-test-websocket-undertow false 89

!ENTRY org.springframework.tooling.ls.eclipse.commons 1 0 2022-07-13 12:33:58.240
!MESSAGE exists = true open = true => deleted = false

!ENTRY org.springframework.tooling.ls.eclipse.commons 1 0 2022-07-13 12:33:58.241
!MESSAGE classpath=68 entries

Suggested strategies for resolving this issue... a combination of:

• remove some messages completely (e.g. exists = true open = true => deleted = false) what does that even tell us, even I do not remember what that is there for.
• most of what remains should be demoted from 'info' to 'debug' level and somehow subject to a preference (so it doesn't show by default).
• if any 'info' messages remain they should be things that only happen very rarely (classpath events as shown in above example logs are not one of those 'rare events' because they scale up with the number of projects in a workspace).

[kdvolder]

Cleaned this up in the above commit. The messages in question are coming from the 'Eclipse native' replacement of jdt-ls extension. I've made it so most of the messages are now disabled unless a system property -Dorg.springframework.tooling.ls.eclipse.commons.DEBUG=true is set on the Eclipse process.

The only messages that will be visibly logged now are related to actual exceptions so likely to be indicative of real issues.

[martinlippert]

Closing this here. Additional cleanup work for Error Log view entries should be tracked in a separate issue.