inline as usual
2015-01-22 16:56 GMT+01:00 Tresch, Anatole <[email protected]>:
> Feedback inline:
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:[email protected]]
> Sent: Donnerstag, 22. Januar 2015 16:18
> To: [email protected]
> Subject: Re: PropertyQuery
>
> shouldnt prevent us to go futher but also means we make a lot of noise
> and no progress...
> -> That depends on the quality of discussion, not on the fact that we discuss
> ;). And if you say my posts are noise, well... I take that into account.
> Thanks.
>
we all tend to do it but that's hard to follow where we are and
finally 1-2 people are doing the product which is bad IMO
-> I agree. And I also trying to motivate my colluegues to participate the
discussions...
> That said here the feedbacks I try to make precise:
> -> Nice, thanks!
>
> - java 7 module:
> -- ConfigurationProvider should be called ConfigurationFactory IMO (see next)
> -> NO! NO! NO! We already discussed multiple times that this is not
> necessarily a factory.
>
> - org.apache.tamaya.spi.ServiceContext#getServices should disappear ->
> no usage at least
> -> Of course it is used. How do you think the services in core are loaded
> from? Read the code before you state things that are not true or join our
> hangouts.
>
not justified if you prefer. Said otherwise we shouldn't get a single
ServiceLoader abstraction since both needs are really different.
-> I do not agree here, but I am not sure I got your point. ServiceLoader is
not powerful enough and users may want to use a different approach. Also for
testing you might want to have a more flexible solution as well.
> -- Configuration.current() miss the "config" stage where you can
> select your impl: Configuration.byDefaultProvider() or
> Configuration.byProvider(MySuperProvider.class) and then we just call
> build() (or we can add in between addPropertySource/Converter). Doing
> it we don't need to cache
> org.apache.tamaya.spi.ServiceContextManager#serviceContextProviderDelegate
> which makes it more reliable
> -> Obviously you still in case of a factory, which it is not. It is a
> service!!!
this is broken in most of environment...just test, check you leaked,
check you don't have the config you should etc...mainly works in SE
only where this abstraction is useless
-> Just a claim. Credit Suisse runs plusminus 800 plus instances also with low
latency requirements successfully. Some are running in Weblogic, some in
Tomcat, some standalone...
Also here: your expertise is welcome, but your argument is simply not true.
> -> For me it seems you are still stuck in the commons config design somehow.
> Oliver BTW is currently trying to build an extension module, where you can
> "build" your configuration in such/similar way.
> So you can still do your own coding of everything there. We can then
> still discuss if we want to have that moved into the core/API part at a later
> stage.
>
> - org.apache.tamaya.spi.ConfigurationContext#context has no real
> meaning IMO and shouldn't be public if it is needed (it is not IMO)
> -> tbd. This could be an implementation detail, indeed (or I missed
> something).
>
> - org.apache.tamaya.spi.PropertySource#isScannable is not used ATM
> AFAIK so we should remove it IMO
> -> That is not true as well. Non scannable property source are not called for
> Configuration.getProperties().
>
ok - I should have a cache issue in Idea, sorry
-> fair enough.
> - I'd remove org.apache.tamaya.ConfigOperator and just allow to export
> a Config as a Map -> then use Map API to actually "map"
> - ConfigQuery -> same as previous comment
> -> adapt Configuration with 2 previous comments
> -> Well, JSR 310 as well as JSR 354 use this concept very successfully. I
> would definitively deny removing it. If you don’t get it talk with Stephen
> Colebourne.
> -> In many cases exporting to the full Map is not necessary.
> -> Creating of views will get implementation dependent.
> -> Summarizing: no way! IMO useless and inefficient proposal compared to what
> we have.
>
> - finally check it does worth to keep this j8 module (think only
> drawback removing it would be to loose Configuration.current() - or
> new equivalent - which is not a big deal IMO.
>
> -> Again this is not true again. There are as well the additional accessor
> using Optional, which are legit additions if someone uses Java 8.
yep which is a very poor gain IMO for a lot of complexity:
-> on our side
-> on user side (in real life you often have multiple java version so
multiple apis?)
-> fair enough. your opinion, I have another one!
> -> And to say it again once more: if you don’t want to support Java 8 as a
> first citizen, many people here on the list would probably leave the project.
>
please shout guys if that statement is true
-> yes please!
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-22 16:01 GMT+01:00 Tresch, Anatole <[email protected]>:
>> Hi Romain
>>
>>>well why I want to step back is just cause we slowly leave config
>>>field and we are implementing a storage solution.
>>
>> Do we? I am only focused on config related use cases and know about what I
>> am talking:
>> - Exposing a part of the internals as API does not make a storage solution.
>> - Using TypeLiteral for property conversion does not have anything in common
>> with a storage solution.
>>
>> -> So please stay on the topic and keep off things that are not relevant,
>> please.
>>
>>>There are already
>>>numerous projects doing it at apache - even if they can sometimes
>>>mandate some infra - so we should stick to the first goal of tamaya.
>>
>> -> Which is providing a configuration solution. I have well defined and well
>> important use cases. If you don’t have them, well...
>> -> I do not care (too much) what other projects do. Often others provide
>> good features, but also some less good ones. To argue not to repeat, what
>> others did
>> IMO is useless. We should take the good things and combine it here, so
>> we get a good solution. And again: if you have something that disturbs you,
>> be
>> explicit. Just claiming or writing down your feelings does not help
>> anybody here. Either you write down your concerns clearly, at the end by
>> code, or your input
>> is not much of use. It is that simple IMO. I am exposing me by writing
>> down and trying to do things as Java API, simply because that is the only
>> way it works to get
>> a common understanding. Sorry for the hard words here.
>>
>>> I also not fully agree with the basis - in particular the SPI to be
>>> clear - we have ATM.
>>>
>>>To sumamrize a first release with:
>>>1) SPI ("provider" + property source)
>>>2) basic merge/conflict policy
>>>3) String read API
>>>4) basic convertion support
>>>
>>>Is far enough IMO.
>>>
>>>Once all of it is clear I'd like we do a release to gather feedback
>>>then continue building on top of it - we are ATM in the tunnel ;).
>>
>> -> So we have a scope discussion for the new release now. IMO the current
>> artifacts within the API are clearly in focus for release 1 (from an API
>> perspective). If you want to remove anything, you should
>> exactly write down, WHAT should be removed and also WHY.
>> -> About Collection support, we may have a vote on it. Or other people here
>> on the mailing list should add their cents ;)
>> -> Gathering feedback is OK. Nevertheless we can mark the release as alpha,
>> so everybody is clear that things may still change.
>> -> And again discussing what should be part of release 1 IMO must not
>> constrain us to discuss on further concepts as long as the threads are
>> clearly separated and not too many. So help us constructively with the
>> discussion instead of throwing woods into our legs all the times. That
>> would be great!
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-22 13:47 GMT+01:00 Tresch, Anatole
>> <[email protected]>:
>>> Hi Romain/all
>>>
>>> I think we have quite a common agreement on the basic functions designed so
>>> far and I do not want to
>>> reinvent or change any of the basic mechanism. I simply come up with a
>>> simple request to use the algorithm pattern
>>> for a small subset of a functionality (how the final property value is
>>> evaluated). The usage of TypeLiteral was even your
>>> own proposal AFAIK, when we discussed PropertyConverters ;) ).
>>>
>>> Our current configuration model in general IMO is a very good start. It is
>>> already so flexible that I can implement 60-70% of use cases
>>> I have currently in use within Credit Suisse (this is somehow my
>>> "benchmark", which from my discussions I had during the last years covers a
>>> majority of use cases when dealing with distributed and modular systems).
>>>
>>> I am sure you remember, we had a discussion on another mail thread
>>> yesterday about Collection support. My proposal
>>> basically is the outcome of having played around to extend our API to
>>> support collections based only on Map<String,String>
>>> only as internal PropertySource representation thus avoiding the String[]
>>> getListProperty(String) methods.
>>>
>>> So for getting type information and define the content type of collections
>>> we need TypeLiterals, which similarly is useful perhaps for other non
>>> collection
>>> cases. Since collection entries can be defined in different property
>>> sources, a final list may want to contain all the properties found, instead
>>> of overriding,
>>> so values of different property sources are to be combined. AFAIK you
>>> already agreed on that UC. Hardcoding yet another strategy IMO makes
>>> no sense, so I would recommend use the default for all common aspects (that
>>> is what we already have in place) and add support for adapting the default
>>> where it is not appropriate. Thinking on this IMO both aspects
>>> (TypeLiterals and the collector) are the same for evaluating single
>>> property values as well,
>>> so regarding that it makes no sense to model collections differently, but
>>> extend/flexibilize the way how we can access properties in general.
>>>
>>> I tried to combine both aspects in one class, which I called PropertyQuery.
>>> Perhaps also the name PropertyQuery is confusing. Alternates would be
>>> PropertyRequest, PropertyAccess,... or whatever you like, I am completely
>>> open here ;)
>>>
>>> We can postpone that discussion, but just stopping this discussion now will
>>> not solve anything. Also we already invested a lot of discussing
>>> collection support, why stop here.
>>> We have enough time I think. We have important use cases to solve that may
>>> affect the Configuration interface as a whole. Adding them later may be a
>>> bad idea, so we
>>> should sort out these things now IMO.
>>>
>>> So I am curious to see your concrete (improvement) proposals ;), so we can
>>> continue to see, if we end up in a common view. If so, others on the
>>> mailing list also have a
>>> chance to join us again, I think.
>>>
>>> Anatole
>>>
>>>
>>> -----Original Message-----
>>> From: Romain Manni-Bucau [mailto:[email protected]]
>>> Sent: Donnerstag, 22. Januar 2015 09:45
>>> To: [email protected]
>>> Subject: Re: PropertyQuery
>>>
>>> not exactly, it is different to expose MapReduce in API and to
>>> implement it behind another concept, ATM it is an implementation
>>> detail.
>>>
>>> Why I worry a bit about Query stuff is we start to leave configuration
>>> layer to enter backend one, not sure it does worth it *to start* - I
>>> understand your feature even if I never needed it but I'd really like
>>> we ensure our basis are solid enough before adding features on top of
>>> them.
>>>
>>> Said otherwise I think we should now focus on trying to make a 0.1 -
>>> we can add alpha to make obvious we are not done - and stop adding
>>> anything before being fully agree on all we have.
>>>
>>> Does it make sense?
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-22 9:39 GMT+01:00 Anatole Tresch <[email protected]>:
>>>> Hi Romain
>>>>
>>>> About lamba friendly I can still have a Builder that creates a query.
>>>> Works perfectly.
>>>> The default use cases would remain as is. Queries would just add about 3
>>>> methods to Configuration. We get as well all the flexibility we would need
>>>> for collection support as well ;)
>>>>
>>>> Mapreduce? Well what else is evaluating a chain of propsources by
>>>> overridding? Its already there, but hardcoded the same, which is obviously
>>>> not flexible enough!
>>>>
>>>> -
>>>> Anatole Tresch
>>>> Glärnischweg 10
>>>> 8620 Wetzikon
>>>> Tel +41 (43) 317 05 30
>>>> -
>>>> Send from Mobile
>>>>
>>>>> Am 22.01.2015 um 09:11 schrieb Romain Manni-Bucau <[email protected]>:
>>>>>
>>>>> isnt it too complicated for most common use cases (+ not that lambda
>>>>> friendly cause of the 4 parameters which dont help writing readable
>>>>> code IMO).
>>>>>
>>>>> Functionally it works but it makes default cases "hard" and actually
>>>>> you just want to implement the MapReduce pattern so maybe we should
>>>>> call it this way if we go this way.
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2015-01-22 8:44 GMT+01:00 Anatole Tresch <[email protected]>:
>>>>>> Dear all
>>>>>>
>>>>>> *let's think about additional use cases:*
>>>>>> 1) as mentioned in my last mail about collection types,* overriding may
>>>>>> not
>>>>>> always be the right resolution policy *for accessing a configured value
>>>>>> (e.g. for collecting all configured values in a final set/list).
>>>>>> 2) sometimes I want to define my own PropertyConverters (already
>>>>>> implemented)
>>>>>> 3) sometimes I even would like to evaluate multiple keys taking the
>>>>>> result
>>>>>> of the first property key that returns a config property (nice
>>>>>> convenience)
>>>>>>
>>>>>> When we will add all this kind of aspect into Configuration, we will end
>>>>>> up
>>>>>> in a messy interface, e.g. for
>>>>>> String get(String);
>>>>>> <T> T get(String, Class<T>);
>>>>>> <T> T get(String, Class<T>, PropertyConverter);
>>>>>>
>>>>>> String get(String, ValueCollector);
>>>>>> <T> T get(String, Class<T>, ValueCollector);
>>>>>> <T> T get(String, Class<T>, PropertyConverter, ValueCollector);
>>>>>> ...
>>>>>>
>>>>>> Obviously that does not make sense.
>>>>>>
>>>>>> Instead of I would propose, we would define a PropertyQuery, which
>>>>>> basically is
>>>>>>
>>>>>> - is the same as a TypeLiteral<T> solving the type aspects
>>>>>> - has a list of *keys* to be evaluated, at least one
>>>>>> - optionally has a ValueCollector
>>>>>> - optionally has a list of PropertyConverter
>>>>>>
>>>>>> With that our interface gets much leaner, but still flexible enough to
>>>>>> accommodate the use cases above:
>>>>>>
>>>>>> String get(String);
>>>>>> <T> T get(String, Class<T>);
>>>>>> <T> T get(String, Class<T>, PropertyConverter); // may be ommitted as
>>>>>> well ?
>>>>>> <T> get(PropertyQuery<T> query);
>>>>>> ...
>>>>>>
>>>>>> This solves all use cases above and gives us an easy way to add
>>>>>> additional
>>>>>> feature, if needed (I dont see any, but who knows). Hereby ValueCollector
>>>>>> would be defined as follows:
>>>>>>
>>>>>> @FunctionalInterface
>>>>>> public interface ValueCollector {
>>>>>>
>>>>>> /**
>>>>>> * Method that is called for each value returned by a PropertySource
>>>>>> for the given key.
>>>>>> * @param currentValue the current value, including null.
>>>>>> * The collector should either combine the
>>>>>> existing
>>>>>> value with value from {@code currentValue}
>>>>>> * or replace the value in {@code currentValue}
>>>>>> with {@code valueRead}, hereby returning the
>>>>>> * result to be used as new {@code currentValue}.
>>>>>> * @param key The current key to be evaluated.
>>>>>> * @param newValue the new value read from the current {@code
>>>>>> propertySource}, not null.
>>>>>> * @param propertySource The PropertySource that returned the current
>>>>>> value (either as the result of a direct
>>>>>> * access of as a property Map containing the
>>>>>> given key. The PropertySource given
>>>>>> * may be evaluated for additional meta-data,
>>>>>> how
>>>>>> the given values are to be combined.
>>>>>> * @return the value to be used for future evaluation.
>>>>>> */
>>>>>> String collect(String key, String newValue, PropertySource
>>>>>> propertySource,
>>>>>> String currentValue);
>>>>>>
>>>>>> /**
>>>>>> * Default overriding collector.
>>>>>> */
>>>>>> public final ValueCollector DEFAULT_OVERRIDING_COLLECTOR = (k, nv, ps,
>>>>>> cv) -> nv;
>>>>>> }
>>>>>>
>>>>>> Feedback?
>>>>>>
>>>>>> Cheers,
>>>>>> Anatole
