Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

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

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

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

No branches or pull requests

4 participants