> 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.
We know pretty exactly how a truly portable solution works. The DeltaSpike solution works really well in that regard. And No, Oracle doesn’t fight against a configuration JSR if done right. Never did. There was a short period when Oracle fought against themselves and everything else went black becasue of that. But I seriously hope those times are over now. > Talking about a minimal API but including the source based Approach for me > doent match. Think about CDI or Spring without any CDI-Extensions or Spring bootstrap changes. That would have made it impossible to implement 80% of all the code that happened with those frameworks. Also I’m not quite sure if it’s a wise idea to push changes to the ASF cannonical git repo despite the fact that we are _still_ discussing things and the majority is opposed such changes. The same thing happend a year ago and it starts to happen again. Don’t get me wrong, I like to see code to play with. But if you didn’t yet get it we cannot easily get rid of branches once they are in the cannonical repo. They immediately get mirrored downstream to dozen repos. So please use github for playground activities in the future. txs and LieGrue, strub > Am 20.07.2016 um 09:36 schrieb Anatole Tresch <[email protected]>: > > 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*
