>IMHO there can only be one current() otherwise the name makes no sense.
>See CDI current() Get the CDI instance that provides access to the
>current container.
>
>CDI has no current("Giovanni") or current("Francis") either ;-)
Thank you Werner, that is a really good example. Didn't think about it but you
are perfectly right.
CDI has exactly ONE internal rule. And I cannot think how we could do multiple
different ones in the same ClassLoader. And I have the same problem
understanding how it should work with Configuration.
All things like environment, dbvendor, ProjectStage, tenant etc must be totally
hidden from the application. Of course it affects the values the application
sees, but the application itself doesn't need to do anything to get it.
And if there really is the need to do complicated scenarios, then just add a
delegating PropertySource as outlined by Gerhard.
LieGrue,
strub
On Saturday, 27 December 2014, 16:37, Werner Keil <[email protected]> wrote:
>
>Inline
>
>
>On Sat, Dec 27, 2014 at 4:26 PM, Mark Struberg <[email protected]> wrote:
>
>Hi Anatole!
>>
>>First of all thanks for sharing this sample. You might know your use cases
>>but others don't.
>>
>>
>>
>>
>>I assume that all this PropertySource construction is done at a single point,
>>e.g. a producer metho
>>
>>Let me ask a few questions:
>>
>>1.) How do you know which ConfigSources exist in the project? You might be
>>one jar in a dozen ones, having no control over them?
>>
>>2.) In DeltaSpike each property file could define it's own ordinal with a
>>simple entry in the property file. That way you can just add a JAR which
>>overrides a default config from another jar. Would each of them get an own
>>name? Or do they all share the same name and priority?
>>
>>3.) How do you deal with modularity? E.g. adding a dependency which needs
>>some other ConfigSource but knows nothing about your code?
>>
>>4.) Another modularity question: What about having multiple jars (different
>>independent framework parts) and each of them likes to have another
>>PropertySouceBuilder configuration?
>>
>
>
>1-4 are valid questions. While it is only about to begin and may not affect
>Java for a while, let's keep an eye on a more modular JVM, too at least from
>Java 9 onward.
>
>
>>5.) How do you allow containers and framework programmers to add
>>PropertySources which affect all the project?
>>
>>
>>6.)
>>
>>> - you can override along the classloader hierarchy (system, ear, war)
>>
>>> by adding resources to the classpath at xxx.Usually this does not work well
>>> as e.g. all the JARs in WEB-INF/lib have exactly the same 'level'. It's
>>> totally up to the ClassLoader mechanism in which order you get them. And
>>> that could change on every restart. Been there, done that - doesn't work.
>>
>>
>>7.)
>>> In code the do simply: Configuration config =
>>> Configuration.current("Stephen");
>>And what if another jar does Configuration.current("Giovanni")?
>>Imo that approach doesn't scale.
>>
>>
>>
>
>
>IMHO there can only be one current() otherwise the name makes no sense.
>See CDI current() Get the CDI instance that provides access to the
>current container.
>
>CDI has no current("Giovanni") or current("Francis") either ;-)
>
>
>Werner
>
>
