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
> >
>
