yes the EAR case is a bit harder. Also OSGi is a bit tricky. In my javaconfig proposal I have moved this out into a SPI which is pluggable. The only requirement is that you can get the config for 'your application' via ConfigProvider#getConfig().
If this is internally done via a Map<ClassLoader, Config> or a Map<ConfigExtension, Config> or via a ThreadLocal is totally up to the implementation. For OSGi the ClassLoader might not be as good as in a WAR or EAR. The ThreadLocal might blow up in an EAR on various containers, etc. I fear there is no one-fits-all solution. We might provide an impl which can be configured to use different strategies. The question is whether we like to make it depending on CDI or if it should also work purely in SE. LieGrue, strub > On Monday, 7 November 2016, 12:44, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > added @Source and @Filter as markers (was breaking applications otherwise), > pushed the basic plain proxying too. Only tested with OWB for now but seems > not bad. > > The storage change is more impacting cause of ear case which is not > protable at all so wonder if we can do anything about it without breaking > existing applications. Maybe we should just ensure we don't leak the > classloader as key for now to not break anyone (we can leak if CDI doesn't > finish to start and the application is undeployed AFAIK). > > Adding the ConfigResolver as an instance in the CDI context (= a bean) is > still an option IMHO but can wait and is more an internal refactoring than > an API work. > > wdyt? What would be the next steps? JIRA for converter method, proxy > feature and source/filter detection in CDI? > > Happy to also get some help on running it on other containers. > > > > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2016-11-07 9:39 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > >> In the spirit of sharing and trying to move forward I started a branch on >> my github fork: https://github.com/rmannibucau/deltaspike/tree/ >> fb/config-rework >> >> For now it includes 1 ("easy") and 5 (pre 2 storage but will be > part of >> the refactoring "2" normally since we'll not break this API). >> >> About 5 there is the question of the detection. By type is enough >> technically but wonder if we should introduce @Source and @Filter just as >> markers to ensure we don't also detect SPI sources and filters which > are >> likely CDI beans in a lot of apps. >> Feedback welcomed ^^ :). >> >> Once done, next step will be to add 3 then try to do 2. If all is good we >> can work on the jira tickets. >> >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://blog-rmannibucau.rhcloud.com> | Old Blog >> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory >> <https://javaeefactory-rmannibucau.rhcloud.com> > >> >> 2016-11-06 21:40 GMT+01:00 Mark Struberg <strub...@yahoo.de.invalid>: >> >>> +1 for moving the Config out into an own module. It's the best we > can do >>> for now. The JSR will likely take a bit to evolve and until then we can > use >>> what we have in DeltaSpike. Just a bit cleaned up. >>> >>> LieGrue, >>> strub >>> >>> >>> PS: a single ticket is by far enough imo. >>> >>> >>> >>> >>> > On Sunday, 6 November 2016, 21:28, John D. Ament > <johndam...@apache.org> >>> wrote: >>> > > Some thoughts in line. >>> > >>> > On Sun, Nov 6, 2016 at 3:16 PM Romain Manni-Bucau < >>> rmannibu...@gmail.com> >>> > wrote: >>> > >>> >> Hi guys >>> >> >>> >> sent it some times ago - ok, a long time ago now ;) - but > will retry >>> with >>> >> few more details now. >>> >> >>> >> Goal: I'd like to rework a bit our configuration >>> >> >>> > >>> > How does this relate, if at all, to Mark's proposal for config > on >>> geronimo? >>> > >>> > >>> >> >>> >> Proposals (no particular order but numbered to let it be > referenced): >>> >> 1. Add converter to @ConfigProperty (cdi lookup or fallback > on >>> >> newInstance() probably) >>> >> >>> > >>> > +1 >>> > >>> > >>> >> 2. remove the map storage we have and replace it by >>> >> 2.a. a thread local during the boot ConfigResolver would use >>> >> 2.b. a config bean for the runtime (BeanProvider or > CDI.current() >>> allow to >>> >> get it easily) >>> >> >>> > >>> > +1000 I hate the static methods for users. >>> > >>> > >>> >> 3. add an interface/abstract class based configuration > "à la >>> > owner" >>> >> (probably reusing @ConfigProperty) >>> >> >>> > >>> > I've been thinking about this as well. Sounds like a good fit > for >>> partial >>> > bean. >>> > >>> > >>> >> 4. extract config in its own module to let it be reused more > widely >>> without >>> >> bringing all ds core >>> >> >>> > >>> > I like the idea. But I think the real problem is defining what is > core >>> vs >>> > what is a module. To me, core should be a lightweight component. > We've >>> > stuck some extra stuff in there that can be a pain sometimes. May > be >>> worth >>> > an entirely separate thread. >>> > >>> > >>> >> 5. support during bootstrap the detection of converters and > sources >>> (not >>> >> only propertyfile ones) and add them in the runtime config > added in >>> 2.b >>> >> >>> > >>> > Well, this kind of works today. Using a property source provider, > I was >>> > able to create a archaius config source and have it discovered > pretty >>> early >>> > on. >>> > >>> > >>> >> >>> >> 2. implies we don't use the config in extension > constructor (which >>> > should >>> >> be fine) and that we can cleanup the thread local after CDI > startup >>> (here >>> >> we can have few options to enforce this cleanup like using >>> >> AfterDeploymentValidation by default + probably either some > container >>> >> dependent solutions or at least a > ServletContextListener#context >>> Destroyed >>> >> for the case deployment fails) >>> >> >>> >> Excepted the usability (converter option, extraction in a > dedicated >>> module) >>> >> the goal is to not do any concurrence to CDI lookup mecanism > and stay >>> 100% >>> >> aligned on it. >>> >> >>> >> In term of usability the fact to be able to have a real CDI > source >>> DTO for >>> >> runtime and reuse default ones (system properties, properties > in >>> classpath, >>> >> etc..) for the extension itself (internal application > configuration) >>> is a >>> >> huge gain IMHO. >>> >> >>> >> Wdyt? Any blocker? >>> >> >>> > >>> > Would you be able to get the ideas into JIRA as a few different > tickets? >>> > >>> > >>> > >>> >> >>> >> This would likely lead to a 1.8. >>> >> >>> >> Romain Manni-Bucau >>> >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> >> <https://blog-rmannibucau.rhcloud.com> | Old Blog >>> >> <http://rmannibucau.wordpress.com> | Github < >>> >> https://github.com/rmannibucau> | >>> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | > JavaEE Factory >>> >> <https://javaeefactory-rmannibucau.rhcloud.com> >>> >> >>> > >>> >> >> >
