Support arbitrary sources for loading properties from

[pgaschuetz]

Hi,

in reference to #14

I would like to propose the attached pull request to support loading properties from arbitrary sources.
In detail, the pull request:

• changed all internal occurrences of java.net.URL to java.net.URI
• refactored some logic from org.aeonbits.owner.loaders.Loader into a new AbstractFileBasedLoader
• Introduced AbstractNamedCustomLoader, which can be easily extended to support pretty much any source of configurations

see CustomNamedLoaderTest for a demonstration

There is definitely room for improvement, especially HotReloading is not implemented yet, but this should be relatively trivial by moving the WatchableFile logic into Loader

Apart from some minor internal API changes, this pull request should not change any existing functionality. All tests run fine.

Please let me know what you think.

[lviggiano]

I'll review this asap in detail.
Thanks.

[lviggiano]

While I find interesting to use URI in place of URL, I am not fully convinced by the rest. I'll learn more from your branch as soon as I can (very busy recently with work and life, so sorry in advance for the delay).

At first sight, using URI in place of URL is good since it allows to have user-defined specifications to identify resources, without the need to configure a URLStreamHandler (java is not very flexible in that). Loaders are in charge of accepting URI, but they can possibly be responsible to access acceptable URIs returning the InputStream (task, that at the moment is done via ConfigUR*Factory and normally it would require an URLStreamHandler). But it looks like the problem is more complex than that: Loaders were initially thought for file formats, while the "protocol" is independent from that and may require something like a ProtocolHandler.

Your code contains interesting ideas. I need more time to study it in deep and to fully understand it. I admit I didn't consider to use URI in place of URL on the first place for my ignorance on the topic.

[pgaschuetz]

Thanks for your reply!
As I said, there's definetly a lot of room for improvement and the main idea was to get it working in the first place and keep the number of changes to a minimum.

[lviggiano]

Thanks to you. I'll get back to this asap with more thoughts. Maybe we can abstract the logic on how to do some things on URIs, with an interface like:

// this is just a draft of an idea
interface ProtocolHandler {
    // returns a long identifying last modified time; useful for hot reload
    long lastModified(URI uri);

    // returns the content of the uri
    InputStream openStream(URI uri);

    // eventually
    boolean accept(URI uri);
}

// then

ConfigFactory.registerProtocolHandler(new JDBCProtocolHandler(...));

just a thought.

So loader can still work on file types, while protocol handler can be used to access different resource locations.

[pgaschuetz]

• lastModified definitely makes sense

For the others, I'm not too sure, whether I understand this correctly.

• The idea of having a "custom loader" also specify a defaultSpecFor() was that Config classes without @ Sources could be easily distinguished when loading:

interface foo.bar.SimpleConfig implements Config {
  ...
}

// inside ie. CustomJdbcLoader
SQL = "SELECT key,value FROM config WHERE identifier = " + getFragment()
// where getFragment() would return "foo.bar.SimpleConfig"

• openStream would probably not work with ie. a JDBC datasource, unless one would serialize a properties file into a single column

My initial idea was that owner should not care, where its datasources are located and how they are to be read

[lviggiano]

A little update.

Commit 156a8b2 is basically a cherry pick of the URL->URI substition.

I'll probably split the Loader class in two parts:

• a protocol handler, to handle specific (and custom) protocols
• a parser, to handle data interpretation and transformation to java.util.Properties from different sources
  resolved by the protocols