STS on Eclipse quick-fix for unknown property in application.properties doesn't work

[Lucas3oo]

Describe the bug
STS on Eclipse quick-fix for unknown property in application.properties doesn't work

To Reproduce
create a new custom property (like hello.world=17) in application.properties and do cmd-1 over it.
Then just a "bell" sounds.

Content assist works on "standard" Spring boot properties like server.port.
Command click on a property also works in that you jump to its definition.

Mac OS,
Version: 2022-03 (4.23.0)
Build id: 20220310-1457
adoptopenjdk-11.jdk
VMware, Inc. SpringSource Tool Suite (Core) 4.14.0.202203131529 org.springsource.ide.eclipse.commons.core

% jps
34962 BootLanguageServerBootApp
35252 Jps
29787 GradleDaemon
31851 GradleDaemon
34956 Eclipse

I checked the Eclipse error log and also the enabled the Spring boots language server log. But noting in those.

I tried an older version of STS and same but it use to work on my box but probably an older version of Eclipse.

[martinlippert]

It looks to me like the problem marker doesn't appear on the first character of the missing property. When you hit Cmd-1 while the cursor is on the first character of that line, the "bell" sound appear due to no warning or quick fix being around. When I change the cursor to the second or third. character of the line, Cmd-1 works fine.

Do you experience the same behavior?

[Lucas3oo]

Hi

No it is a bell regardless on position for me. But there isn't any warnings for the unknown properties. Sorry I didn't relize that until now that it should be. I just know that they are unknown since I haven't defined them in the additional-spring-configutation-metadata.json.

So my issue might be that STS isn't validating the file then?
I selected the file and picked Validate from the context meny on the file in the explorer but it didn't reported any errors.

[Lucas3oo]

Hi

I create a new vanilla STS project in Eclipse using the wizard and then it works. So I am not sure why my other project isn't validated for unknown properties by the Language server.

It has the "[boot]" annotation on the project and all. And the icon on the file is the leaf etc.

I notice the new project I created didn't have the "Spring boot validations builder" enable or even present in the list of Validators on the project. But my old not working project have it.

[Lucas3oo]

snippet of application.properties:
hello.world=4711

The language server log when it doesn't work:

[t=1648491330485] LSP4E to org.eclipse.languageserver.languages.springboot:
{"jsonrpc":"2.0","id":"4","error":{"code":-32603,"message":"Internal error.","data":"java.lang.RuntimeException: java.lang.reflect.InvocationTargetException\n\tat org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$null$0(GenericEndpoint.java:67)\n\tat org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.request(GenericEndpoint.java:120)\n\tat org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleRequest(RemoteEndpoint.java:261)\n\tat org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:190)\n\tat org.eclipse.lsp4e.LanguageServerWrapper.lambda$4(LanguageServerWrapper.java:260)\n\tat org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:194)\n\tat org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:94)\n\tat org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:113)\n\tat java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)\n\tat java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)\n\tat java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat java.base/java.lang.Thread.run(Thread.java:829)\nCaused by: java.lang.reflect.InvocationTargetException\n\tat jdk.internal.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)\n\tat java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\tat java.base/java.lang.reflect.Method.invoke(Method.java:566)\n\tat org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$null$0(GenericEndpoint.java:65)\n\t... 12 more\nCaused by: java.lang.UnsupportedOperationException\n\tat org.eclipse.lsp4j.services.LanguageClient.createProgress(LanguageClient.java:149)\n\t... 16 more\n"}}

