exactly so we have 2 choices as I mentionned: 1- fail - my preffered solution ATM knowing it will never happen with other hard side effects IMO 2- add a sorter to get a clean API for such an issue if we consider it important
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-28 12:56 GMT+01:00 Mark Struberg <[email protected]>: > Romain, usually PropertySources should have different ordinals. The trick > with the fqn Classname and the property source name is just to at least get a > reproducible result during server restarts. If they change the package name > then it's their fault. > > PropertySources with the same ordinal are also only an issue if they contain > the SAME config keys!. > > LieGrue, > strub > > > > > >> On Wednesday, 28 January 2015, 11:57, Romain Manni-Bucau >> <[email protected]> wrote: >> > inline ;) >> >> >> 2015-01-28 11:46 GMT+01:00 Tresch, Anatole >> <[email protected]>: >>> Well, for me it is questionable if we need this: >>> >>> 1) I don’t see much advantages adding another abstraction for that >>> 2) we HAVE a well defined order currently based on prio and class name, so >> there are no conflicts! >>> >> >> class name (worse when using fqn vs simple name) is not something you >> can bet on, too fragile + you can get multiple JsonPropertySource with >> the same ordinal and same values for instance. You'd need to use >> idendityhashCode to be deterministic then. >> >>> BTW throwing exception in a EE environment can have disastrous >> consequences, so it is not always a good idea to just throw an >> exception...especially since it may result on some assembly htat might be >> out of >> control of a developer or operator. So I would suggest writing w warning is >> the >> better way to handle it. >>> >> >> In EE I don't expect to use it "like it" but in a CDI extension at >> minimum so not a big deal, will hopefully make the deployment fail. >> >> >>> Cheers, >>> Anatole >>> >>> >>> >>> -----Original Message----- >>> From: Romain Manni-Bucau [mailto:[email protected]] >>> Sent: Mittwoch, 28. Januar 2015 10:23 >>> To: [email protected]; Mark Struberg >>> Subject: Re: Multiple PropertySources with the same ordinal >>> >>> Why don't we just introduce a sorter API? Then ordinal would be @Order >>> and used as default only. This would allow us to fail when there is a >>> conflict since it is solvable on user side and shouldn't happen >>> anyway. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-01-28 10:08 GMT+01:00 Mark Struberg <[email protected]>: >>>>> Did you read the Javadocs? It is clearly written that we sort >>>>> 1) by ordinal >>>>> 2) by fully qualified class name. >>>> >>>> Side note as I'm atm busy with a $$dayjob issue. We might >> additionally need to sort via the PropertySource name. That would be >> important >> if you have 2 PropertyFilePropertySource instances with different URLs. They >> should get a well defined sorting as well. >>>> >>>> >>>> After that there really should be no == in the sorting anymore, right? >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>> >>>>> On Tuesday, 27 January 2015, 21:26, Anatole Tresch >> <[email protected]> wrote: >>>>> > -1 for failing. >>>>> >>>>> Did you read the Javadocs? It is clearly written that we sort >>>>> 1) by ordinal >>>>> 2) by fully qualified class name. >>>>> >>>>> So there is an order that even is not dependend on classloaders. >>>>> >>>>> >>>>> >>>>> 2015-01-27 19:52 GMT+01:00 Oliver B. Fischer >> <[email protected]>: >>>>> >>>>>> Hi, >>>>>> >>>>>> I am just writing some unit tests. One of them adds multiple >> property >>>>>> sources with the same key and the same ordinal. As we can not >> decide >>>>>> which one is the right one we should throw an exception. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Oliver >>>>>> >>>>>> -- >>>>>> N Oliver B. Fischer >>>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany >>>>>> P +49 30 44793251 >>>>>> M +49 178 7903538 >>>>>> E [email protected] >>>>>> S oliver.b.fischer >>>>>> J [email protected] >>>>>> X http://xing.to/obf >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *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* >>>>> >>
