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

The '$' character in the application.properties parameter name is forcibly deleted #23238

Closed
octoape opened this issue Sep 10, 2020 · 7 comments
Labels
for: external-project For an external project and not something we can fix

Comments

@octoape
Copy link

octoape commented Sep 10, 2020

Problem

I'll do it again application.properties Is configured in spring.datasource.hikari.data-source-properties.v$session.program=myapp, but the final property key is vsession.program.

spring.datasource.hikari.data-source-properties is a java.util.Properties, v$session.program As a property key is completely legal, so I think it is a bug.

Finally, I use the following configuration to get the correct property key

spring.datasource.hikari.data-source-properties[v$session.program]=myapp

But only problem is that the spring boot language server prompts an error as follows

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
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Sep 10, 2020
@wilkinsona
Copy link
Member

Thanks for the report. The need to wrap the key in square brackets ([]) to preserve unusual characters is documented here. The language server is managed as a separate project. Please raise a new issue with the STS team so that they can take a look.

@kdvolder
Copy link
Member

kdvolder commented Sep 15, 2020

@wilkinsona

The need to wrap the key in square brackets ([]) to preserve unusual characters is documented here.

Please clarify that. The report was raised for version 2.2.8 of spring boot and indeed it seems that requires the '[..]' to escape. However spring boot 2.3.3 are the docs you actually linked to and from my experiments at least, it doesn't seem like there is a need to escape in this particular example.

The doc also seems to be talking about maps in yaml not .properties file which I think follow a different set of rules. So this is all leaving me a little confused.

@wilkinsona
Copy link
Member

Escaping should be required in 2.3.3 and my own experimentation shows that's the case:

package com.example.demo;

import java.util.Properties;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.boot.context.properties.EnableConfigurationProperties;

@SpringBootApplication
@EnableConfigurationProperties(ExampleProperties.class)
public class Gh23238Application {

	public static void main(String[] args) {
		Properties properties = SpringApplication.run(Gh23238Application.class, args)
				.getBean(ExampleProperties.class).getProperties();
		System.out.println(properties);
	}

}

@ConfigurationProperties("example")
class ExampleProperties {
	
	private final Properties properties = new Properties();

	public Properties getProperties() {
		return properties;
	}

}
example.properties.alpha$bravo=one
example.properties.[charlie$delta]=two
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.3.3.RELEASE)

2020-09-16 09:03:17.652  INFO 12487 --- [           main] com.example.demo.Gh23238Application      : Starting Gh23238Application on wilkinsona-a01.vmware.com with PID 12487 (/Users/awilkinson/dev/workspaces/spring-projects/spring-boot/2.3.x/gh-23238/target/classes started by awilkinson in /Users/awilkinson/dev/workspaces/spring-projects/spring-boot/2.3.x/gh-23238)
2020-09-16 09:03:17.654  INFO 12487 --- [           main] com.example.demo.Gh23238Application      : No active profile set, falling back to default profiles: default
2020-09-16 09:03:18.007  INFO 12487 --- [           main] com.example.demo.Gh23238Application      : Started Gh23238Application in 0.583 seconds (JVM running for 0.859)
{alphabravo=one, charlie$delta=two}

Note that alpha$bravo has lost the $ and [charlie$delta] has not.

The doc also seems to be talking about maps in yaml not .properties file

That section of the docs isn't specific to YAML and the small snippet of YAML is only an example. The only YAML-specific part in that section is in the tip that notes the need to use quotes:

For YAML files, the brackets need to be surrounded by quotes for the keys to be parsed properly.

@kdvolder
Copy link
Member

Thanks for the clarification. I cannot reproduce the example from yesterday anymore. So not sure what happened. Anyway, I guess the safe thing to do would be to always use '[..]' since that seems to work most reliably even if there might be some odd cases where it works without, this is not something to be relied on.

I would suggest a few possible improvements to the docs:

  • making the docs more clear/explicit about the differences or non-differences between .properties and .yml treatment, one possible way to do that is adding a explicit .properties example. (The fact that there is a info box specific to yaml already hints that their treatment is different somehow. You are right the words themselves when read carefully don't say they are different, but that is not the same as explicitly saying that in most respects they are the same.

  • explaining what happens to '.' characters. Do these need to be escaped? (My experiments suggest they do not, yet the wording suggests they do because they are neither alphanumeric or -. Is this another case were we should escape the '.' to be safe?

  • explaining the treatment of yaml nesting levels (I think they implicitly are translated into . characters rather than being treated in the way one would probably expect.

@wilkinsona
Copy link
Member

making the docs more clear/explicit about the differences or non-differences between .properties and .yml treatment

This is already largely covered in the section on using YAML instead of properties. Elsewhere, and as done here, we call out additional differences where relevant. In the interests of not making the documentation overly verbose, I think this strikes a good balance. I'm not keen on explicitly stating that there are no other differences everywhere. We would have to do it consistently to avoid causing confusion and doing so would add significantly to the length of the documentation.

explaining what happens to '.' characters

Yep, this needs to be clarified. Escaping them does no harm but it also isn't (always) necessary. I've opened #23390.

explaining the treatment of yaml nesting levels

Hopefully this is already covered in the section on using YAML instead of properties.

@kdvolder
Copy link
Member

Hopefully this is already covered in the section on using YAML instead of properties.

Yes, agreed. Thanks for pointing that out.

@wilkinsona Of course you have the final say on which of my suggestions you consider useful to act on (that should go without saying, but I'm saying it anyway to be clear).

I think this strikes a good balance.

I agree. The docs are pretty good really. But, even if you don't want to change any of the explanation... I still would like to see an extra example of a .properties equivalent to the yml example that is already there. Just seeing that example there would have probably avoided some confusion to me personally (i.e avoided my lazy brain from jumping to the wrong conclusion that the section is only about yml).

@wilkinsona
Copy link
Member

I still would like to see an extra example of a .properties equivalent to the yml example that is already there

We'd like to do that across the board. I've opened #23515.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: external-project For an external project and not something we can fix
Projects
None yet
Development

No branches or pull requests

4 participants