Well yes and no. Default would stay the same.
Now the fact we need to open the door to custom and fully defined config is I fear no more a choice than support in application config. If we dont first extension will be a custom provider/context...then this extension will just be the main usage (all != EE/SE need it and it is the majority of apps today). Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-08 9:32 GMT+01:00 Mark Struberg <[email protected]>: > The problem I see is that users will do it in different ways. Thus the > mypdflib.jar will build a different config then theothercsvlib.jar and your > own application. They will simply fall appoart if we don't define those > single default factory. Seen this so often that it really hurts. > > LieGrue, > strub > > > > > >> On Thursday, 8 January 2015, 9:13, Romain Manni-Bucau >> <[email protected]> wrote: >> > more or less >> >> as given previously it is almost never true - do you still wrap even >> SE softs in plain manual java? You almost always have a light >> "container" - word is surely not the best but something managing your >> lifecycle. >> >> This pattern brings the integration outside the core. It is a drawback >> but a big advantage. A drawback cause you let the user doing it - but >> often it is 3 lines. An advantage cause we don't conflict with the >> app, we don't introduce any leak etc..and finally with the >> release/close method we need anyway the app will manage the lifecycle >> whatever we propose so finally we have an abstraction which doesn't >> help IMO. >> >> Also and I think I mentionned it being fully contextual prevents the >> app to control the visibility of the conf so if you think some teams >> need best practise you'll quickly see it will be used everywhere and >> that's not what you want IMO - at least I don't ;). >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> >> 2015-01-08 9:02 GMT+01:00 Mark Struberg <[email protected]>: >>> Romain the point is that you would do that yourself and provide it in e.g. >> a static field basically (that's what it boils down to - regardless how >> gloriously you wrap it in factory methods). >>> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>>> On Thursday, 8 January 2015, 8:59, Romain Manni-Bucau >> <[email protected]> wrote: >>>> > Hmm, Anatole can you just rephrase it - not sure I get it as you >> think >>>> it, in particular not sure what your "contextually" means >> here. >>>> >>>> For me ConfigurationProvider is just the impl of the factory/builder >>>> and is contextual only in the boot phase - ie it uses TCCL to find the >>>> impl. >>>> >>>> ServiceContext would be quite useless in my model but we would have >>>> Configuration instance with a close() method. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> >>>> 2015-01-08 3:11 GMT+01:00 Anatole Tresch <[email protected]>: >>>>> Hi Romain >>>>> >>>>> let me say that way: it was my original design proposal to have a >>>>> ConfigurationSpi that provides different Configuration instances >>>>> contextually. >>>>> So now we might have a ConfigurationProvider instead of >> ConfigurationSpi, >>>>> but we might end up at the same idea: ConfigurationProvider >> implements >>>>> contextuality, ServiceContext is just the registry of the >> instances... >>>>> >>>>> Anatole >>>>> >>>>> >>>>> 2015-01-07 23:20 GMT+01:00 Romain Manni-Bucau >>>> <[email protected]>: >>>>> >>>>>> so basically we have a ServiceContext<KEY> with get(KEY) >> and >>>>>> release(KEY) - if so OWB has a complete working impl of this >> pattern? >>>>>> >>>>>> still find weird to have it in core and not in another module. >> EE list >>>>>> speaks about having a kind of meta container - still an idea >> today - >>>>>> where you can register "sub containers": >>>>>> >>>>>> Properties p = new Properties(); >>>>>> p.put(ContainerFactory.JPA_CONTAINER, myJpaContainer); >>>>>> p.put(ContainerFactory.BVAL_CONTAINER, myBValContainer); >>>>>> //... >>>>>> Container c = ContainerFactory.create(props); >>>>>> >>>>>> (sub)containers would be here just more or less providers of >> instances >>>>>> (EntityManagerFactory for JPA, ValidatorFactory for BVal >> etc...) or >>>>>> factories of these factories - not yet clear. In such a >> pattern and >>>>>> even if I'm not very convinced of this I think the overall >> view is >>>>>> good. The main container is still the one to choose how to >> affect >>>>>> sub-containers. So if you want to plug the config you still >> have the >>>>>> issue the config does what it wants or you need to not respect >> the >>>>>> given container to switch the ServiceContext. >>>>>> >>>>>> IMO it is really the case for an app. >>>>>> >>>>>> Makes me think to 2 things: >>>>>> 1) we miss ConfigurationProvider API - this is not the context >> which >>>>>> is a runtime solution >>>>>> 2) locking to a contextual solution is just a provider >> implementation >>>> IMO >>>>>> >>>>>> wdyt? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau >>>>>> http://www.tomitribe.com >>>>>> http://rmannibucau.wordpress.com >>>>>> https://github.com/rmannibucau >>>>>> >>>>>> >>>>>> 2015-01-07 22:58 GMT+01:00 Anatole Tresch >> <[email protected]>: >>>>>> > Hi Mark just did no know this abbreviation. I agree there >> are use >>>> cases >>>>>> > where the TCCL is not appropriate (or even null). So >> adding a >>>> parameter >>>>>> to >>>>>> > set it might be a good idea... >>>>>> > >>>>>> > 2015-01-07 22:50 GMT+01:00 Mark Struberg >>>> <[email protected]>: >>>>>> > >>>>>> >> > TCCL >>>>>> >> > ??? >>>>>> >> >>>>>> >> >>>>>> >> TCCL = ThreadContextClassLoader. >>>>>> >> >>>>>> >> >>>>>> >> java.util.ServiceLoader uses it internally if you >> don't >>>> explicitly >>>>>> specify >>>>>> >> a ClassLoader as parameter [1]. Thus we do also rely >> on the >>>> TCCL >>>>>> >> implicitly. But for e.g. @ApplicationScoped beans in >> shared >>>> libs of >>>>>> EARs we >>>>>> >> might need to not use the TCCL but the application >> classloader >>>> (== EAR >>>>>> >> ClassLoader). >>>>>> >> >>>>>> >> LieGrue, >>>>>> >> strub >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> [1] >>>>>> >> >>>>>> >>>> >> http://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html#load%28java.lang.Class,%20java.lang.ClassLoader%29 >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> > On Wednesday, 7 January 2015, 22:39, Anatole >> Tresch < >>>>>> [email protected]> >>>>>> >> wrote: >>>>>> >> > > Hi Mark >>>>>> >> > >>>>>> >> > see inline ;) >>>>>> >> > >>>>>> >> > 2015-01-07 22:25 GMT+01:00 Mark Struberg >>>> <[email protected]>: >>>>>> >> > >>>>>> >> >> well, option 1. already works really fine >> for CDI, >>>> JSF, EL, JSP, all >>>>>> >> >> Logging frameworks, etc. Why shouldn't >> it work >>>> well for config >>>>>> neither? >>>>>> >> >> >>>>>> >> > +1 >>>>>> >> > >>>>>> >> > The question is what more do we need? >>>>>> >> >> >>>>>> >> >> 1.a: Do we like to solely rely on the >>>>>> >> >> >>>>>> >> >> TCCL or do we like to add it as parameter >> to our >>>> factory? >>>>>> >> >> >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > TCCL >>>>>> >> > ??? >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > 1.2: Do we like to add a >> shutdown/release/cleanup method >>>> to the >>>>>> >> >> ServiceContext? >>>>>> >> >> >>>>>> >> > Hmm, since we also have according earlifecycle >> listeners >>>> and similar >>>>>> >> stuff >>>>>> >> > in place, this makes sense. We should go all >> miles as >>>> far as we can >>>>>> go >>>>>> >> to >>>>>> >> > have a solution that does not impact system >> stability, so >>>> IMO yes! >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> >> 2. would be fine if there wouldn't be >> the huge >>>> problem with >>>>>> propagating >>>>>> >> >> each certain configuration. In practice you >> are back >>>> to reading YOUR >>>>>> >> config >>>>>> >> >> and thus ending up having 47 different and >> parallel >>>> 'realities'. It >>>>>> >> > is >>>>>> >> >> pretty much impossible to properly handle >> this in >>>> big apps. If you >>>>>> see >>>>>> >> a >>>>>> >> >> solution for this problem then please share >> your >>>> ideas. >>>>>> >> >> >>>>>> >> > +1 >>>>>> >> > >>>>>> >> > On top of that managing the mechanisms centrally >> also >>>> gives you the >>>>>> >> ability >>>>>> >> > to more easily built analysis tools that helps >> finding >>>> bugs. This is >>>>>> >> often >>>>>> >> > much underestimated, but can be a real pain in >> big >>>> systems, especially >>>>>> >> when >>>>>> >> > several dozens of teams all are providing some >> confif >>>> parts... >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> >> >>>>>> >> >> LieGrue, >>>>>> >> >> strub >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> > On Wednesday, 7 January 2015, 21:35, >> Romain >>>> Manni-Bucau < >>>>>> >> >> [email protected]> wrote: >>>>>> >> >> > > IMO we can't do 1 right cause >> it is >>>> very dependent of the app >>>>>> >> > and its >>>>>> >> >> > stack. All our solution would be >> degraded mode >>>> working more or >>>>>> less >>>>>> >> >> > well depending the app. >>>>>> >> >> > >>>>>> >> >> > 2 is nice cause aligned with almost >> all specs + >>>> simple. >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > Romain Manni-Bucau >>>>>> >> >> > @rmannibucau >>>>>> >> >> > http://www.tomitribe.com >>>>>> >> >> > http://rmannibucau.wordpress.com >>>>>> >> >> > https://github.com/rmannibucau >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > 2015-01-07 20:40 GMT+01:00 Mark >> Struberg >>>> <[email protected]>: >>>>>> >> >> >> Hi! >>>>>> >> >> >> >>>>>> >> >> >> We had great discussions and many >> valid >>>> and important aspects >>>>>> did >>>>>> >> > came >>>>>> >> >> up. >>>>>> >> >> > Too bad they were spread all over the >> place in >>>> various threads ;) >>>>>> >> >> >> >>>>>> >> >> >> So let's again pick up the >> discussion. >>>>>> >> >> >> >>>>>> >> >> >> We basically have 2 options. >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> 1.) a 'contextual' >> approach like >>>> we currently have with >>>>>> >> > our >>>>>> >> >> > ServiceContext. There is exactly 1 >>>> Configuration 'per >>>>>> >> > application'. >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> 2.) a 'builder' approach. >> The >>>> configuration system gets >>>>>> >> > built by >>>>>> >> >> > the user as often as the user likes >> and in >>>> exactly the way the >>>>>> user >>>>>> >> >> likes. In >>>>>> >> >> > that case andling the configuration >> for whole >>>> application is _not_ >>>>>> >> > part >>>>>> >> >> of this >>>>>> >> >> > project. Means any contextually would >> need to >>>> be provided as >>>>>> >> >> @ApplicationScoped >>>>>> >> >> > producer bean or in other ways. >>>>>> >> >> >> >>>>>> >> >> >> Now it's your turn. Gimme all >> the pros >>>> and cons ;) >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> 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/ >>>>>> > <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/ >>>>> <http://javaremarkables.blogspot.ch/>* >>>>> >>>>> *Google: atsticksMobile +41-76 344 62 79* >>>> >>
