Skip to content

Spring Boot Language Server processing java.util.Properties type configuration logic error #534

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
octoape opened this issue Sep 11, 2020 · 4 comments
Milestone

Comments

@octoape
Copy link

octoape commented Sep 11, 2020

Problem

Configure the property name spring.datasource.hikari.data-source-properties[v$session.program]=myappin application.properties.
But problem is that the spring boot language server prompts an error Can't use '[..]' navigation for property 'spring.datasource.hikari.data-source-properties' of type java.util.Properties.

Environment

Spring Boot: 2.2.8.RELEASE
Oracle JDK: 1.8.0_192
Eclipse: 2020-06 (4.16.0)
Spring Boot Language Server: 4.7.2.202009020949

Related issue

https://github.com/spring-projects/spring-boot/issues/23238

@kdvolder
Copy link
Member

I can reproduce this issue.

Steps:

  • create new boot project with web and actuator starter using initializer wizard
  • Add the sample code as given by @shanlaomao to application.properties file.

=> error shown on the text between [..].

This is definitely something we should fix.

However for this particular example it seems like the '[..]' notation while it is indeed 'valid' and shouldn't be flagged as an error... is actually not necessary.

I create a property class myself to test this out:

package com.example.demo;

import java.util.Properties;

import org.springframework.boot.context.properties.ConfigurationProperties;

@ConfigurationProperties("my")
public class MyProps {

	private Properties stuff = new Properties();

	public Properties getStuff() {
		return stuff;
	}

	
}

And I made my app read these properties and print them out to test how they get bound.

When I create a properties file like this:

my.stuff.v$session.program=myapp

The 'stuff' properties object gets populated with a map entry of v$session.program=myapp. So this seems like it doesn't need the [..] to escape the special characters at all (I think this because the java.util.Properties is a special case and doesn't support further navigation with .. So therefore it isn't necessary to escape these dots.

Anyhow long story short:

  • yes this is a bug and we should fix it but...
  • as a workaround I think you can simply use the notation without [..].

However, I am a little confused with comments from the other bug ticket. These suggest that using the . notation isn't working, in that example. But I don't understand why that would be the case... it seems to work fine for me with the property that I defined. Maybe there is something special about the properties in spring.datasource.hikari.data-source-properties ?

Maybe @wilkinsona can clarify.

Also I wonder if this behavior might vary on different versions of Spring Boot (I am trying this with Boot 2.4.M2 and there escaping the . seems not needed.

@kdvolder
Copy link
Member

Okay, so switching my test app to Boot 2.2.8... and indeed in that case escaping is necessary. Without escaping the key becomes vsession.program instead of v$session.program.

@martinlippert martinlippert added this to the 4.8.1.RELEASE milestone Sep 17, 2020
kdvolder added a commit that referenced this issue Sep 17, 2020
See: #534

Signed-off-by: Kris De Volder <kdevolder@pivotal.io>
@spring-projects-issues
Copy link

(comment in Pivotal Tracker added by Kris De Volder:)

Follow up ticket: https://www.pivotaltracker.com/story/show/174872660

I think we have similar issue in .yml and also the conversion from .properties to yml.

@spring-projects-issues
Copy link

(comment in Pivotal Tracker added by Nieraj Singh:)

Accepted using:

Version: 4.8.1.CI-B2455
Build Id: 202009251902

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants