-
Notifications
You must be signed in to change notification settings - Fork 205
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
Consider if content assist can be offered for spring.config.import property keys #536
Comments
I wanted to kick this around a bit to explore how it works. I created a spring-boot 2.4.0-SNAPSHOT project using initializer. When I put
Into the Do I need a special/specific dependency or version to be able to use this? |
Hmm... strange it works with 2.4.0.M2 but not with 2.4.0.SNAPSHOT. I guess this must be some maven caching issue. |
This seems somewhat similar to the E.g. in metadata
But for the import property I find instead something like this:
Why is that not also typed as a Reason for asking is, STS already provides some smarts for helping user complete the
|
The new system is quite flexible and we intent to use it in Spring Cloud to support config sources such as Consul, Zookeeper and Vault. Because of that, it's not necessarily true that a location is always a
I'll have to refresh my memory on how those work, but that may indeed be a better option (/cc @snicoll) |
The problem with hint is that:
On the IDE side, I think an explicit support for the key is needed. And an explicit knowledge of the implementations as well. A next step would be that each implementation of |
@snicoll I don't understand. Maybe this isn't the same as Resource type, I can understand that much but... Why isn't it possible to just attach a new type of hint to the key
I don't understand. Please explain / clarify.
Okay, if there is no other way I can of course add a special case for this specific key to trigger 'special support'. But is this really the right answer? The real problem I have is the second part of that statement: "And an explicit knowledge of the implementations as well". I don't see how STS can have this kind of special knowledge, especially if implementation details may change in the future. |
We could do that but that special handling only works for
I was talking at the existing value hint which is what I thought you both referred to.
Yeah well that's the root of the problem, isn't it? I don't believe it would be possible for us to go full declarative for this either so the most pragmatic approach right now IMO is to have some sort of dedicated behaviour based on available |
Sure, that's a good argument. And I'll buy that. But isn't that pretty much also the case for property like 'logger.level'? Anyhow, okay. Let's just assume we handle it as special case. You are right that its not all that different if we recognise the property name directly or just look at whether it has a special hint. In some ways special-casing the property name is actually simpler.
Okay. Regardless of whether or not its flagged by a hint, or triggered by the property name itself, I still need to understand how it should behave. It sounds like you suggest that we inspect the project's classpath and that somehow should help decide the behavior? That's probably do-able. But I'll need help figuring out the exact rules like: 'if this class is on the classpath, then these kinds of completions should be provided'. Or alternatively, we just provide all these completions/support regardless of whether or not the supporting ConfigDataLoader is actually on the classpath.
I wasn't. I was talking about replacing that with something more similar to how it works for logging propery. I.e. the hint says "for this thing, make suggestions that are typical for logging configuration'. I.e. mark the property with 'this specific key would benefit from this type of special support' and then we of course also would need to spell out in some detail what that actually means. And sure, we don't have to do it this way, recognizing just the key is not that different from recognizing the hint. But we do still need to concretize exactly what the special handling is supposed to do (what it does is really a different question to how it is activated). |
Maybe if the key's name is changed in a newer version of boot. But I suppose that is very unlikely. |
Not really, although it's a fine line I reckon. If you need to configure logger levels for whatever reason in your code you can inject a
My gut feeling would give that option a go. |
I've thought about this a bit more. Instead of triggering any 'special support' from the property key or from the metadata attached to it, I think instead the simplest thing is probably we trigger it from seeing a prefix/string like
Then when you invoke CA again we (editor CA engine) can notice the 'special' string 'classpath:' and that would trigger it to deliver CA similar to what you'd get if this was explicitly declared as a 'resource'. |
@philwebb @snicoll Picking this up again. I am trying to find documentation on this feature. Is the above linked blog article still the best location to read/learn about this? I tried looking in the spring-boot-reference docs but so far the only thing that I could find was a one-line entry in the appendix here: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#application-properties.core.spring.config.import What I'm looking for is some sort comprehensive description of the various supported syntaxes that are acceptable in the string bound to that property. I assume such a doc exists? I am probably just not looking in the right place so a pointer would be welcome. |
@kdvolder I'm afraid we've not written a developer guide document (beyond that original blog). Most of the details are buried in the javadoc for the code. The system is quite flexible, so I suspect we won't be able to deal with all possible location strings in the IDE. We probably can still make the common strings more useful. For the code, the there are two main classes that will be useful. The The other class to look at is We've got two important ones in Spring Boot itself. The We've also got some minimal meta-data hints that provide I'm not 100% sure what we can do the IDE, but perhaps supporting |
We have implemented some basic support for 'classpath:' prefix. Whenever we see a prefix like 'classpath:...' we'll make completions based on the contents of the project's resource source folder. I thought about other cases and thought this is probably the only case for which the IDE has enough context information to provide meaningful completions. (I.e. we know what stuff is on the classpath but we don't really know what is on the 'file:' system or the 'config:' tree because I would assume that this actually depends on where the program eventually gets run (e.g. inside k8s / docker container). We might consider implementing some kind of support for 'file' though if that seems useful (opinions welcome, either as comment in this ticket or by raising other tickets with suggestions). For now I'll just consider this item as complete with just support for 'classpath:'. |
I am closing this issue here as we implemented support for the |
Spring Boot 2.4 will ship with support that allows you to easily import additional config files. There's a bit of background about the feature in this blog post. Currently the content-assist for
spring.config.import
will be limited to the hints that we provide in the meta-data JSON file, but we might be able to go further.The
spring.config.import
key accepts a list of string location values. Locations are ultimately resolved to provide additional config data. The resolver logic is completely pluggable, but by convention a location prefix will be used to determine how the location is resolved.Out of the box, we'll have support for
configtree:
andresource:
. Theresource:
prefix will also be used as the default of no other resolver supports the string.Some examples:
It might be possible to offer some content-assist that would allow users to select files from either their workspace, or from their local disk. I suspect the workspace would be more useful.
For example:
The user types
Content assist could provide the usual hints:
It could also provide a richer "select classpath resource..." option. This could bring up a dialog similar to "Open Resource". You could also have a "select filesystem resource..." option.
Another useful feature would be ctrl-click on a location.
For example, given:
A ctrl-click on
classpath:my.properties
could open themy.properties
file.The text was updated successfully, but these errors were encountered: