management.trace.include in application.properties does not auto-complete as expected

[wilkinsona]

Using STS 3.9.2 with a Spring Boot 1.5.9.RELEASE, auto-completion of management.trace.include in application.properties does not work as I would expect.

If I type management.trace.i, wait for the single auto-completion suggestion to appear, and then press enter, the result is management.trace.include.. I expected the result to be management.trace.include=. If I correct the . to be =, I would then expect to receive suggestions for the value and for those suggestions to be based on the Include enum. The actual behaviour is that no suggestions are made.

[wilkinsona]

I just tried spring.session.store-type, another property with an enum value. It behaves as I had expected in both regards. I had wondered if it was a general problem that would affect all properties with enum values but that does not appear to be the case.

[wilkinsona]

One last attempt with spring.session.hazelcast.flush-mode. It behaves the same way as management.trace.include. A key difference here, though, is that I don't have Spring Session Hazelcast on the classpath. If I add the dependency, the auto-completion then works as expected.

This doesn't fully explain the behaviour with management.trace.include, though, as I have spring-boot-actuator on the classpath.

[kdvolder]

If the enum type isn't on the classpath STS won't know its values (or even that it is an enum). So it explains the hazelcast case. But yeah, assuming the management.trace.include's enum is on the classpath, then it should work...

[kdvolder]

Tried it. I can reproduce. Actually the management.trace.include isn't of a enum type. But is of type Set:

java.util.Set<org.springframework.boot.actuate.trace.Include>

STS considers Set as some kind of 'structured' data. So it behaves consistent with that.

We may have some special handling of java.util.List types. But Set != List either.

Not really sure what to do with this. Treat it similar to java.util.List ?

I.e. can be entered as comma-separated or like so:

my.color-set[0]=RED
my.color-set[1]=GREEN

Putting it to the test now and see how spring boot behaves :-)

[kdvolder]

Confirmed. Spring boot handles Set much like list. So I guess STS should do the same and accept 'listy values' in its place. This applies to both application.properties and application.yml.

For example, I crafted something with a 'Color' enum and when I put this:

my:
  color: RED
  color-list:
  - blue
  color-set:
  - RED
  - GREEN

Editor complains the the colorset should be 'Set' and doesn't like it if you put such values as a sequence node. (But spring boot accepts it just fine)

[spring-projects-issues]

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

Fix with regresssion tests for STS 3 .properties editor:
e65cb0c

[spring-projects-issues]

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

Similar fix applied to STS 3 .yml editor. With regression tests:

ebcc846

[spring-projects-issues]

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

I've pushed fixes for STS 4 as well. However, when I try it for real with vscode it isn't working.

I suspect its some issue around how classpath is resolved but will have to look into it more. Therefore undelivering this.

[spring-projects-issues]

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

I was wrong, problems in STS 4 language server seem to not stem from problems determining classpath, but rather from some issue with JandexIndex to find the type org.springframework.boot.actuate.trace.TraceProperties.Include. Most likely this is because that is a nested class rather than a toplevel class.

As we are planning to get rid of Jandex soon-ish I'm not sure this is something we should really be trying to fix now.

[BoykoAlex]

I think JandexIndex expects inner class like this org.springframework.boot.actuate.trace.TraceProperties$Include rather than org.springframework.boot.actuate.trace.TraceProperties.Include. Maybe that is an issue...

[spring-projects-issues]

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

I am delivering this ticket as a fix for the reported problem in STS 3 / eclipse environment.

Issue around dealing with Set is fixed in both STS 3 and STS 4 language servers, but we still have the jandex inner classes issue in STS 4 to solve. I will reate a separate ticket to solve that as its kind of a different problem and doesn't affect STS eclipse.

[spring-projects-issues]

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

Ticket for looking further into jandex issue around nested types: https://www.pivotaltracker.com/story/show/155407807