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