Thanks Anatole!
It's probably a good idea to first work on the PropertyAdapter and Filter stuff and then come back to providing 'default implementations' which are easily extendible by our users. LieGrue, strub On Sunday, 4 January 2015, 18:01, Anatole Tresch <[email protected]> wrote: >Just a few comments from my phone: >1) I think on users side (the one that comsume config) I dont see anything >more that is needed. >2) where I still struggle is to stop core functionality provided at >propertysource level. > >eg I would expect even from a core part thst a spi user can do something like > >MyConfigSource extends AbstractPropertySource{ > >Public MyConfigSource(){ >Super(300 /** prio */, "cfg/test.properties"); >} > >} > >My higher expectation was that I also can do the same for a >PropertySourceProvider, but instead of a single resource passing a resource >pattern. > >Since in some environments I read the same format from different locations but >with different prio I wanted to enable spi writers to reuse the format impl. >so I wanted to make formats pluggable, maybe also using a builder for creating >my propertysource. (Provider). > >Nevertheless I also see the point of doing everything non trivial in modules >and see what user's find cool. So I will move the recently added stuff to a >module and add other thing I like and lets see what user feedback will be. > >Anatole > > > >Mark Struberg <[email protected]> schrieb am So., 4. Jan. 2015 um 14:33: > >That's a really good start, thanks for bringing it up. >> >>Comments inline. >> >> >> >> >> >>> On Sunday, 4 January 2015, 12:57, Anatole Tresch <[email protected]> wrote: >>> > Hi all >>> Looking at the discussions from this morning I think we need more >>> discussions >>> what core should contain. The term minimalistic obviosly is not precise >>> enough. >>> So we must agree in more detail what the features and objectives of core >>> are. So >>> I make a first try: >>> >> >>> 1. it should implement the api/spi for simple se usage. >> >>+1 >> >>> 2. it should provider enough logic to provide the minimal building blocks >>> so a >> >>> user could build a minimal config system. >> >>+1 >> >>> 3. said this I would expect that properties configs are supported ootb as a >> >>> format. >> >>+1 >>The question is how this should be done. I would just define a default >>classpath resource name (e.g. "META-INF/javaconfiguration.properties") and >>pick all those property files up as a PropertySource each. >> >>We later could easily add features similar to DeltaSpikes PropertyFileConfig >>http://deltaspike.apache.org/documentation/configuration.html#_propertyfileconfig >> or also pick them up via a ServiceLoader approach. >> >> >>> 4. I would expect that adding a propertysource is basically a one liner if >>> the >> >>> file is in the cp or a file. >> >>+0.5 >>If we do like to add this then we also need to reflect this in our API >>module. Probably a few helper classes in our spi package are enough. >> >> >> >>> 5. I would expect that core helps me defining my location declaratively. >>> users >>> dont care about resource loading details, they expect the lib to handle that >> >>> ootb. >> >>+0.5 >> >>If the java.util.ServiceLoader mechanism falls under the category >>'declarative' then that's ok. I'm -1 for requiring an own class scanning >>mechanism in our core for SE. For EE environments we might simply leverage >>CDI. We might even specify this for EE later. >> >>To sum it up: >>+0.5 for picking it up via ServiceLoader >>-1 for class scanning in SE >>+1 for fully implementing it in EE >> >> >> >>> 6. I would expect that the mechanisms provided are extendible, so with >>> adding >>> additional modules the api basically still feels the same. Given that >> >>> abstractions must be defined in the api or in core. >> >>I'd make a difference between the 'user' which just likes to get it's >>configured values (our Configuration interface) vs the programmers who >>provide own PropertySources. >>For both all necessary parts must be available in the api module. core is imo >>just a runtime impl in both cases. Remember that this will probably come from >>the container in the future. >> >> >>> 7. I dont think extension modules must rely on the api only (if that would >>> be a >>> decision we might have to discuss if the api may define more things). My >>> idea is >>> that tamaya is a combinable set of modules that as a whole can be tailored >>> to >>> the many different facets required. Constraining modules on api deps will >> >>> probably lead to much duplications, but lets see... >> >>That depends whether we think that our Extensions are 'portable' or bound to >>a specific implementation. >> >> >>> 6 and 7 are things to be argued about I think. >>> >>> If we see core as a supermonimalistic set that is not enough per se for all >>> supertrivial usage scenarios I agree I would remove latest additions to a >>> separate module. Perhaps this is even the best solution to keep our personal >>> hygiene in place ;) >> >>> >> >>> Cheers> Anatole >>> >>> - >>> Anatole Tresch >>> Glärnischweg 10 >>> 8620 Wetzikon >>> Tel +41 (43) 317 05 30 >>> - >>> Send from Mobile >>> >> > >
