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* >>> >
