Provide a plaintext/data ProtocolResolver by default and register it in the default ResourceLoader.
More and more applications are deployed as containerized apps so they benefit greatly from a simplified configuration deployment process. Especially applications that are configured via spring-boot-cloud-config could be improved with inline file configuration/ Resource support, all would be configured in a single file/"place".
https://github.com/yidongnan/grpc-spring-boot-starter/issues/325
In that issue a user requested an additional string property for a Resource property because the cloud config only supports simple properties and file Resources require an additional s3: setup.
I suggested adding a custom ProtocolResolver but due to the early initialization of the configuration process there seem to be issues with the registration.
It's not the first time I have been requested to implement that.
It doesn't matter for me whether a plaintext or data (or both) ProtocolResolver is added as long as there is a native way of configuring an inline file.
An example implementation for a data-URI Protocolresolver can be found here in the examples.
Corresponding "implementation" for plaintext can be found here
Feel free to copy/use these dummy implementation as a reference implementaiton.
I'm not sure whether this is the right place to open the issue, maybe this belongs more to spring-boot (cloud (config)), but based on the required code size and the general usefulness I decided to request the feature here.
Alternatives considered
- Extend the documentation of ´ProtocolResolver
](https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/core/io/ProtocolResolver.html) / [ResourceLoader` with information how to register them "as early as possible". - Load the default/additional ´ProtocolResolver
using java'sServiceLoader` at least if they don't require any additional parameters.
Comment From: snicoll
Unfortunately, this doesn't belong to the core framework that's providing the core pieces for others to build upon. I wonder if that's not been largely duplicating by the new import mechanism in Spring Boot. If you feel this is still necessary, please report that against Spring Boot.