Pushed eveything I had and created the related jira for 1.8.0.
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-08 21:28 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > Le 8 nov. 2016 18:59, "John D. Ament" <johndam...@apache.org> a écrit : > > > > I'm personally fine with that as a first pass but agree its going to > cause > > some issues because config is available pre-initialization of container > > (e.g. there maybe no CDI available yet) as a result converters, filters > may > > not work. Something to resolve at a later point. > > > > The use case is runtime config - extension config being considered there > as internal config or the app which can be hardcoded. > > I ll wait until tomorrow and if nobody shout will create tickets and push > on master. > > > John > > > > On Tue, Nov 8, 2016 at 12:57 PM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > > > @ConfigProperty(converter) method was added and ConfigSource and > > > ConfigFilter decoarated with @Source and @Filter are added to the > config > > > using cdi bean lookup after extension startup (= usable after CDI > startup > > > but without any META-INF/services and with all CDI features like > injections > > > and interceptors) > > > > > > > > > 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-08 18:52 GMT+01:00 John D. Ament <johndam...@apache.org>: > > > > > > > What's currently on your branch? I saw proxy. Anything else? > > > > > > > > John > > > > > > > > On Tue, Nov 8, 2016 at 12:46 PM Romain Manni-Bucau < > > > rmannibu...@gmail.com> > > > > wrote: > > > > > > > > > if i open 3 tickets (convert, proxy, cdi source/filter) then push > my > > > > branch > > > > > does it work? > > > > > > > > > > > > > > > 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-08 18:43 GMT+01:00 John D. Ament <johndam...@apache.org>: > > > > > > > > > > > On Mon, Nov 7, 2016 at 12:41 PM Romain Manni-Bucau < > > > > > rmannibu...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > 2016-11-07 17:56 GMT+01:00 Mark Struberg > <strub...@yahoo.de.invalid > > > > >: > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > I'd say this one is easy for deltaspike if we re-read the > project > > > > > > proposal > > > > > > > (and BTW should be the same under EE ecosystem now, other > choices > > > > don't > > > > > > > make much sense now in particuar for the config which should be > > > > > > > contextualized by something else than itself - ok off topic > ;)). > > > > > > > > > > > > > > Concretely how do we move forward on these topics? I'm > concerned to > > > > get > > > > > > > converter method in @ConfigProperty, the @Source/@Filter > detection > > > > and > > > > > > > proxy support. Other mentionned features can be put on a > backlog or > > > > > > > forgotten I wouldn't cry. > > > > > > > > > > > > > > > > > > > > That's actually why i was saying separate JIRA tickets. Tackle > the > > > > > complex > > > > > > needed stuff now, work on the more polish stuff later. > > > > > > > > > > > > Obviously, deltaspike should be focused on CDI runtimes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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> > > > > > > > > >>> >> > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
