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