[cdi-dev] With the end of Java Config...
John D. Ament
john.d.ament at gmail.com
Sun Sep 7 15:28:17 EDT 2014
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 at 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 at 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 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.
>>
>>
>>
>> _______________________________________________
>> 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 <%2B41-76%20344%2062%2079>*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140907/3c2e1330/attachment-0001.html
More information about the cdi-dev
mailing list