2016-11-07 17:56 GMT+01:00 Mark Struberg <[email protected]>:
> 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. > > LieGrue, > strub > > > > > > On Monday, 7 November 2016, 12:44, Romain Manni-Bucau < > [email protected]> 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 <[email protected]>: > > > >> 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 <[email protected]>: > >> > >>> +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 > > <[email protected]> > >>> wrote: > >>> > > Some thoughts in line. > >>> > > >>> > On Sun, Nov 6, 2016 at 3:16 PM Romain Manni-Bucau < > >>> [email protected]> > >>> > 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> > >>> >> > >>> > > >>> > >> > >> > > >