{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///Users/lpersson/src/c360/c360-admin/external-api/src/test/resources/application.properties","diagnostics":[{"range":{"start":{"line":0,"character":0},"end":{"line":0,"character":11}},"severity":2,"code":"PROP_UNKNOWN_PROPERTY","source":"vscode-spring-boot","message":"\u0027hello.world\u0027 is an unknown property."}]}}

[t=1648491330877] org.eclipse.languageserver.languages.springboot to LSP4E:
{"jsonrpc":"2.0","id":"4","result":"done"}

[t=1648491330879] LSP4E to org.eclipse.languageserver.languages.springboot:
Content-Length: 193

[t=1648491330879] LSP4E to org.eclipse.languageserver.languages.springboot:
{"jsonrpc":"2.0","id":"5","method":"textDocument/codeLens","params":{"textDocument":{"uri":"file:///Users/lpersson/src/c360/c360-admin/external-api/src/test/resources/application.properties"}}}

[t=1648491330879] org.eclipse.languageserver.languages.springboot to LSP4E:
{"jsonrpc":"2.0","id":"5","result":[]}

log from when it works:

[t=1648491121099] org.eclipse.languageserver.languages.springboot to LSP4E:
{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///Users/lpersson/src/workspace-2021-12/spring-cloud-sample-2/src/main/resources/application.properties","diagnostics":[{"range":{"start":{"line":1,"character":0},"end":{"line":1,"character":11}},"severity":2,"code":"PROP_UNKNOWN_PROPERTY","source":"vscode-spring-boot","message":"\u0027hello.world\u0027 is an unknown property."}]}}

[t=1648491121355] org.eclipse.languageserver.languages.springboot to LSP4E:
{"jsonrpc":"2.0","id":"3","result":"done"}

[t=1648491121357] LSP4E to org.eclipse.languageserver.languages.springboot:
Content-Length: 204

[t=1648491121357] LSP4E to org.eclipse.languageserver.languages.springboot:
{"jsonrpc":"2.0","id":"5","method":"textDocument/codeLens","params":{"textDocument":{"uri":"file:///Users/lpersson/src/workspace-2021-12/spring-cloud-sample-2/src/main/resources/application.properties"}}}

[t=1648491121357] org.eclipse.languageserver.languages.springboot to LSP4E:
{"jsonrpc":"2.0","id":"5","result":[]}

[martinlippert]

I notice the new project I created didn't have the "Spring boot validations builder" enable or even present in the list of Validators on the project. But my old not working project have it.

That is an interesting observation, great find. Do you have a simple sample project that you could share that we could import into a running Eclipse as existing project (so including the .project files etc.) and would reproduce this behavior?

[kdvolder]

The "spring boot validations builder" I think refers an old Ecipse only implementation of some validations. I don't think it has anything to do with the 'unknown property' quickfix or validation because that is done by the language server.

It's interesting, in the logs you pasted it seems that the language server is aware there is a 'unknown property' problem and sends that info to the client. So I am not really sure what is wrong with that.

I'll try to reproduce the issue myself when I have some time.

If you can attach a sample project that might be helpful, otherwise I will try to create a pretty vanilla sample project myself.

[Lucas3oo]

Hello

I think they way to re-create it is to have a multi project in Gradle that is imported to Eclipse.
If you navigate to one of the application.properties from the sub-project in Eclipse and open the file then the validator will not show unknown property. But if you start from the parent/root project which is also a project in Eclipse (but generally not a Java project) then when you open the file from that context then the file is validated. (note that depending on the config in Eclipse for Gradle the sub-project's folder isn't visible in the root projects file tree)

[kdvolder]

@Lucas3oo The bit about multi-project is a great piece of information. That gives me something to work with. It sounds like Eclispe or lsp4e are getting confused by the fact that the same physical file, exists in multiple 'incarnations' as an Eclipse resource.

[kdvolder]

I was able to reproduce a similar behavior as @Lucas3oo describes... except it does the exact opposite.

• in the subproject, the warning marker shows
• when accessing the same resource via the parent project which is not configured as a Java project, then the marker does not show.

Yes, this is odd and confusing, but it seems to also be the 'correct' or 'expected' behavior: application.properties validation requires classpath information, which is only available in the context of a Java project. So if you access it in the context of the 'non-java' root project then its somewhat expected you don't get the Java-classpath-dependent functionality.

Now... two thoughts here:

• I did not do this via a gradle project. I just create the nested project setup directly since I figured this was what really matters. I could try the gradle project but I don't have a good sample for that and don't really know how to create one, so it would be nice if you attached such a project as I requested before.

• what I am seeing is similar, but kind of the opposite of what you described (the cases where it works/doesn't are 'flipped'). So either there is something more going on that I have not yet reproduced... or maybe you accidentally described the opposite of what actually happens. Can you check what you said and confirm?

BTW: the 'flipped' cases is important since what I'm seeing is 'somewhat logical' but what you describe is more or less the opposite of what you'd expect.

In either case it might be useful if I dig a little deeper and see if we can improve on this somehow (e.g. maybe the validation and other functionality could be made to work in both cases when a resource is 'aliased'). Before I do that however, I want to be sure the problem I've reproduced actually matches what you observed (which is unclear since it seems to be the 'opposite').

[Lucas3oo]

Hello

i will fix a Gradle/eclipse combo.
thanks
Lucas

[kdvolder]

Hi @Lucas3oo

i will fix a Gradle/eclipse combo.

That would be great, thanks! But please read and answer this other question/point first:

what I am seeing is similar, but kind of the opposite of what you described (the cases where it works/doesn't are 'flipped')

I.e. can you confirm that what you are seeing is indeed the 'opposite' of what I'm seeing/describing?

The reason why I am trying to ask for this explicitly is that:

• I am sort of hoping you are actually seeing the same thing, and just accidentally flipped the "works/not works" cases in your description of the problem.
• If you are seeing the same thing (not the 'opposite'), then I don't actually need another sample (because I already have one that reproduces that behavior) and so that can save you the work of putting together a sample.

[Lucas3oo]

Hi

Indeed the warnings are on the root project which is not a java project.

I did create a multi project with a Spring app using the Spring init wizard and then of course everything worked as it should.

So I took my real project that has the issue and slimmed it down. I will attach that.

[Lucas3oo]

sts_issu22.zip

[Lucas3oo]

[Lucas3oo]

another strange thing maybe unrelated but in my other Eclipse workspace where I have a big multiproject then Eclipse sometimes ends up in recurring build that takes 100% CPU. And if I uninstall the STS plugin it never happens.

[martinlippert]

another strange thing maybe unrelated but in my other Eclipse workspace where I have a big multiproject then Eclipse sometimes ends up in recurring build that takes 100% CPU. And if I uninstall the STS plugin it never happens.

@Lucas3oo Please raise a separate issue for this.

[kdvolder]

Now that our MR with lsp4e had some time to 'percolate' through Eclipse and STS releases, I have confirimed that this problem seems to be indeed fixed in STS 4.15.0.RELEASE