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@gmail.com<mailto:atsticks@gmail.com>>
Datum: Friday 5 September 2014 21:22
An: Antonio Goncalves
<antonio.goncalves@gmail.com<mailto:antonio.goncalves@gmail.com>>
Cc: CDI-Dev <cdi-dev@lists.jboss.org<mailto:cdi-dev@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@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-go... |
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