Would have been the same since the app is PropertySource aware. Can also mean we dont have PropertySource in a default impl and then it is true it is easy. I m fully ok to remove PropertySource from the API and make it an impl detail. Le 28 déc. 2014 11:59, "Mark Struberg" <[email protected]> a écrit :
> But if you would have had this container wide 'AdminConfigSource' with the > nice gui, or a installation wide DatabaesConfigSource then it would not > have been a problem, right? > > I mean you would have to add this filter to all the 100 apps in the 1 day > as well, right? So it would be the exact same effort to just add 1 > FilteringConfigSource (hacky but works) with a high priority either, right? > That would be just adding a single jar to all your lib folders... > > > Sometimes we tend to add new mechanisms out of blindness. But the problem > often can be solved easily with existing tools - we just often don't see > them. This happens to me as well, but I'm glad to have really brilliant > co-workers which often stop me from doing overly complicated crazy things. > Happens more often than I like it ;) > > > Of course sometimes we really need to add a new mechanism. But this should > only be the (almost) last resort if there is no other acceptable way. > > There are just sooo many weirdo cases out there. Of course they are often > needed in production. But for such huge installations you will barely find > 2 companies with the exact same situation... > > > > Maybe I'm alone here but my goal is to make the 90-95% 'standard' use > cases as easy as possible out of the box. And _additionally_ have an SPI > layer which is very deep down to the metal and as flexible as possible to > allow solving more complex edge cases. > > And I honestly don't care if a programmer does need to write 50 lines more > for such a seldom case. It's just impossible to solve every problem out of > the box. That would blow up Tamaya 10x times (or even more). And that would > make it unfriendly (if not even 'unusable') for the 95% standard cases... > > > LieGrue, > strub > > > > > > On Sunday, 28 December 2014, 11:41, Romain Manni-Bucau < > [email protected]> wrote: > > >T hat 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 > >> >> > > >> >> > > >> > > >> > > >> > > >> > > >
