That is exactly the difference between real life and theory. You cant ask to change 100 apps in 1 day...you have to live with Le 28 déc. 2014 10:33, "Mark Struberg" <[email protected]> a écrit :
> I don't get your samples Romain. > > In v1 you have configured keys A,B,C > In v2 you have D. So what? > > Just remove A,B,C and use D instead. That's exactly the same like changing > a table structure. > > Doing some 'translation' just because the ops guys don't want to change > configuration is a total dead end and will end up being a maintenance > nightmare in v3++. Your filter mechanism is just an utter ugly hack and if > I would be the manager of this project then I'd call you names ;) > > That's like arguing that maven is not usable because it makes scripting > hard. This is a FEATURE and not a bug!. People should not script builds! If > they like to do complicated stuff then it's very easy to write plugins. In > our case it's very easy to write ConfigSources. > > > Remember the old saying "dirty remains, while quick is long forgotten" > > > > Some config can conflict > > No. That's the same like with JNDI, JMX etc. Just tell them to use their > own namespaces and you are done. > That's like saying Java is not good because if I have multiple JARs which > contain the same ClassName then it doesn't work. JUST USE NAMESPACES. You > don't need any explicit merging. > > > > Oki, that was 2 arguments and both of them are actually non-problems. > > Cmon folks, give me more use cases and examples. I'm ready to solve them ;) > > > LieGrue, > strub > > On Sunday, 28 December 2014, 9:54, Romain Manni-Bucau < > [email protected]> wrote: > >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 > >> > > >> > > > > > > > >
