2015-01-07 11:49 GMT+01:00 Mark Struberg <[email protected]>: >> Configuration config = ConfigurationFactory.newConfiguration(.. > > > There is a really huge no-go in this approach. This basically defeats DI. It > makes the consumer to be in charge what he gets. But configuration needs to > be extendible to adopt to other situations. > > > Consider that you did write a mycoolpdflib.jar. Years ago. And it happen to > need a mycoolpdflib.storage.location configuration property. How to do this > if you only read the single json/ini/property file you have in your > mycoolpdflib.jar? Nada, endoftheroad, endegelaende! > > Also: if you then have multiple of those Configurations in your application: > which one to pick? That's just a dead end solution! Been there, done that. > Didn't work and was always a pain and got hugely complicated over time. It > simply doesn't work. >
Not at all and not what I wrote. Default would still use current SPI but we should be free to use PropertySource we want as well (ConfigurationFactory/builder.noImlpicitLoading().withSource(...).withProvider(...)). > > >> 3) if we go one step further and install tamaya in a container > > That scenario is not a problem at all as it internally is basically a weak > Map<ClassLoader, Configuration>. > this is broken Mark and leaks even with the WeakHashMap simply cause the key is a classloader :( > We might probably end up adding another method > Configuration.currentFor(ClassLoader) or such. That could be handy in case of > shared libs in an EAR which don't like to use the TCCL but really explicitely > use configuration which is reachable form the application ClassLoader only > (to avoid picking up config from the WARs in shared ear libs). > You CAN'T rely on classloader, DS for instance prooved it but it is not the only one. Depending your envirnoment classloader can not be as unique as you think and there are enough cases to take care of it + in SE what would be the sense of it? > > There is no perfect solution right now (at least I don't know one). But the > factory approach really works far better than anything else when it comes to > plug&play, modularity and easy-of-use. > > > LieGrue, > strub > > > > >> On Wednesday, 7 January 2015, 10:29, Romain Manni-Bucau >> <[email protected]> wrote: >> > Hello guys, >> >> I'd like to discuss - again sorry - Configuration.current(). >> >> Here the reasons: >> 1) this make tamaya context/environment aware - I know these words >> means a lot so in more words I mean tamaya knows applications and when >> you'll have read 2 it knows all parts of an app >> 2) I saw quite commonly the need to start twice - or a bit more - the >> same library/part of the app. With current design we need to translate >> keys to the part we desire before using the configuration provided by >> tamaya. This implies the app knows a way to find all needed keys which >> is not always the case even if some patterns (prefixing) can work. It >> is surely close to the original need of Anatole's map function in the >> config but I wonder why we can't just have multiple config reading >> different sources? >> 3) if we go one step further and install tamaya in a container then >> the app will call the container context impelmentation which will >> delegate to the app if there is one cause the container doesnt know >> such needs. >> >> I find it over complicated where finally all we need is to get a >> Configuration reference. >> >> Here what I'd like: >> >> - SE >> >> Configuration config = ConfigurationFactory.newConfiguration(/* here >> we could optionally put few config, either properties or internal >> config file path. it would contain some manual declared sources and >> provider and could replace addpropertySource for instance */). >> >> Default implementation would be the ServiceLoader one we have ATM but >> the config passed to this factory could deactivate it and force the >> config to use mentionned sources/providers. >> >> Then if the configuration needs the config as a singleton I think it >> is simple enough to let the app do a singleton - in particular since >> in most of cases it will be as simple as "@Singleton" (CDI, Spring, >> Guice...) >> >> Last point: the configuration is built in its startup context which >> means it resolves all it needs during its own bootstrap and not at >> runtime later to avoid contextual side effects. >> >> - EE/Spring >> >> In this case it is acceptable to have an automatic configuration: >> >> @Inject Configuration config; >> >> this would be built during container boot and would just be a >> singleton for the underlying container. >> >> This still allows apps to create "SE" style config if needed. >> >> >> wdyt? >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >>
