No Anatole, I DO get it, but I really think it is a bad idea. Because it adds
way too much complexity or a very limited benefit.
Think about it in an analogy to the ExpressionLanguage ELResolver chain. Of
course this is a sorted lookup chain. And this list is fixed!
And at runtime you cannot change the order and the user also does not care!
All he cares is that #{user.name} does the right thing. He does not have to
express an 'evaluator' and the chain ordering for each and every EL invocation.
It just does not make any sense from a users perspective.
LieGrue,
strub
On Saturday, 27 December 2014, 14:17, Anatole Tresch <[email protected]> wrote:
>
>
>Hi Mark
>
>
>2014-12-27 12:56 GMT+01:00 Mark Struberg <[email protected]>:
>
>> The mechanism is clumsy and implies
>>> constraints that are already known as of now not matching all use cases.
>>
>>Tell me some limitations. Never had one. So just enlist them here and now.
>>
>And I am working since decades as well in the industry. I will not argue
>about use cases. I gave you same examples. You have the stand my opinion,
>unless you feel your opinion counts more than mine.
>
>> On top of it the priority leaks into the PropertySource API
>>
>>
>>Because it IS part of the PropertySource!
>>
>
>But it shoud not. I want to have my property sources and I want to combine
>them they way I want it. I want the concern of assembly being separated from
>the source itself.
>It is like you write a Java program like this:
>
>
>2: {
>4: }
>
>3: System.out.println();
>1: for(int i=0;i<10;i11)
>
>
>
>Shows pretty much the nonsense of your argumentation. For priorizing the
>loading of components in CDI priorities are great and sufficient, here they
>are not.
>
>
>> Finally functions is the
>>
>>> modern way of modelling such an operation.
>>
>>If you have a hammer...
>>I'm not interested in style if it doesn't add any real benefit.
>>
>>
>If the hammer is more elegant and powerful but still easy than you outstyled
>solution, let it be a hammer!
>
>>> different or
>>
>>> partial overridings (common in complex environments)
>>
>>Never came across this need and I did very complex projects. It's always a
>>trade off between an easy straight forward algorigthm which are easy to
>>understand but sometimes you have to bend em a bit or program your own
>>(PropertySource). The other option is to have hugely complex base mechanism
>>which noone can use in practice because it is 'too flexible' - means not
>>clear and straight enough.
>>
>>
>>> you will never get one solution, which a special type of
>>
>>> overridings that matches all users.
>>Oh sure we do. By having the ConfigSource define their ordinal themselves and
>>it being really easy for a programmer to add own ConfigSources we have all of
>>that!
>>
>>
>>
>>> A solution should NEVER constraint users in doing the stuff
>>> they want!*
>>
>>Having the sorting via Ordinal doesn't impose any restriction on the user.
>>Because he can easily overwrite those values.
>>We are talking about a simple straight forward config mechanism and not about
>>alien rocket science and time travelling.
>>
>>
>>>You are not on green field here!
>>
>>
>>Oh boy, we are! We just need to fulfil user needs, that's all.
>I am not a boy. I am an adult with 44 years on track.... !
>And BTW you seem to have lost every kind of reality contact. Do you really
>think companies will change their internal systems completely because just a
>few guys think they know
>how the world is rouling...? NO!
>
>>
>>> *Of course not! (despite the fact that is trivial for the ones used the
>>> functional style of Java 8).
>>Of course I know Map#merge, but what do you use it for? To me it seems like
>>an overkill.
>Seems that your mindis still stick on Java 7.,,,
>
>> You can still provide a singleton with
>>> constants, where you*
>>> *provide the most common combinations, see AggregationPolicy in my the
>>> current tree.*
>>
>>Again: I don't see the benefit. If I'm in an EAR and like to get my
>>"documentarchive.endpoint.url" then WHY would I like to manually change the
>>aggregation? Makes no sense to me. And this increases the complexity quite
>>impressively.
>>
>
>
>Perhaps one day you realize that we are talking about a general configuration
>soultion. EE is a sepcial case, not the other way round. It is NOT like
>Deltaspike, which benefits the mechanism provided by CDI. It is not and if it
>will, it gets Deltaspike 2, which is useless. There is already one, which for
>its purposes on this level, I agree, works well. But for a general solution it
>lacks so much on functionality-
>
>
>I personally really think you still do not get the difference! It drives me
>crazy.
>
>LieGrue,
>>strub
>>
>>
>>
>>
>>> On Saturday, 27 December 2014, 12:28, Anatole Tresch <[email protected]>
>>> wrote:
>>> > *See inline...*
>>>
>>> 2014-12-27 11:42 GMT+01:00 Mark Struberg <[email protected]>:
>>>
>>>> Hi!
>>>>
>>>> 1.1)
>>>>
>>>> I think we agree that having a PropertySource/ConfigSource SPI with MANY
>>>> implementations is the way to go?
>>>> Any objections?
>>>>
>>> *+1 The way to go.*
>>>
>>>
>>> 1.2)
>>>>
>>>> Where should it belong to? Is it an API or rather an SPI?
>>>> I think it's more the later. A end user just likes to get the
>>> 'final'
>>>> configured values and does NOT deal with the PropertySources himself. It
>>>> is
>>>> really just for extending the system -> SPI.
>>>>
>>> *+1 for PropertySource being an SPI. Configuration must be the API.*
>>>
>>>
>>> 1.3)
>>>> Merging.
>>>> Option (1.3.a) Do we like to do 'implicit' merging (aka the
>>> ordinal
>>>> stuff).
>>>>
>>> *It's not a question of taste. The mechanism is clumsy and implies
>>> constraints that are already known as of now not matching all use cases. On
>>> top of it the priority leaks into the PropertySoiurce API (as an additional
>>> method, which is a very ugly mix of concerns), Finally functions is the
>>> modern way of modelling such an operation.*
>>>
>>>
>>>> Option (1.3.b) Or do we like 'explicit' (the merge function). What
>>> benefit
>>>> does this add in practice?
>>>>
>>>
>>> *See above and as outlined multiple times. Adding additional functionality
>>> for audit (e.g. logging of the configuration overriding), different or
>>> partial overridings (common in complex environments). Please stop
>>> discussion on this priority thing, it's simply not enough! By the way the
>>> priority thing can still be implemented, when the rest of the design is
>>> done in a modular way. My proposed solution gave you the abtrsaction of a
>>> ConfigProvider BTW, where you could do this easily, but also the other
>>> stuff. What you do depends on the use case, and to some extent your
>>> personal taste. A solution should NEVER constraint users in doing the stuff
>>> they want!*
>>>
>>> Ad 1.3.a 'explicit' merging: This is basically the DeltaSpike mode: EACH
>>>> ConfigSource (PropertySource) has an ordinal which it can set itself. The
>>>> higher the configuration ordinal of the ConfigSource, the more important
>>>> it
>>>> is and it will override values from ConfigSources with lower ordinal.
>>>>
>>>> That way it is possible to have a kind of 'default configuration'
>>> e.g. in
>>>> a property file inside your project and later overwrite it via -Dxxx=yyy,
>>>> JNDI, or some container provided MyCountainerAdminConfigSource etc later.
>>>>
>>> *No Mark. The fact of having a default configuration does not interconnect
>>> how this is evaluated and composed. You are wrong! And on top, when I look
>>> at your ideas: you will never get one solution, which a special type of
>>> overridings that matches all users. You have to provide building blocks
>>> (one more) that helps the users (companies) to model their functionality
>>> with it. You are not on green field here!*
>>>
>>> Ad 1.3.b 'implicit' merging: Well, actually I don't got this. There
>>> was
>>>> merge(String key, PropertySource s1, s2), but that would mean that every
>>>> user needs to deal with that himself? Could you please elaborate on that
>>>> option? I didn't get it..
>>>
>>> *Of course not! (despite the fact that is trivial for the ones used the
>>> functional style of Java 8). You can still provide a singleton with
>>> constants, where you*
>>> *provide the most common combinations, see AggregationPolicy in my the
>>> current tree.*
>>>
>>> *-Anatole*
>>>
>>>
>>>>
>>>>
>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>
>>>
>>>
>>> --
>>> *Anatole Tresch*
>>> Java Engineer & Architect, JSR Spec Lead
>>> Glärnischweg 10
>>> CH - 8620 Wetzikon
>>>
>>> *Switzerland, Europe Zurich, GMT+1*
>>> *Twitter: @atsticks*
>>> *Blogs: **http://javaremarkables.blogspot.ch/
>>> <http://javaremarkables.blogspot.ch/>*
>>>
>>> *Google: atsticksMobile +41-76 344 62 79*
>>
>>>
>>
>
>
>
>
>--
>
>Anatole Tresch
>Java Engineer & Architect, JSR Spec Lead
>Glärnischweg 10
>CH - 8620 Wetzikon
>
>
>Switzerland, Europe Zurich, GMT+1
>Twitter: @atsticks
>Blogs: http://javaremarkables.blogspot.ch/
>Google: atsticks
>Mobile +41-76 344 62 79
>
>
