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