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