Ok Maybe read too much mails in batch ;) Le 28 déc. 2014 09:57, "Anatole Tresch" <[email protected]> a écrit :
> Hi Romain > I think we are not fighting anymore. Currently I see an open discussion on > the heart of the overall config modularity topic. > > Cheers > Anatole > > Ps: will join later again, now first a ice hockey match with my boys... ;) > Romain Manni-Bucau <[email protected]> schrieb am So., 28. Dez. 2014 > um 09:54: > >> Well more I read more I think there is a real need but we are all wrong >> so instead of fighting please help us finding a solution. >> >> @Mark: priorities or ordinal are great while you completely own the app >> and its config + it is a single technical version. I guess you know it is >> not always (rarely?) The case in medium and big projects. >> >> A sample can be: v1 you configure an url with host, port propertkes and >> in v2 it is directly the url cause you added a path. Can be the same for >> datasource and business config etc... >> >> What I did in practise was to use a filter mecanism but it was an ugly >> hack. >> >> For such cases you can maybe use PropertySource translators or things >> like that to ensure the config is in the right format and then merge with >> ordinal. >> >> Now let take the case where you package together several sub apps coming >> with their config. How do you do? Some config can conflict and the >> selection is not ordinal based - let me guess it will be the same. Best is >> to have both property sources and merge them into a single one. Kind of >> Properties merge(Properties current, PropertySource next). >> >> I am not happy with these solutions but the needs are here and not >> something thought but really met - even if I dont have your experiences. >> >> Point is we cant assume config will be perfect so let our future users >> make errors and be able to fix it easily. >> >> Le 27 déc. 2014 14:50, "Mark Struberg" <[email protected]> a écrit : >> >> >> > >> > 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 >> > > >> > > >> >
