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