Portability is a difficult Thing. We will not get a truely portable solution as Java EE also is not as Long as we have a portable configuration Definition for administrative resources as well, which Oracle (UNTIL NOW) actively fights against. So a common API unifying approaches in SE and EE for me brings what we can do as of now. Talking about a minimal API but including the source based Approach for me doent match. This does not mean we cannot provide some Default functionality: E.g. if we have Configuration as the main delegate API, we can simply define that by Default configuration is built up using: - env props - System props - properties read from the CP, e.g. javaconfiguration.properties - properties read from a file/Directory.
This "Default" mechanism is enough in most cases. And exchanging it with a property source based one (or whatever) is trivial. Additionally non constraining users may also be good for the Overall ecosystem since it gives space to the community to think on how configuration can be organized. I also have alternate, e.g. event-driven ideas, so property sources must not be everything and I actually dont want them to see as pafrt of the API, but a propertysources module (BTW: I am currentl exactly experimenting with such an Approach, will perhaps commit it this evening to the tamaya-next branch. On this branch I also factored out functionality for serviceloading and adapting configuration, using the ladder to Support type safew configuration based on modules/Adapters ;) J A 2016-07-19 22:20 GMT+02:00 Mark Struberg <[email protected]>: > > > Am 19.07.2016 um 17:45 schrieb Anatole Tresch <[email protected]>: > > > > Not providing any kind of mechanism, but > > the API also makes us less vunerable to discussions about how > configuration > > should be organized, which ultimately is the main issue, why > standardizing > > it is so difficult. So from a political perspective it may be an > advantage > > NOT to define the mechanisms behind, but only provide the main mechanism > to > > access it, the API. > > I see the point, but I fear it falls a bit too short. > Think about JSR-330 (atinject). It only provides the ‚consumer‘ API. > Is it usable? No, it _always_ needs another spec to be usable. Be it CDI, > Guice or Spring. > It is *absolutely* impossible to provide a portable solution based on > atinject alone. > It is just the least common denominator of a few frameworks. > > Do we like to do that? > If so, how does a user build it’s applications in a *portable* way? > Without any SPI or very simple default ways to configure your app this is > imo impossible. > That’s the reason why I really would love to see the SPI as part of such a > spec. > > LieGrue, > strub > > -- *Anatole Tresch* PPMC Member Apache Tamaya JCP Star Spec Lead *Switzerland, Europe Zurich, GMT+1* *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * *Twitter: @atsticks, @tamayaconf*
