matteobaccan/owner

Property loaders should not load all properties but only mapped ones

Closed this issue · 9 comments

Owner seems to load all properties from a given source regardless whether these properties are mapped by appropriate interface or not.
Especially when using system properties or system environment as source, this behaviour causes a lot of head ache when trying to process the overall set of effective properties using the property traversing methods provided by Accessible interface.

Maybe, my use case is somewhat special as I need to hand over the effective properties for a given configuration to another Java process. As long as my code does not explicitly filter out unwanted properties - such as user.dir, java.vendor.name etc. - I cannot use system properties as source for mapping interface.

Please let me know if you need any further information. And mille grazie for this awesome library!

This might be somewhat related to #150.

Hi.

This is the intended behavior.
The library takes the properties you give, then on method requests it retrieves what it is requested to get: everything is resolved at method request time, including variable expansion and other things.

If you want to filter out properties, you need to load the properties by your own, retain all the properties you need before passing to the library.

Well, I do not want to filter out properties but I have to ;-) Even worse, I do not know which properties I have to filter out as users may pass any properties to the JVM. All I need, is a set of properties mapped by given configuration. Of course, I can use reflection to retrieve the set of mapped property keys and forget about the rest.... but I'm wondering if this isn't something the library should do 🤔

Maybe, it's absolutely valid to load all properties from a given source but when requesting the known properties from a given Accessible I would not expect that it also returns properties it should not care about.

Check out this example:

http://owner.aeonbits.org/docs/variables-expansion/

The only property "mapped" is "story", but all others are still used and needed.

I don't see how removing all other properties can be useful, when they can be needed at runtime to resolve others.

The only statically mapped property is "story", yes. But by inspecting the value of this property and scanning for variable expressions, it's possible to compute all effectively mapped property keys - exactly what I need. As property values might change at runtime, the overall set of mapped property keys has to be re-computed and thus can only be seen as snapshot.

Regarding your point how useful it use to remove all unmapped properties, consider a mapping interface that takes system properties or system environment as source and that consists of only two methods: foo and bar. The application uses this interface for its configuration and whenever it encounters a runtime error it writes the error along with the application configuration to the log.
The question that came to my mind is solely about user expectation: Do you expect properties such as user.dir to be contained in the output?

Maybe my use-case is somewhat special as I do not expect the properties to change at runtime. My feature request might make more (or some, at least) sense when another feature, namely sealing of properties, is introduced and active.

Hi.

I don't see any advantage in filtering out properties that might not be used (or might be). If you need that, you should filter them out before giving it to the library.

I'm not going to implement this for these reasons:

  • I fail to see this as an improvement, and I see a lot of downsides, like understanding what is used and what is not at load time, given also the fact that in runtime that could and possibly will change.
  • I am not actively developing new features due to lack of time, and this feature (admitted that I can be convinced of its usefulness) would be very low priority.

Thanks for your feedback.

That's absolutely reasonable. I can use reflection to collect the information that I need. Just wanted to track it here in case others stumble across this.

Thanks for this great library!

sure; no problem.

thanks for the nice words.