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

Sun Sep 7 08:51:00 EDT 2014

P.s.: There's a new Servlet JSR (369) also proposed with supporters
everywhere from Google to Red Hat or Pivotal.

As I missed it a bit earlier, note, Servlet also has its own config
sub-system:
http://www.java4s.com/java-servlet-tutorials/example-of-servletconfig-in-java-servlet/

This interface was around ever since Servlet 1.0 I recall and it certainly
won't go away in 4.0 but a proper introduction of a (CDI or separate)
config mechanism would also have to say try offer a bit of improvement
there. That's what JSR 369 seems about after all;-)

Werner

On Sun, Sep 7, 2014 at 2:46 PM, Mark Struberg <struberg at yahoo.de> wrote:

> 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 at gmail.com>
> 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 at gmail.com>
> 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 at gmail.com> 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 at 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-profiles-devel-beta-qa-production-in-one-war
>
> 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 at lists.jboss.org> wrote:
>
> Send cdi-dev mailing list submissions to
>         cdi-dev at 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 at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at 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 at openknowledge.de>
> Subject: Re: [cdi-dev] With the end of Java Config...
> To: Anatole Tresch <atsticks at gmail.com>, Antonio Goncalves
>         <antonio.goncalves at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <D02FDD99.396B9%jens.schumann at openknowledge.de>
> 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/openknowledge-cdi-common/src/main/java/de/openknowledge/cdi/common/property
> [2]
> https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-common/src/test/java/de/openknowledge/cdi/common/property
>
> Von: Anatole Tresch <atsticks at gmail.com<mailto:atsticks at gmail.com>>
> Datum: Friday 5 September 2014 21:22
> An: Antonio Goncalves <antonio.goncalves at gmail.com<mailto:
> antonio.goncalves at gmail.com>>
> Cc: CDI-Dev <cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>>
> 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 at gmail.com
> <mailto:antonio.goncalves at 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 at sabot-durand.net<mailto:antoine at 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-dear.html
> ).
> 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 at lists.jboss.org<mailto:cdi-dev at 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 at lists.jboss.org<mailto:cdi-dev at 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/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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 at 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*
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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 at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140907/215e43d3/attachment-0001.html 