This enables us to provide configurations in the form of URLs

[yogeshnachnani]

The initial path based configurations prevented us from accessing resources that are,say, packaged within a jar
Since the underlying configuration impls accept both files and urls, this should not be a breaking change and we end up exposing similar functionality throughout

[indroneel-flipkart]

Instead of having overloaded methods, one taking a URL and the other a string, why not have the original method's implementation extended to accept URL-like capabilities. So instead of taking a decision by looking at the path suffix (e.g. .properties, .yaml, etc.). also look at the prefix to determine load path. For example a path that looks like file:/somepath/filename.yaml will be loaded from the filepath, while a path of the form classpath:/somepath/filename.yaml will be loaded using the classpath. Default behavior, without a prefix will always assume a filepath.

[yogeshnachnani]

Shouldn't it be the other way round? Take only URLs - the standard way of identifying resources. By identifying the "scheme" part of a given string, we essentially end up re-writing the logic that is contained within URL.

In fact, I kept the String path location to maintain backward compatibility.

Also, if we give something like file:/.jar!/foo.yaml ; the approach you mentioned fails. Although the scheme says "file", it is not a file in the file system but a file contained within a jar. We can possibly work around this by providing classpath:/foo.yaml. However, the former URL is the one that is provided when we do a classLoader.getResource(). Identifying a resource using the classLoader seems more straight forward and less error prone than constructing the string "classpath:/foo.yaml" and then passing it to the config provider.