Re: [cdi-dev] With the end of Java Config...

Hi, If it's not really usable as API or annotation I don't see much value in adding some "how to" or intent for the future into the Spec Document. If it was to become a part of CDI 2, there's nothing against optionality like MEEP 8 or JSR 363 already practice on the SE/EE side either. Agorava/DeltaSpike demonstrate how true modularity work, similar to the JSRs mentioned above, where you have multiple module JARs/bundles instead of a big monolithic one. Some JSRs like Batch also declared separate "annotation" modules, so that's what CDI 2 should also do if it was a feature Inside of it. Calling some features optional if they're not used by every implementation allows them to chose. That was also the main value of keeping @Inject a separate "module" under CDI. It was never included into a JDK but used independently. The core of a Config module would ideally work in SE, but CDI 2 already declared an aim to have some modules work under SE. Werner Am 08.09.2014 09:47 schrieb "Antonio Goncalves" <antonio.goncalves(a)gmail.com > Hi all, > > I really have some concerns about adding configuration into CDI but I can > see benefits too. And what about adding it... and not adding it at the same > time ? In Bean Validation 1.0, the Expert Group decided not to include > method-level validation in the spec (it was included in 1.1). But what they > did is to add it as a proposal in the Appendix. > > If we feel some configuration should get in, why not have a proposal in > the Appendix of CDI 2.0 ? It could then be implemented by Weld (and > OpenWebBeans if they feel like it). And then, if it's successful and things > get easier, get its own JSR for Java EE 9. > > WDYT ? > > Antonio > > On Mon, Sep 8, 2014 at 7:03 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; > wrote: > >> Hmm >> >> I see config jsr as a jse spec which would allow EE injections in config >> components in EE containers (exactly like jbatch). >> >> This way it can be used without any container or with any container >> easily. Only limit will be to not do something cdi/known containers will >> not support I think. >> >> Not sure EE side is needed today, a lot can already be done without it >> and it can be enhanced later adding some integration words. >> Le 8 sept. 2014 00:01, "Anatole Tresch" <atsticks(a)gmail.com&gt; a écrit : >> >> Hi Romain >>> >>> just a few remarks inline... >>> >>> Summarizing >>> 1) injection of values, reinjection, feedback on config changes can all >>> be done with already existing features (producers, extensions). >>> 2) configuring/bootstrapping CDI itself, e.g. configuration, is targeted >>> with CDI 2.0 (see spec failing) >>> >>> So basically we could try to look if there is enough interest to >>> standardize configuration in a more general way. For deployment aspects we >>> need an EE JSR, for the rest, another SE standard may be an option as >>> well... tbd... >>> >>> -Anatole >>> >>> >>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau <rmannibucau(a)gmail.com>>> >>>> well sorry to pop in so late but here are my 2cts >>>> >>> ​easy ;)​ >>> >>> >>>> Config JSR is more about environment config IMHO and putting it in CDI >>>> doesn't make sense since more or more spec works without any other >>>> spec - CDI in our case. >>> >>> ​CDI even with some config mechanism added would still work >>> "standalone".​ >>> >>> >>> >>>> This mean CDI can't be the place but should >>>> just be the bridge for config JSR. >>> >>> ​As I suggested as well.​ >>> >>> >>> >>>> Plus CDI config will surely highly >>>> be an application config first (beans.xml should be the place then) >>>> >>> ​Yes, app config, but beware people of writing config into beans.xml. >>> That is definitively in most cases not what you want.​ CDI should not >>> define, where and how config is located and formatted. CDI should provide a >>> SPI, where config providers can publish the configured values, so it can be >>> injected wherever needed. E.g. some kind of producer, that can provide >>> multiple objects to be injected and can benefit from some kind of callback >>> mechanism would be sufficient... >>> >>> >>>> then environment config can be done at EE level (saying it has to >>>> support placeholders or any pre deployment processing). >>>> >>> ​Config is much more complex. There is no clear border what is >>> environment config or environment dependent and what not. This depends on >>> what kind of application you have deployed. As an example the email >>> address, where you send error messages, can be different depenending on the >>> stage/environment, but this is not EE related config entry. Also what an >>> environment is, is not a thing that you can define completely. So I agree >>> not to add this complexities to CDI, I would hide them between some kind of >>> "config provider", as mentioned above.​ CDI does not need to know if the >>> config provided is environment dependent or not, its just what is visible >>> at a current runtime state... >>> >>> >>>> If you put something like ProjectStage in CDI it is great but then you >>>> have it in JSF, CDI and finally surely all specs...same as >>>> converters... >>>> >>> ​That was originally the idea, when doing a EE config JSR, but without >>> such standard. I agree, CDI is not the place to define them. >>> >>> >>> >>>> Config should really be split in: >>>> 1) spec dependent config -> spec.xml >>>> 2) *common* config (a bit like javax.annotation) for environment and >>>> external configuration -> Config JSR >>>> >>> ​Not 100% sure, if a get the point here... >>> >>> >>> >>> >>> >>> 2014-09-08 0:10 GMT+02:00 Romain Manni-Bucau <rmannibucau(a)gmail.com>>> >>>> well sorry to pop in so late but here are my 2cts >>>> >>>> Config JSR is more about environment config IMHO and putting it in CDI >>>> doesn't make sense since more or more spec works without any other >>>> spec - CDI in our case. This mean CDI can't be the place but should >>>> just be the bridge for config JSR. Plus CDI config will surely highly >>>> be an application config first (beans.xml should be the place then) >>>> then environment config can be done at EE level (saying it has to >>>> support placeholders or any pre deployment processing). >>>> >>>> If you put something like ProjectStage in CDI it is great but then you >>>> have it in JSF, CDI and finally surely all specs...same as >>>> converters... >>>> >>>> Config should really be split in: >>>> 1) spec dependent config -> spec.xml >>>> 2) *common* config (a bit like javax.annotation) for environment and >>>> external configuration -> Config JSR >>>> >>>> wdyt? >>>> >>>> >>>> >>>> Romain Manni-Bucau >>>> Twitter: @rmannibucau >>>> Blog: http://rmannibucau.wordpress.com/ >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>> Github: https://github.com/rmannibucau >>>> >>>> >>>> 2014-09-07 23:39 GMT+02:00 Werner Keil <werner.keil(a)gmail.com>>>> > Sounds like an argument for a CDI module rather than a separate JSR >>>> then?;-) >>>> > >>>> > On Sun, Sep 7, 2014 at 11:32 PM, Anatole Tresch <atsticks(a)gmail.com&gt; >>>> wrote: >>>> >> >>>> >> I would not worry about CDI regarding licensing. Just the sentence >>>> was >>>> >> that Oracle does not want to have more ALv2 in addition to what is >>>> already >>>> >> there. So as long as we do things within CDI, no worries, I think. >>>> For new >>>> >> EE JSRs nevertheless this is a BIG issue and should be clarified by >>>> the EC! >>>> >> >>>> >> >>>> >> 2014-09-07 21:44 GMT+02:00 Werner Keil <werner.keil(a)gmail.com>>>> >>> >>>> >>> Indeed, and with CDI 1.2 (MR) and 2.0 offering even the Spec under >>>> ALv2 >>>> >>> as a dual-license, this was discussed by EC Members but both JCP EC >>>> and >>>> >>> Oracle Legal/PMO seems fine with it, and CDI is already an essential >>>> >>> building block to Java EE 6/7, hence used with Glassfish, too. I >>>> wasn't >>>> >>> involved in these discussions, but given CDI is especially liberal >>>> and fully >>>> >>> accepted by JCP formalities and license policies, I don't really >>>> see what >>>> >>> the problem wss for Anatole's JSR attempt (though I know, both >>>> Oracle and >>>> >>> other EC Members/companies don't always prefer this kind of >>>> licensing...;-) >>>> >>> >>>> >>> Werner >>>> >>> >>>> >>> On Sun, Sep 7, 2014 at 9:28 PM, John D. Ament < >>>> john.d.ament(a)gmail.com&gt; >>>> >>> wrote: >>>> >>>> >>>> >>>> Ok, this mail has me more concerned than anything. Can you >>>> clarify this >>>> >>>> ALv2 statement? AFAIK, Weld (the CDI RI) is ALv2. >>>> >>>> >>>> >>>> On Sun, Sep 7, 2014 at 3:12 PM, Anatole Tresch <atsticks(a)gmail.com >>>> > >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi All >>>> >>>>> >>>> >>>>> unfortunately things seem quite complicated: >>>> >>>>> >>>> >>>>> first of all, similarities with Deltaspike are basically not >>>> >>>>> accidental. The concepts we developed in Credit Suisse are very >>>> similar to >>>> >>>>> Deltaspike, though Deltaspike was not yet born at that time. >>>> Fortunately we >>>> >>>>> ended up with a similar kind of solution. >>>> >>>>> filtering still can be done. My idea is to define some kind of >>>> >>>>> "configuration provider", which then is dynamically asked for >>>> configuration. >>>> >>>>> How the provider is internally organized, is completely >>>> transparent to CDI. >>>> >>>>> This enables to have multi-layered, complex config solutions work >>>> the same >>>> >>>>> (from a view point of CDI) like simple programmatic test >>>> configurations >>>> >>>>> during unit tests. The config provider still can support >>>> filtering and >>>> >>>>> dynamic resolution as commonly used in configuration systems. >>>> Similarly the >>>> >>>>> format is basically also not fixed. Of course, would a reference >>>> >>>>> implementation provide a set of functionalities, but I would >>>> definitively >>>> >>>>> not define the exact configuration mechanism as part of the CDI >>>> (or even a >>>> >>>>> EE config JSR). Another reason, beside complexity and time, is >>>> the fact that >>>> >>>>> different companies handle, store and manage configuration >>>> differently, so a >>>> >>>>> mechanism must be flexible enough to accommodate these, without >>>> adoption >>>> >>>>> rate will be low. Furthermore this flexibility also keeps doors >>>> open for use >>>> >>>>> cases we do not know yet. >>>> >>>>> Also we have to separate some basically two types of configuration >>>> >>>>> aspects: >>>> >>>>> >>>> >>>>> application config basically is injected into deployed >>>> components, but >>>> >>>>> basically only can affect deployment to the extend it can be >>>> managed and >>>> >>>>> injected by CDI. The basic architecture and design, how >>>> application servers >>>> >>>>> to load and deploy are basically not affected. This type of >>>> configuration >>>> >>>>> (mechanism) I see also as a possible addition to CDI, if we >>>> really fail to >>>> >>>>> do something in another JSR. With CDI going for a more modular >>>> design, even >>>> >>>>> basic configuration of CDI can be possible, given we have some >>>> kind of API, >>>> >>>>> we can access during CDI initialization. >>>> >>>>> On the other side deployment configuration affects directly how >>>> the >>>> >>>>> application server deploys the application. Configuration here >>>> would allow >>>> >>>>> to define datasources, EJBs, transactional aspects, security, >>>> persistence, >>>> >>>>> war and ear configurations etc. Basically everything you do as of >>>> today with >>>> >>>>> some kind of XML file, or annotation. Hereby enabling more >>>> flexibility into >>>> >>>>> the existing descriptors is relatively easy, but as mentioned by >>>> Mark, >>>> >>>>> constraint. Adding more flexibility raises other subtle problems. >>>> Imagine a >>>> >>>>> application module, e.g. a war, that defines everything it >>>> requires. There >>>> >>>>> is no need to configure anything more on server side (with spring >>>> you can do >>>> >>>>> this, with Java EE unfortunately not). But this has a severe >>>> consequence, it >>>> >>>>> would make the application really portable in the sense, that it >>>> can be >>>> >>>>> moved between different app servers (vendors) without any change >>>> (ideally). >>>> >>>>> As a result commercial profits of some vendor companies may be >>>> affected. I >>>> >>>>> think this is actually one of the key points, why things are >>>> getting so >>>> >>>>> complicated in that area. >>>> >>>>> >>>> >>>>> Legal aspects also were discussed. One of them is a possible legal >>>> >>>>> clash of ALv2 with GPL. This is the case already within >>>> Glassfish, but one >>>> >>>>> of the reasons, why ALv2 was not acceptable to Oracle's legal >>>> department. At >>>> >>>>> the end we decided to use a BSD model. Even dual licensing >>>> BSD/ALv2 could >>>> >>>>> theoretically be an option. If you would choose ALv2, Oracle will >>>> not >>>> >>>>> include your RI into Glassfish, which is the RI for the EE >>>> Umbrella JSR, >>>> >>>>> meaning your JSR will not be included into EE8. So what should we >>>> do? I >>>> >>>>> don't have a good answer... >>>> >>>>> >>>> >>>>> So, I like to discuss configuration aspects here. Nevertheless if >>>> we >>>> >>>>> decide to add config aspects, be aware that we might only >>>> (mainly) support >>>> >>>>> application config, since everything else directly would impact >>>> other JSRs. >>>> >>>>> And that is obviously quite similar to what Apache Deltaspike is >>>> all about >>>> >>>>> ;-) >>>> >>>>> >>>> >>>>> Cheers, >>>> >>>>> Anatole >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> 2014-09-07 14:46 GMT+02:00 Mark Struberg <struberg(a)yahoo.de>>>> >>>>>> >>>> >>>>>> Yes, the config group also was (obviously) looking at DeltaSpikes >>>> >>>>>> config mechanism as well. >>>> >>>>>> There were others who wanted to go more into the 'filtering' >>>> approach >>>> >>>>>> as done on WebLogic servers (though not sure who else does that >>>> as well). >>>> >>>>>> You know, having all the XML configs like WEB-INF/web.xml >>>> containing >>>> >>>>>> placeholders and the real values only get placed in there at >>>> deployment >>>> >>>>>> time. I personally find this approach a bit limited from a >>>> technical >>>> >>>>>> perspective and it already didn't work out for me when using >>>> WebLogic (what >>>> >>>>>> about changing a configured value after the deployment was done? >>>> What about >>>> >>>>>> security? Having passwords in web.xml, unit testing, ...). >>>> >>>>>> There are of course also other approaches which all might have >>>> strong >>>> >>>>>> sides and would have needed to get discussed. >>>> >>>>>> >>>> >>>>>> But utterly the problem seems to have been legal reasons. We even >>>> >>>>>> offered to have Anatole/CS lead the EG and do the RI as an ASF >>>> project with >>>> >>>>>> substantial support and participation from the JBoss, DeltaSpike >>>> and TomEE >>>> >>>>>> communities. >>>> >>>>>> >>>> >>>>>> Anyway, the time will come when we will resurrect this effort. >>>> >>>>>> >>>> >>>>>> LieGrue, >>>> >>>>>> strub >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Sunday, 7 September 2014, 14:29, Werner Keil >>>> >>>>>> <werner.keil(a)gmail.com&gt; wrote: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Yep, it contains a simple but extendable notion of ProjectStage, >>>> >>>>>> too;-) >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Sun, Sep 7, 2014 at 2:19 PM, John D. Ament < >>>> john.d.ament(a)gmail.com&gt; >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>>>> Anatole, >>>> >>>>>> >>>> >>>>>> I'm wondering if some of your configuration description falls >>>> under >>>> >>>>>> what was put together in DeltaSpike? >>>> >>>>>> >>>> >>>>>> http://deltaspike.apache.org/configuration.html >>>> >>>>>> >>>> >>>>>> John >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Fri, Sep 5, 2014 at 6:18 PM, Anatole Tresch < >>>> atsticks(a)gmail.com&gt; >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>>>> Staging is not a question of xml or not xml (the "format" of >>>> config). >>>> >>>>>> You can do staged config also using xml, or based on a database >>>> or json >>>> >>>>>> config service. Staging as well as, more generally speaking, >>>> environment >>>> >>>>>> dependent config is more like to select/filter the right config >>>> that targets >>>> >>>>>> the current (runtime) environment. This might include stages, >>>> but also many >>>> >>>>>> other aspects are feasible and common (server, tier, ear, war, >>>> tenant ...). >>>> >>>>>> Since these aspects are per se very complex, it might be >>>> advisable to leave >>>> >>>>>> them out of any spec (even a dedicated config JSR would probably >>>> not be >>>> >>>>>> capable of covering these within the relatively short EE >>>> timeframe)... >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2014-09-05 23:30 GMT+02:00 Werner Keil <werner.keil(a)gmail.com>>>> >>>>>> >>>> >>>>>> Jens/all, >>>> >>>>>> >>>> >>>>>> A sort of "staging" already was possible using CDI earlier, see >>>> >>>>>> examples like this: >>>> >>>>>> >>>> >>>>>> >>>> http://stackoverflow.com/questions/16907185/multiple-cdi-configuration-pr... >>>> >>>>>> >>>> >>>>>> DeltaSpike also includes type-safe staging that goes beyond the >>>> >>>>>> primitive, hard-coded JSF enum. >>>> >>>>>> >>>> >>>>>> If that works without XML, while still allowing flexible >>>> configuration >>>> >>>>>> for different stages or to add and "inject" additional stages >>>> maybe even on >>>> >>>>>> a tenant basis (for Cloud scenarios) I could see something like >>>> that work >>>> >>>>>> without XML. In the Multiconf project we managed to code >>>> everything in >>>> >>>>>> Python, and similar to Puppet or Chef you can configure and >>>> deploy multiple >>>> >>>>>> environments with it, Java EE, Spring or Play! several of them >>>> are >>>> >>>>>> configured this way and it requires no XML (where the container >>>> needs such >>>> >>>>>> files, the framework generates them;-) >>>> >>>>>> >>>> >>>>>> Werner >>>> >>>>>> >>>> >>>>>> On Fri, Sep 5, 2014 at 10:21 PM, < >>>> cdi-dev-request(a)lists.jboss.org&gt; >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>>>> Send cdi-dev mailing list submissions to >>>> >>>>>> cdi-dev(a)lists.jboss.org >>>> >>>>>> >>>> >>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> or, via email, send a message with subject or body 'help' to >>>> >>>>>> cdi-dev-request(a)lists.jboss.org >>>> >>>>>> >>>> >>>>>> You can reach the person managing the list at >>>> >>>>>> cdi-dev-owner(a)lists.jboss.org >>>> >>>>>> >>>> >>>>>> When replying, please edit your Subject line so it is more >>>> specific >>>> >>>>>> than "Re: Contents of cdi-dev digest..." >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Today's Topics: >>>> >>>>>> >>>> >>>>>> 1. Re: Tools : Google Drive vs Asciidoc and Github (Anatole >>>> Tresch) >>>> >>>>>> 2. Re: With the end of Java Config... (Anatole Tresch) >>>> >>>>>> 3. [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition >>>> >>>>>> (Anatole Tresch (JIRA)) >>>> >>>>>> 4. Re: With the end of Java Config... (Jens Schumann) >>>> >>>>>> >>>> >>>>>> ------------------------------ >>>> >>>>>> >>>> >>>>>> Message: 4 >>>> >>>>>> Date: Fri, 5 Sep 2014 20:20:53 +0000 >>>> >>>>>> From: Jens Schumann <jens.schumann(a)openknowledge.de&gt; >>>> >>>>>> Subject: Re: [cdi-dev] With the end of Java Config... >>>> >>>>>> To: Anatole Tresch <atsticks(a)gmail.com&gt;, Antonio Goncalves >>>> >>>>>> <antonio.goncalves(a)gmail.com&gt; >>>> >>>>>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>>> >>>>>> Message-ID: <D02FDD99.396B9%jens.schumann(a)openknowledge.de&gt; >>>> >>>>>> Content-Type: text/plain; charset="windows-1252" >>>> >>>>>> >>>> >>>>>> I can confirm that this approach works very well. We are using a >>>> >>>>>> similar approach a couple of years now, and I love the >>>> simplicity that comes >>>> >>>>>> with portable extensions and @Producer methods. See our public >>>> version here >>>> >>>>>> [1] (works since early CDI 1.0 days) . >>>> >>>>>> >>>> >>>>>> Instead of a @Inject + Qualifier we just use the qualifier >>>> @Property. >>>> >>>>>> We support default values and type conversation for primitives >>>> and >>>> >>>>>> everything that has a string based constructor. The property >>>> source can be >>>> >>>>>> anything, from property files (default) to databases or xml >>>> files. For >>>> >>>>>> examples see tests here [2]. >>>> >>>>>> >>>> >>>>>> Nevertheless I am not sure if this should be part of an future >>>> CDI >>>> >>>>>> spec. My concerns include the bloat argument, of course. But the >>>> main reason >>>> >>>>>> relates to the fact that we have almost everything in the >>>> current CDI spec >>>> >>>>>> already. >>>> >>>>>> >>>> >>>>>> Right now I am quite happy with an custom portable extension >>>> that does >>>> >>>>>> everything for me. At the time we implemented the extension we >>>> realised that >>>> >>>>>> the "hard part" was writing an extension that links a qualified >>>> "optional >>>> >>>>>> injection point" with an @Producer method while supporting code >>>> based >>>> >>>>>> default values. Luckily I had Arne in my team who did that >>>> within a few >>>> >>>>>> minutes. >>>> >>>>>> >>>> >>>>>> Because of this experience I would propose that we simplify >>>> extension >>>> >>>>>> development such that "optional injection points" may be linked >>>> to @Produces >>>> >>>>>> values easily. Additionally we have to solve a few more >>>> integration issues >>>> >>>>>> (e.g. read-only DB access should be available during CDI >>>> startup). >>>> >>>>>> Everything else should be provided by portable extensions (e.g. >>>> via >>>> >>>>>> delta-spike) and documentation/howtos at cdi-spec.org. >>>> >>>>>> >>>> >>>>>> Jens >>>> >>>>>> [1] >>>> >>>>>> >>>> https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master... >>>> >>>>>> [2] >>>> >>>>>> >>>> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master... >>>> >>>>>> >>>> >>>>>> Von: Anatole Tresch <atsticks(a)gmail.com&lt;mailto: >>>> atsticks(a)gmail.com&gt;&gt; >>>> >>>>>> Datum: Friday 5 September 2014 21:22 >>>> >>>>>> An: Antonio Goncalves >>>> >>>>>> <antonio.goncalves@gmail.com<mailto:antonio.goncalves@gmail.com >>>> >> >>>> >>>>>> Cc: CDI-Dev <cdi-dev(a)lists.jboss.org&lt;mailto: >>>> cdi-dev(a)lists.jboss.org&gt;&gt; >>>> >>>>>> Betreff: Re: [cdi-dev] With the end of Java Config... >>>> >>>>>> >>>> >>>>>> Hi all, >>>> >>>>>> >>>> >>>>>> I would not like to add an XML "bloated" mechanism as part of >>>> CDI 2.0. >>>> >>>>>> Spontaneously I would propose a more CDI like things like: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> * Adding a @Configured annotation (basically a qualifier). >>>> This >>>> >>>>>> can be in addition to @Inject and would allow to inject >>>> "configured" values. >>>> >>>>>> * Since configuration can change we may think of a (CDI) >>>> >>>>>> event/reinject mechanism based on config changes. By default, >>>> this is >>>> >>>>>> switched off and we can discuss how it would be activated, e.g. >>>> by an >>>> >>>>>> additional flag settable with the @Configured annotation, or an >>>> additional >>>> >>>>>> @Observable ConfigChangeEvent (similar to the Griffon >>>> framework), or both. >>>> >>>>>> * Hereby configured values theoretically behave similar as >>>> all >>>> >>>>>> other injection points. They also can be qualified (the aspect >>>> of scopes, I >>>> >>>>>> did not yet have time to think about). The only difference is, >>>> that they are >>>> >>>>>> satisified using the configuration "system". >>>> >>>>>> * The configuration "source" itself could in the extreme >>>> simplest >>>> >>>>>> way be a Provider<Map<String,String>>. The CDI spec should not >>>> care about >>>> >>>>>> how this map is provided (XML, DB, overrides, etc). This still >>>> can be >>>> >>>>>> standardized later. As long as the ConfigurationSource SPI is >>>> defined, >>>> >>>>>> companies still can hook in the logic and level of configuration >>>> abstraction >>>> >>>>>> they need. >>>> >>>>>> * Of course, since not only Strings can be injected, we need >>>> some >>>> >>>>>> conversion or adapter logic as basically outlined in my blog. >>>> Also here we >>>> >>>>>> can add a simple SPI and let the details to the RI. >>>> >>>>>> >>>> >>>>>> Summarizing a >>>> >>>>>> >>>> >>>>>> * @Configured annotation >>>> >>>>>> * some kind of change event >>>> >>>>>> * a ConfigurationSource extends Provider<MapString,String>> >>>> >>>>>> * a conversion mechanism from String to T. >>>> >>>>>> >>>> >>>>>> we get a full fledged configuration mechanism that leverages CDI. >>>> >>>>>> >>>> >>>>>> That would be my idea basically. WDYT? I will try to work that >>>> out in >>>> >>>>>> more details. Basically it should be implementable even with the >>>> CDI >>>> >>>>>> mechanism already in place with CDI 1.1. >>>> >>>>>> >>>> >>>>>> Best, >>>> >>>>>> Anatole >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2014-09-05 16:08 GMT+02:00 Antonio Goncalves >>>> >>>>>> <antonio.goncalves@gmail.com<mailto:antonio.goncalves@gmail.com >>>> >>>>> >>>>>> One wise man* once said "EJB was a hype specification, we added >>>> too >>>> >>>>>> many things to it, it became bloated. The next hype >>>> specifications are >>>> >>>>>> JAX-RS and CDI, careful with them" >>>> >>>>>> >>>> >>>>>> Either we get this idea of "parts" right, or CDI will endup being >>>> >>>>>> bloated. >>>> >>>>>> >>>> >>>>>> Antonio >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> *David Blevin >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Fri, Sep 5, 2014 at 3:28 PM, Antoine Sabot-Durand >>>> >>>>>> <antoine@sabot-durand.net<mailto:antoine@sabot-durand.net>> >>>> wrote: >>>> >>>>>> Hi all, >>>> >>>>>> >>>> >>>>>> You may have followed the rise and fall of the Java Config JSR >>>> >>>>>> ( >>>> http://javaeeconfig.blogspot.ch/2014/09/no-java-ee-configuration-for-ee8-... >>>> ). >>>> >>>>>> Anatole in CC was leading this initiative and I proposed him to >>>> join >>>> >>>>>> us and explore if some part of his late-JSR could be done in CDI. >>>> >>>>>> >>>> >>>>>> I?m mainly thinking of https://issues.jboss.org/browse/CDI-123 >>>> or >>>> >>>>>> related solution. If we achieve to have a majority of specs to >>>> integrate >>>> >>>>>> with CDI, our configuration solution would therefore become a >>>> configuration >>>> >>>>>> system for all spec based on CDI 2.0. >>>> >>>>>> >>>> >>>>>> Antoine >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Antonio Goncalves >>>> >>>>>> Software architect, Java Champion and Pluralsight author >>>> >>>>>> >>>> >>>>>> Web site<http://www.antoniogoncalves.org> | >>>> >>>>>> Twitter<http://twitter.com/agoncal> | >>>> >>>>>> LinkedIn<http://www.linkedin.com/in/agoncal> | >>>> >>>>>> Pluralsight< >>>> http://pluralsight.com/training/Authors/Details/antonio-goncalves> >>>> >>>>>> | Paris JUG<http://www.parisjug.org> | Devoxx France< >>>> http://www.devoxx.fr> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org> >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Anatole Tresch >>>> >>>>>> Java Lead Engineer, JSR Spec Lead >>>> >>>>>> Gl?rnischweg 10 >>>> >>>>>> CH - 8620 Wetzikon >>>> >>>>>> >>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>> >>>>>> Twitter: @atsticks >>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>> >>>>>> Google: atsticks >>>> >>>>>> Mobile +41-76 344 62 79 >>>> >>>>>> -------------- next part -------------- >>>> >>>>>> An HTML attachment was scrubbed... >>>> >>>>>> URL: >>>> >>>>>> >>>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140905/3d951250/at... >>>> >>>>>> >>>> >>>>>> ------------------------------ >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev(a)lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> End of cdi-dev Digest, Vol 46, Issue 20 >>>> >>>>>> *************************************** >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev(a)lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Anatole Tresch >>>> >>>>>> Java Lead Engineer, JSR Spec Lead >>>> >>>>>> Glärnischweg 10 >>>> >>>>>> CH - 8620 Wetzikon >>>> >>>>>> >>>> >>>>>> Switzerland, Europe Zurich, GMT+1 >>>> >>>>>> Twitter: @atsticks >>>> >>>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>> >>>>>> Google: atsticks >>>> >>>>>> Mobile +41-76 344 62 79 >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev(a)lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev(a)lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> cdi-dev mailing list >>>> >>>>>> cdi-dev(a)lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>>> >>>> >>>>>> Note that for all code provided on this list, the provider >>>> licenses >>>> >>>>>> the code under the Apache License, Version 2 >>>> >>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all >>>> other ideas >>>> >>>>>> provided on this list, the provider waives all patent and other >>>> intellectual >>>> >>>>>> property rights inherent in such information. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> -- >>>> >>>>> Anatole Tresch >>>> >>>>> Java Lead Engineer, JSR Spec Lead >>>> >>>>> Glärnischweg 10 >>>> >>>>> CH - 8620 Wetzikon >>>> >>>>> >>>> >>>>> Switzerland, Europe Zurich, GMT+1 >>>> >>>>> Twitter: @atsticks >>>> >>>>> Blogs: http://javaremarkables.blogspot.ch/ >>>> >>>>> Google: atsticks >>>> >>>>> Mobile +41-76 344 62 79 >>>> >>>> >>>> >>>> >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Anatole Tresch >>>> >> Java Lead Engineer, JSR Spec Lead >>>> >> Glärnischweg 10 >>>> >> CH - 8620 Wetzikon >>>> >> >>>> >> Switzerland, Europe Zurich, GMT+1 >>>> >> Twitter: @atsticks >>>> >> Blogs: http://javaremarkables.blogspot.ch/ >>>> >> Google: atsticks >>>> >> Mobile +41-76 344 62 79 >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > cdi-dev mailing list >>>> > cdi-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> > >>>> > Note that for all code provided on this list, the provider licenses >>>> the code >>>> > under the Apache License, Version 2 >>>> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >>>> ideas >>>> > provided on this list, the provider waives all patent and other >>>> intellectual >>>> > property rights inherent in such information. >>>> >>> >>> >>> >>> -- >>> *Anatole Tresch* >>> Java Lead Engineer, JSR Spec Lead >>> Glärnischweg 10 >>> CH - 8620 Wetzikon >>> >>> *Switzerland, Europe Zurich, GMT+1* >>> *Twitter: @atsticks* >>> *Blogs: **http://javaremarkables.blogspot.ch/ >>> <http://javaremarkables.blogspot.ch/>* >>> >>> *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >>> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site <http://www.antoniogoncalves.org> | Twitter > <http://twitter.com/agoncal> | LinkedIn > <http://www.linkedin.com/in/agoncal> | Pluralsight > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris > JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr> >