If you dont manage see them at all for merging (or their key-value pairs if not them directly) then you cant merge correctly. I saw it several times and finally bypassed something very close to DS - enough time to care about it.
Issue is: if system is too complex or doesnt solve it then Properties (or more exactly Map<String, String>) is clearly more efficient: no abstraction, can be changed easily when aggregating apps etc... Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-28 12:47 GMT+01:00 Mark Struberg <[email protected]>: >> I m fully ok to remove PropertySource from the API > > I think we've lost each other. > > Tamaya PropertySource == DeltaSpike ConfigSource basically. > You just cannot remove this without ditching the whole project. > > The point is that a USER never operates directly with the ConfigSources. They > are a hidden detail. IF you manually manage them in your application then you > end up with exactly your problem - you are doomed and cannot simply enhance > your system but you really need to rework all the applications. > > If you just say ConfigResolver#getPropertyValue("mykey") and rely on the > ordinal mechanism then you can just add such a FilteringConfigSource as JAR > without having to touch any of your code. If you did manage/merge/etc your > PropertySources manually then you are doomed. That's why I don't like that > approach. > > > > LieGrue, > strub > > > > > >> On Sunday, 28 December 2014, 12:22, Romain Manni-Bucau >> <[email protected]> wrote: >> > 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 >>> >> >> > >>> >> >> > >>> >> > >>> >> > >>> >> > >>> >> >>> > >>> >>
