Re: [cdi-dev] Async events. We need ideas to improve CDI-499
by Werner Keil
Mark,
What do you mean by @Event?
CDI contains the Event interface, no annotation.
Are you proposing a new annotation or was it a typo?
So did you mean
@Async
private Event<UserLoggedIn> userLoggedInEventSource;
below?
Werner
On Tue, Feb 10, 2015 at 10:31 AM, <cdi-dev-request(a)lists.jboss.org> 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: Async events. We need ideas to improve CDI-499 (Mark Struberg)
> 2. Re: Async events. We need ideas to improve CDI-499 (Mark Struberg)
> 3. Re: Async events. We need ideas to improve CDI-499
> (Jozef Hartinger)
> 4. Re: Async events. We need ideas to improve CDI-499
> (Jozef Hartinger)
> 5. Re: Async events. We need ideas to improve CDI-499
> (Jozef Hartinger)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 10 Feb 2015 07:53:30 +0000 (UTC)
> From: Mark Struberg <struberg(a)yahoo.de>
> Subject: Re: [cdi-dev] Async events. We need ideas to improve CDI-499
> To: Jos? Paumard <jose.paumard(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <1995246191.1465726.1423554810674.JavaMail.yahoo(a)mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Jos?!
>
> Backward compatibility is perfectly fine with both approaches. People can
> use BeanManager#fire() instead of the newly proposed
> BeanManager#fireAsync().
>
>
> My point is that many people will simply not be able to use fireAsync()
> because as a framework developer you really need to code defensive. Without
> an explicit opt-in on observer side fireAsync() can basically only be used
> in situations where you _exactly_ know all your observers...
>
> An own @Async annotation would also be nice as it could not only be used
> at @Observes but also for @Event
>
> @Inject
> @Async
>
> @Event
>
> private Event<UserLoggedIn> userLoggedInEventSource;
>
>
> The benefit of an own @Async annotation over extending e.g. the @Event
> annotation is that it would be perfectly backward compatible. This code
> would also run on CDI-1.0 .. 1.2 containers (as all annotations which are
> not available on the classpath will simply be ignored by the JVM.
>
> LieGrue,
> strub
>
>
>
> On Tuesday, 10 February 2015, 8:41, Jos? Paumard <jose.paumard(a)gmail.com>
> wrote:
> >Mark,
> >It vas never been in the mind of anyone to modify the way things work
> currently. Keeping the backward compatibility is a prerequisite to any kind
> of modification or improvment added to the spec. This has already been said
> and written several times.
> >Jos?
> >Le 10 f?vr. 2015 07:37, "Mark Struberg" <struberg(a)yahoo.de> a ?crit :
> >
> >Good morning!
> >>
> >>
> >>Folks, please think a bit further.
> >>
> >>
> >>I'll give you a practical example. What should a developer do first? Eat
> their own dog food...
> >>
> >>Where does this apply to us? Means where do _we_ use CDI events? Right,
> in CDI Extensions.
> >>
> >>So ask yourself a simple question: if we like to leverage async events
> in CDI extensions then how could we do that? Your suggestion was to just
> use fireAsync instead of fire, right?
> >>
> >>Now imagine what would happen if we would do that... I'd say most real
> world apps would go BOOOOMMMMM and not even finish the start. Simply
> because most CDI extensions are not built to be executed in parallel. Just
> look at Extensions who collect information about classes in @Observes
> ProcessAnnotatedType. Most of the time they collect this in a
> non-concurrent Set or List
> >>
> >>private final Collection<AnnotatedType<?>> messageBundleTypes = new
> HashSet<AnnotatedType<?>>();
> >>
> >>
> >>If you fire the ProcessAnnotatedType event in parallel then you will
> blow up. And this was just ONE example. There are tons of other CDI
> Extension Events which would have the same result if switched to fireAsync.
> >>
> >>
> >>Now think about what would happen IF we would have an @Async on the
> observer?
> >>
> >>All would work. Old extensions still will get triggered in the same
> thread, but extensions with @Async would leverage parallel behaviour.
> >>
> >>
> >>I hope this practical sample makes it more clear why I think that most
> of the time we cannot simply switch to fireAsync if there is old code
> around which is not under your full control.
> >>
> >>
> >>LieGrue,
> >>strub
> >>
> >>
> >>
> >>
> >>
> >>
> >>> On Monday, 9 February 2015, 20:56, Romain Manni-Bucau <
> rmannibucau(a)gmail.com> wrote:
> >>> > I guess 2 is not a real need - and at least not why people voted for
> >>> this feature. Difference between fireAsync and @Async is who decides
> >>> to be asynchronous. Caller (fire) should clearly be able IMO - with
> >>> all the warning we can put in the spec to say it should be done with
> >>> compatible scopes. The second one is less important for me cause you
> >>> can already do it with concurrency utilities (ee one or not) pretty
> >>> easily.
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau
> >>> http://www.tomitribe.com
> >>> http://rmannibucau.wordpress.com
> >>> https://github.com/rmannibucau
> >>>
> >>>
> >>> 2015-02-09 20:33 GMT+01:00 Mark Struberg <struberg(a)yahoo.de>:
> >>>> Btw, did we already cover the 'fireAndForget' vs
> >>> 'fireAndWait' use cases?
> >>>>
> >>>> 1. fireAndForget: this is basically what you get today if you use
> >>> @javax.ejb.Asynchronous on an @Observer method
> >>>>
> >>>> 2.) fireAndWait: call all observers in a new thread and only return
> after
> >>> all observer methods did finish.
> >>>>
> >>>>
> >>>>
> >>>> Did we already agree on one of the 2 modi? If not, do we like to
> support
> >>> both? And if so, how to tell the CDI container which of the 2 modes to
> use for
> >>> each observer?
> >>>>
> >>>>
> >>>> If you answer the last question with yes then we might need some
> >>> annotation/additional info on the observer method anyway. And then we
> are back
> >>> on our @Async annotation on the observer method...
> >>>>
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>> On Monday, 9 February 2015, 18:43, Romain Manni-Bucau
> >>> <rmannibucau(a)gmail.com> wrote:
> >>>>> Guys I'm not sure to fully get the jira description now. Can you try
> >>>>> to rephrase it a bit?
> >>>>>
> >>>>> Here what I see:
> >>>>>
> >>>>> 1) fireAsync (+1) is clear
> >>>>> 2) (part I dont fully get) asyncSupported: is it mandatory? If yes I
> >>>>> think this API is not usable (=user friendly) and I would just
> suggest
> >>>>> it is on by default and to remove this flag
> >>>>>
> >>>>>
> >>>>> Can it break apps? Yes as mentionned by Mark. Will it break apps? No
> >>>>> since it is not yet used and this is surely what we want. I fully
> >>>>> understand all the mentionned pitfalls - but let me say
> @RequestScoped
> >>>>> is by definition as broken as this today since you can't associate
> >>> it
> >>>>> with a request for the exact same reason. What I mean is: if you
> >>>>> choose async then you assume it so I think we shouldn't protect the
> >>>>> user from pitfalls then...in particular since we can't protect him
> >>>>> from other as vicious issues.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Romain Manni-Bucau
> >>>>> @rmannibucau
> >>>>> http://www.tomitribe.com
> >>>>> http://rmannibucau.wordpress.com
> >>>>> https://github.com/rmannibucau
> >>>>>
> >>>>>
> >>>>> 2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand
> >>> <antoine(a)sabot-durand.net>:
> >>>>>> Mark I understand your concern, now can you understand the one we
> >>> discussed about the fact of having to enable async at both ends is a
> source of
> >>> confusion for end users and will give a bad perception of the spec.
> >>>>>>
> >>>>>> So could we figure something user friendly to enable async event?
> >>>>>>
> >>>>>> Antoine
> >>>>>>
> >>>>>>
> >>>>>>> Le 9 f?vr. 2015 ? 12:00, Mark Struberg
> >>> <struberg(a)yahoo.de> a ?crit :
> >>>>>>>
> >>>>>>> But that might defeat pluggabilgity. Basically no framework can
> >>> use fireAsync in that case.
> >>>>>>>
> >>>>>>> Imagine a UserLoggedIn event. For most observers it is
> >>> perfectly fine to observe this in a new thread. But some might need to
> access
> >>> the session -> boom. Which means that all frameworks have to fall back
> to the
> >>> 'safe' fire() instead of fireAsync()...
> >>>>>>>
> >>>>>>> That will leave us half-broken as it totally defeats the usage
> >>> of this cool feature...
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand
> >>> <antoine(a)sabot-durand.net> wrote:
> >>>>>>>>> Mark,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> During last meeting we didn?t say there wasn?t use case
> >>> that would break
> >>>>>>>> existing observer, we said that since we keep the current
> >>> fire() method there is
> >>>>>>>> backward compatibility. User trying to send fireAsync() and
> >>> experiencing error
> >>>>>>>> with legacy observer will have to fall back to fire().
> >>>>>>>>
> >>>>>>>> Antoine
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg
> >>> <struberg(a)yahoo.de> a ?crit :
> >>>>>>>>>
> >>>>>>>>> Hi Jozef, here we go!
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 1.) accessing @RequestScoped beans in your Observer
> >>>>>>>>>
> >>>>>>>>> 2.) accessing @SessionScoped beans in your Observer
> >>>>>>>>> 3.) accessing/relying on any transactional behaviour.
> >>> This is really a
> >>>>>>>> boomer. Basically you break transactions that way.
> >>>>>>>>>
> >>>>>>>>> 4.) accessing @TransactionScoped beans in your Observer
> >>>>>>>>>
> >>>>>>>>> 5.) access/relying on any ThreadLocal in your Observer
> >>>>>>>>> 6.) accessing attached entities in your Observers (they
> >>> must only get
> >>>>>>>> accessed from a very single Thread according to the JPA
> >>> spec)
> >>>>>>>>> 7.) using an EntityManager in a parallel thread might
> >>> give you unexpected
> >>>>>>>> results.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> There might be quite a few more. E.g. we need to
> >>> specify that EJBs and
> >>>>>>>> other EE features need to work in such a new Thread, etc
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> LieGrue,
> >>>>>>>>> strub
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger
> >>>>>>>> <jharting(a)redhat.com> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> We should enumerate all the arguments supporting
> >>> async flag on an
> >>>>>>>> observer. So far I have only seen one:
> >>>>>>>>>>
> >>>>>>>>>> - an observer accessing @RequestScoped state would
> >>> no longer be able
> >>>>>>>>> to do so since it would be run in a worker thread
> >>>>>>>>>>
> >>>>>>>>>> I am eager to hear more arguments as this single
> >>> one may not be
> >>>>>>>>> enough to justify the observer-async-flag design
> >>> decision.
> >>>>>>>>>>
> >>>>>>>>>> Remember that introducing fireAsync() itself does
> >>> not break any
> >>>>>>>>> existing application because existing applications
> >>> are using fire().
> >>>>>>>>> It's when an existing application / library is
> >>> modified to use
> >>>>>>>>> fireAsync() when the problem may occur. Such change
> >>> should not be
> >>>>>>>>> done blindly. As with any other change, an author
> >>> should consider
> >>>>>>>>> possible consequences of the change. Clearly
> >>> documenting the fact
> >>>>>>>>> that fireAsync() processing is done in a different
> >>> thread with a
> >>>>>>>>> different @RequestScoped state may be sufficient.
> >>>>>>>>>>
> >>>>>>>>>> Jozef
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi all,
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> https://issues.jboss.org/browse/CDI-499 comes
> >>> after a lot of
> >>>>>>>> discussion about async events.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I think the solution exposed here is quite
> >>> satisfying, yet the idea
> >>>>>>>> to need to activate async behaviour on the observer side
> >>> doesn?t please a lot of
> >>>>>>>> us. It?ll be confusing for users to have to activate async
> >>> from the firing end
> >>>>>>>> and consuming end to see it work :-(.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I?d like to see alternative proposal to have
> >>> this new feature as
> >>>>>>>> user friendly as possible and keep the retro-compatibility
> >>> aspect. We should
> >>>>>>>> find a better solution on our next meeting on wednesday.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Antoine
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>> 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.
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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.
>
> End of cdi-dev Digest, Vol 51, Issue 21
> ***************************************
>
9 years, 2 months
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-504:
-----------------------------------
-1 for including this now. We will simply just end up with a half backed solution.
I'd suggest to look at the Apache Tamaya project which is basically a spun out and minimalistic version of the DeltaSpike configuration system plus a few nice additions. The goal is to get this ready to be proposed as JSR in a few months. Tamaya does mainly target SE, so it's pure java without DI. But the DI part can easily bet put on top of it. It actually doesn't matter if that would be part of a config JSR or CDI-2.
I just like to avoid a situation like we had with @ManagedBean. 3 annotations in 3 different packages and none of them is really working in practice...
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
Re: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI annotation like
by Werner Keil
If DeltaSpike Configuration already covered everything there would have
been no need for Tamaya;-)
On Fri, Feb 6, 2015 at 1:23 PM, arjan tijms <arjan.tijms(a)gmail.com> wrote:
> Hi,
>
> On Fri, Feb 6, 2015 at 11:22 AM, Werner Keil <werner.keil(a)gmail.com>
> wrote:
> > but so far JCP officials first and foremost
> > Oracle saw either no need or no resources to do this.
>
> I remember some other issues being on the table, like Java SE vs Java
> EE and "configuring the runtime" vs "injecting/providing values to the
> app".
>
> DeltaSpike Configuration is really great, but it's a value provider.
> It doesn't let you swap out or overlay deployment descriptors etc.
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> > Apache Tamaya was a logical result. If that could become a blue-print or
> > initial contribution of a future JSR, let's see, maybe for EE 9. It uses
> > other Apache projects like DeltaSpike where applicable, but may also
> define
> > such annotations and types of its own, so I suggest you also share your
> > ideas on a Tamaya mailing list or JIRA:
> > http://tamaya.incubator.apache.org/index.html
> >
> > On Fri, Feb 6, 2015 at 11:02 AM, <cdi-dev-request(a)lists.jboss.org>
> 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. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
> >> @ConfigProperty from deltapsike (James Strachan (JIRA))
> >> 2. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
> >> @ConfigProperty from deltapsike (Martin Kouba (JIRA))
> >> 3. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
> >> @ConfigProperty from deltapsike (John Ament (JIRA))
> >> 4. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
> >> @ConfigProperty from deltapsike (James Strachan (JIRA))
> >> 5. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
> >> @ConfigProperty from deltapsike (James Strachan (JIRA))
> >> 6. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
> >> @ConfigProperty from deltapsike (James Strachan (JIRA))
> >> 7. [JBoss JIRA] (CDI-504) have a standard CDI annotation like
> >> @ConfigProperty from deltapsike (Antoine Sabot-Durand (JIRA))
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Thu, 5 Feb 2015 05:01:49 -0500 (EST)
> >> From: "James Strachan (JIRA)" <issues(a)jboss.org>
> >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> >> annotation like @ConfigProperty from deltapsike
> >> To: cdi-dev(a)lists.jboss.org
> >> Message-ID:
> >> <JIRA.12562481.1423130482000.44616.1423130509034(a)Atlassian.JIRA
> >
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >> James Strachan created CDI-504:
> >> ----------------------------------
> >>
> >> Summary: have a standard CDI annotation like
> @ConfigProperty
> >> from deltapsike
> >> Key: CDI-504
> >> URL: https://issues.jboss.org/browse/CDI-504
> >> Project: CDI Specification Issues
> >> Issue Type: Feature Request
> >> Reporter: James Strachan
> >>
> >>
> >> Docker and containerisation is the new hotness; in the docker world
> images
> >> are static and the main way of injecting configuration is via
> environment
> >> variables - so that the same image can be reused but configured at run
> time
> >> with different configuration values. (Changing configuration files
> requires
> >> either different images to be created or using custom volumes which is
> less
> >> ideal in a containerized world).
> >>
> >> So IMHO CDI should provide a simple, natural way to allow environment
> >> variables (or system properties) to be easily injected via CDI.
> >>
> >> Delta Spike as a @ConfigProperty annotation which works very nicely
> >> http://deltaspike.apache.org/documentation/configuration.html
> >>
> >> you can specify a name, default value and use it on an @Inject to
> provide
> >> a value from env vars, system properties or provide a default.
> >>
> >> Given how core and useful this is - it feels like it should be part of
> the
> >> CDI specification; its one simple annotation.
> >>
> >> Currently deltaspike provides a way to configure different sources and
> >> whatnot which is cool; I'd be happy if CDI just had a simpler annotation
> >> which was only bound to env vars / system properties.
> >>
> >> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> >>
> >> There could be debate on whether env vars or system properties should
> win
> >> if the same name is used for both; in a dockerized world I'd prefer env
> vars
> >> to win but folks can always tinker with their run command to make sure
> they
> >> pass in env vars as system properties to work around this I guess.
> >>
> >>
> >>
> >> --
> >> This message was sent by Atlassian JIRA
> >> (v6.3.11#6341)
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Thu, 5 Feb 2015 10:30:50 -0500 (EST)
> >> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> >> annotation like @ConfigProperty from deltapsike
> >> To: cdi-dev(a)lists.jboss.org
> >> Message-ID:
> >> <JIRA.12562481.1423130482000.45712.1423150250888(a)Atlassian.JIRA
> >
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >>
> >> [
> >>
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
> >> ]
> >>
> >> Martin Kouba commented on CDI-504:
> >> ----------------------------------
> >>
> >> What's wrong with {{java.lang.System.getProperty()}} and
> >> {{java.lang.System.getenv()}}? I mean the main advantage of DS
> Configuration
> >> is IMO the resolution mechanism and the ability to extend the set of
> >> {{ConfigSource}} s. If you only need system properties and env
> variables a
> >> simple producer method and qualifier (or even a simple util method)
> would be
> >> sufficient. In other words I see no reason to standardize this.
> >>
> >> > have a standard CDI annotation like @ConfigProperty from deltapsike
> >> > -------------------------------------------------------------------
> >> >
> >> > Key: CDI-504
> >> > URL: https://issues.jboss.org/browse/CDI-504
> >> > Project: CDI Specification Issues
> >> > Issue Type: Feature Request
> >> > Reporter: James Strachan
> >> >
> >> > Docker and containerisation is the new hotness; in the docker world
> >> > images are static and the main way of injecting configuration is via
> >> > environment variables - so that the same image can be reused but
> configured
> >> > at run time with different configuration values. (Changing
> configuration
> >> > files requires either different images to be created or using custom
> volumes
> >> > which is less ideal in a containerized world).
> >> > So IMHO CDI should provide a simple, natural way to allow environment
> >> > variables (or system properties) to be easily injected via CDI.
> >> > Delta Spike as a @ConfigProperty annotation which works very nicely
> >> > http://deltaspike.apache.org/documentation/configuration.html
> >> > you can specify a name, default value and use it on an @Inject to
> >> > provide a value from env vars, system properties or provide a default.
> >> > Given how core and useful this is - it feels like it should be part of
> >> > the CDI specification; its one simple annotation.
> >> > Currently deltaspike provides a way to configure different sources and
> >> > whatnot which is cool; I'd be happy if CDI just had a simpler
> annotation
> >> > which was only bound to env vars / system properties.
> >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> >> > There could be debate on whether env vars or system properties should
> >> > win if the same name is used for both; in a dockerized world I'd
> prefer env
> >> > vars to win but folks can always tinker with their run command to
> make sure
> >> > they pass in env vars as system properties to work around this I
> guess.
> >>
> >>
> >>
> >> --
> >> This message was sent by Atlassian JIRA
> >> (v6.3.11#6341)
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 3
> >> Date: Thu, 5 Feb 2015 10:34:49 -0500 (EST)
> >> From: "John Ament (JIRA)" <issues(a)jboss.org>
> >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> >> annotation like @ConfigProperty from deltapsike
> >> To: cdi-dev(a)lists.jboss.org
> >> Message-ID:
> >> <JIRA.12562481.1423130482000.45725.1423150489341(a)Atlassian.JIRA
> >
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >>
> >> [
> >>
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
> >> ]
> >>
> >> John Ament commented on CDI-504:
> >> --------------------------------
> >>
> >> A separate config JSR has been proposed previously to address this.
> They
> >> want to see more options before trying to standardize it.
> >>
> >> > have a standard CDI annotation like @ConfigProperty from deltapsike
> >> > -------------------------------------------------------------------
> >> >
> >> > Key: CDI-504
> >> > URL: https://issues.jboss.org/browse/CDI-504
> >> > Project: CDI Specification Issues
> >> > Issue Type: Feature Request
> >> > Reporter: James Strachan
> >> >
> >> > Docker and containerisation is the new hotness; in the docker world
> >> > images are static and the main way of injecting configuration is via
> >> > environment variables - so that the same image can be reused but
> configured
> >> > at run time with different configuration values. (Changing
> configuration
> >> > files requires either different images to be created or using custom
> volumes
> >> > which is less ideal in a containerized world).
> >> > So IMHO CDI should provide a simple, natural way to allow environment
> >> > variables (or system properties) to be easily injected via CDI.
> >> > Delta Spike as a @ConfigProperty annotation which works very nicely
> >> > http://deltaspike.apache.org/documentation/configuration.html
> >> > you can specify a name, default value and use it on an @Inject to
> >> > provide a value from env vars, system properties or provide a default.
> >> > Given how core and useful this is - it feels like it should be part of
> >> > the CDI specification; its one simple annotation.
> >> > Currently deltaspike provides a way to configure different sources and
> >> > whatnot which is cool; I'd be happy if CDI just had a simpler
> annotation
> >> > which was only bound to env vars / system properties.
> >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> >> > There could be debate on whether env vars or system properties should
> >> > win if the same name is used for both; in a dockerized world I'd
> prefer env
> >> > vars to win but folks can always tinker with their run command to
> make sure
> >> > they pass in env vars as system properties to work around this I
> guess.
> >>
> >>
> >>
> >> --
> >> This message was sent by Atlassian JIRA
> >> (v6.3.11#6341)
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 4
> >> Date: Thu, 5 Feb 2015 10:39:49 -0500 (EST)
> >> From: "James Strachan (JIRA)" <issues(a)jboss.org>
> >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> >> annotation like @ConfigProperty from deltapsike
> >> To: cdi-dev(a)lists.jboss.org
> >> Message-ID:
> >> <JIRA.12562481.1423130482000.45741.1423150789541(a)Atlassian.JIRA
> >
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >>
> >> [
> >>
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
> >> ]
> >>
> >> James Strachan commented on CDI-504:
> >> ------------------------------------
> >>
> >> @Resource is supported - injecting values from JNDI. I don't see why
> >> injecting values (with a default value) from the environment isn't also
> >> supported too. There's a Java API for JNDI too so folks could look
> stuff up
> >> in JNDI by hand and do the type conversions - but we've injection for
> those
> >> values.
> >>
> >> Its also much cleaner code and can easily deal generically with type
> >> conversion to long/double/float/date etc.
> >>
> >> Compare:
> >> {code}
> >> @Inject Foo(int bar, ...) {
> >> bar = System.getenv("FOO");
> >> if (bar == null) {
> >> bar = "someDefault";
> >> }
> >> // now convert to a String with error handling....
> >> }
> >> {code}
> >> to just:
> >> {code}
> >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
> >> }
> >> {code}
> >>
> >> Also by using an annotation it means its very easy to generate
> >> documentation and tooling. (e.g. using APT you can know what all the
> >> environment variables are used by CDI; either to report on demand or to
> >> generate user documentation).
> >>
> >>
> >>
> >> > have a standard CDI annotation like @ConfigProperty from deltapsike
> >> > -------------------------------------------------------------------
> >> >
> >> > Key: CDI-504
> >> > URL: https://issues.jboss.org/browse/CDI-504
> >> > Project: CDI Specification Issues
> >> > Issue Type: Feature Request
> >> > Reporter: James Strachan
> >> >
> >> > Docker and containerisation is the new hotness; in the docker world
> >> > images are static and the main way of injecting configuration is via
> >> > environment variables - so that the same image can be reused but
> configured
> >> > at run time with different configuration values. (Changing
> configuration
> >> > files requires either different images to be created or using custom
> volumes
> >> > which is less ideal in a containerized world).
> >> > So IMHO CDI should provide a simple, natural way to allow environment
> >> > variables (or system properties) to be easily injected via CDI.
> >> > Delta Spike as a @ConfigProperty annotation which works very nicely
> >> > http://deltaspike.apache.org/documentation/configuration.html
> >> > you can specify a name, default value and use it on an @Inject to
> >> > provide a value from env vars, system properties or provide a default.
> >> > Given how core and useful this is - it feels like it should be part of
> >> > the CDI specification; its one simple annotation.
> >> > Currently deltaspike provides a way to configure different sources and
> >> > whatnot which is cool; I'd be happy if CDI just had a simpler
> annotation
> >> > which was only bound to env vars / system properties.
> >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> >> > There could be debate on whether env vars or system properties should
> >> > win if the same name is used for both; in a dockerized world I'd
> prefer env
> >> > vars to win but folks can always tinker with their run command to
> make sure
> >> > they pass in env vars as system properties to work around this I
> guess.
> >>
> >>
> >>
> >> --
> >> This message was sent by Atlassian JIRA
> >> (v6.3.11#6341)
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 5
> >> Date: Thu, 5 Feb 2015 10:49:49 -0500 (EST)
> >> From: "James Strachan (JIRA)" <issues(a)jboss.org>
> >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> >> annotation like @ConfigProperty from deltapsike
> >> To: cdi-dev(a)lists.jboss.org
> >> Message-ID:
> >> <JIRA.12562481.1423130482000.45763.1423151389408(a)Atlassian.JIRA
> >
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >>
> >> [
> >>
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
> >> ]
> >>
> >> James Strachan edited comment on CDI-504 at 2/5/15 10:49 AM:
> >> -------------------------------------------------------------
> >>
> >> @Resource is supported - injecting values from JNDI. I don't see why
> >> injecting values (with a default value) from the environment isn't also
> >> supported too. There's a Java API for JNDI too so folks could look
> stuff up
> >> in JNDI by hand and do the type conversions - but we've injection for
> those
> >> values.
> >>
> >> Its also much cleaner code and can easily deal generically with type
> >> conversion to long/double/float/date etc.
> >>
> >> Compare:
> >> {code}
> >> @Inject Foo(int bar, ...) {
> >> bar = System.getenv("FOO");
> >> if (bar == null) {
> >> bar = "someDefault";
> >> }
> >> // now convert the String to an int with nice error handling and
> >> reporting....
> >> }
> >> {code}
> >> to just:
> >> {code}
> >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
> >> }
> >> {code}
> >>
> >> Also by using an annotation it means its very easy to generate
> >> documentation and tooling. (e.g. using APT you can know what all the
> >> environment variables are used by CDI; either to report on demand or to
> >> generate user documentation).
> >>
> >>
> >>
> >>
> >> was (Author: jastrachan):
> >> @Resource is supported - injecting values from JNDI. I don't see why
> >> injecting values (with a default value) from the environment isn't also
> >> supported too. There's a Java API for JNDI too so folks could look
> stuff up
> >> in JNDI by hand and do the type conversions - but we've injection for
> those
> >> values.
> >>
> >> Its also much cleaner code and can easily deal generically with type
> >> conversion to long/double/float/date etc.
> >>
> >> Compare:
> >> {code}
> >> @Inject Foo(int bar, ...) {
> >> bar = System.getenv("FOO");
> >> if (bar == null) {
> >> bar = "someDefault";
> >> }
> >> // now convert to a String with error handling....
> >> }
> >> {code}
> >> to just:
> >> {code}
> >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
> >> }
> >> {code}
> >>
> >> Also by using an annotation it means its very easy to generate
> >> documentation and tooling. (e.g. using APT you can know what all the
> >> environment variables are used by CDI; either to report on demand or to
> >> generate user documentation).
> >>
> >>
> >>
> >> > have a standard CDI annotation like @ConfigProperty from deltapsike
> >> > -------------------------------------------------------------------
> >> >
> >> > Key: CDI-504
> >> > URL: https://issues.jboss.org/browse/CDI-504
> >> > Project: CDI Specification Issues
> >> > Issue Type: Feature Request
> >> > Reporter: James Strachan
> >> >
> >> > Docker and containerisation is the new hotness; in the docker world
> >> > images are static and the main way of injecting configuration is via
> >> > environment variables - so that the same image can be reused but
> configured
> >> > at run time with different configuration values. (Changing
> configuration
> >> > files requires either different images to be created or using custom
> volumes
> >> > which is less ideal in a containerized world).
> >> > So IMHO CDI should provide a simple, natural way to allow environment
> >> > variables (or system properties) to be easily injected via CDI.
> >> > Delta Spike as a @ConfigProperty annotation which works very nicely
> >> > http://deltaspike.apache.org/documentation/configuration.html
> >> > you can specify a name, default value and use it on an @Inject to
> >> > provide a value from env vars, system properties or provide a default.
> >> > Given how core and useful this is - it feels like it should be part of
> >> > the CDI specification; its one simple annotation.
> >> > Currently deltaspike provides a way to configure different sources and
> >> > whatnot which is cool; I'd be happy if CDI just had a simpler
> annotation
> >> > which was only bound to env vars / system properties.
> >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> >> > There could be debate on whether env vars or system properties should
> >> > win if the same name is used for both; in a dockerized world I'd
> prefer env
> >> > vars to win but folks can always tinker with their run command to
> make sure
> >> > they pass in env vars as system properties to work around this I
> guess.
> >>
> >>
> >>
> >> --
> >> This message was sent by Atlassian JIRA
> >> (v6.3.11#6341)
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 6
> >> Date: Thu, 5 Feb 2015 10:50:49 -0500 (EST)
> >> From: "James Strachan (JIRA)" <issues(a)jboss.org>
> >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> >> annotation like @ConfigProperty from deltapsike
> >> To: cdi-dev(a)lists.jboss.org
> >> Message-ID:
> >> <JIRA.12562481.1423130482000.45773.1423151449139(a)Atlassian.JIRA
> >
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >>
> >> [
> >>
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
> >> ]
> >>
> >> James Strachan edited comment on CDI-504 at 2/5/15 10:50 AM:
> >> -------------------------------------------------------------
> >>
> >> @Resource is supported - injecting values from JNDI. I don't see why
> >> injecting values (with a default value) from the environment isn't also
> >> supported too. There's a Java API for JNDI too so folks could look
> stuff up
> >> in JNDI by hand and do the type conversions - but we've injection for
> those
> >> values.
> >>
> >> Its also much cleaner code and can easily deal generically with type
> >> conversion to long/double/float/date etc.
> >>
> >> Compare:
> >> {code}
> >> int bar;
> >> @Inject Foo() {
> >> barText = System.getenv("FOO");
> >> if (barText == null) {
> >> barText = "someDefault";
> >> }
> >> // now convert the String to an int with nice error handling and
> >> reporting....
> >> bar = someConvertCode(barText);
> >> }
> >> {code}
> >> to just:
> >> {code}
> >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
> >> }
> >> {code}
> >>
> >> Note that in the second case, folks could use the constructor explicitly
> >> without being bound to environment variables too; much cleaner, more
> modular
> >> code.
> >>
> >> Also by using an annotation it means its very easy to generate
> >> documentation and tooling. (e.g. using APT you can know what all the
> >> environment variables are used by CDI; either to report on demand or to
> >> generate user documentation).
> >>
> >>
> >>
> >>
> >> was (Author: jastrachan):
> >> @Resource is supported - injecting values from JNDI. I don't see why
> >> injecting values (with a default value) from the environment isn't also
> >> supported too. There's a Java API for JNDI too so folks could look
> stuff up
> >> in JNDI by hand and do the type conversions - but we've injection for
> those
> >> values.
> >>
> >> Its also much cleaner code and can easily deal generically with type
> >> conversion to long/double/float/date etc.
> >>
> >> Compare:
> >> {code}
> >> @Inject Foo(int bar, ...) {
> >> bar = System.getenv("FOO");
> >> if (bar == null) {
> >> bar = "someDefault";
> >> }
> >> // now convert the String to an int with nice error handling and
> >> reporting....
> >> }
> >> {code}
> >> to just:
> >> {code}
> >> @Inject Foo(@Environment("FOO", "someDefault") int bar, ...) {
> >> }
> >> {code}
> >>
> >> Also by using an annotation it means its very easy to generate
> >> documentation and tooling. (e.g. using APT you can know what all the
> >> environment variables are used by CDI; either to report on demand or to
> >> generate user documentation).
> >>
> >>
> >>
> >> > have a standard CDI annotation like @ConfigProperty from deltapsike
> >> > -------------------------------------------------------------------
> >> >
> >> > Key: CDI-504
> >> > URL: https://issues.jboss.org/browse/CDI-504
> >> > Project: CDI Specification Issues
> >> > Issue Type: Feature Request
> >> > Reporter: James Strachan
> >> >
> >> > Docker and containerisation is the new hotness; in the docker world
> >> > images are static and the main way of injecting configuration is via
> >> > environment variables - so that the same image can be reused but
> configured
> >> > at run time with different configuration values. (Changing
> configuration
> >> > files requires either different images to be created or using custom
> volumes
> >> > which is less ideal in a containerized world).
> >> > So IMHO CDI should provide a simple, natural way to allow environment
> >> > variables (or system properties) to be easily injected via CDI.
> >> > Delta Spike as a @ConfigProperty annotation which works very nicely
> >> > http://deltaspike.apache.org/documentation/configuration.html
> >> > you can specify a name, default value and use it on an @Inject to
> >> > provide a value from env vars, system properties or provide a default.
> >> > Given how core and useful this is - it feels like it should be part of
> >> > the CDI specification; its one simple annotation.
> >> > Currently deltaspike provides a way to configure different sources and
> >> > whatnot which is cool; I'd be happy if CDI just had a simpler
> annotation
> >> > which was only bound to env vars / system properties.
> >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> >> > There could be debate on whether env vars or system properties should
> >> > win if the same name is used for both; in a dockerized world I'd
> prefer env
> >> > vars to win but folks can always tinker with their run command to
> make sure
> >> > they pass in env vars as system properties to work around this I
> guess.
> >>
> >>
> >>
> >> --
> >> This message was sent by Atlassian JIRA
> >> (v6.3.11#6341)
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 7
> >> Date: Fri, 6 Feb 2015 05:02:49 -0500 (EST)
> >> From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org>
> >> Subject: [cdi-dev] [JBoss JIRA] (CDI-504) have a standard CDI
> >> annotation like @ConfigProperty from deltapsike
> >> To: cdi-dev(a)lists.jboss.org
> >> Message-ID:
> >> <JIRA.12562481.1423130482000.47108.1423216969246(a)Atlassian.JIRA
> >
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >>
> >> [
> >>
> https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy...
> >> ]
> >>
> >> Antoine Sabot-Durand commented on CDI-504:
> >> ------------------------------------------
> >>
> >> James, I don't get what's the problem with using DeltaSpike config
> >> solution?
> >>
> >> > have a standard CDI annotation like @ConfigProperty from deltapsike
> >> > -------------------------------------------------------------------
> >> >
> >> > Key: CDI-504
> >> > URL: https://issues.jboss.org/browse/CDI-504
> >> > Project: CDI Specification Issues
> >> > Issue Type: Feature Request
> >> > Reporter: James Strachan
> >> >
> >> > Docker and containerisation is the new hotness; in the docker world
> >> > images are static and the main way of injecting configuration is via
> >> > environment variables - so that the same image can be reused but
> configured
> >> > at run time with different configuration values. (Changing
> configuration
> >> > files requires either different images to be created or using custom
> volumes
> >> > which is less ideal in a containerized world).
> >> > So IMHO CDI should provide a simple, natural way to allow environment
> >> > variables (or system properties) to be easily injected via CDI.
> >> > Delta Spike as a @ConfigProperty annotation which works very nicely
> >> > http://deltaspike.apache.org/documentation/configuration.html
> >> > you can specify a name, default value and use it on an @Inject to
> >> > provide a value from env vars, system properties or provide a default.
> >> > Given how core and useful this is - it feels like it should be part of
> >> > the CDI specification; its one simple annotation.
> >> > Currently deltaspike provides a way to configure different sources and
> >> > whatnot which is cool; I'd be happy if CDI just had a simpler
> annotation
> >> > which was only bound to env vars / system properties.
> >> > e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> >> > There could be debate on whether env vars or system properties should
> >> > win if the same name is used for both; in a dockerized world I'd
> prefer env
> >> > vars to win but folks can always tinker with their run command to
> make sure
> >> > they pass in env vars as system properties to work around this I
> guess.
> >>
> >>
> >>
> >> --
> >> This message was sent by Atlassian JIRA
> >> (v6.3.11#6341)
> >>
> >>
> >> ------------------------------
> >>
> >> _______________________________________________
> >> 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 51, Issue 9
> >> **************************************
> >
> >
> >
> > _______________________________________________
> > 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.
>
9 years, 2 months
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Arjan t (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Arjan t commented on CDI-504:
-----------------------------
{quote}So we open the door to include a converter SPI in the spec. I'm worried about the out of scope and anti-diet aspect of the spec here...{quote}
Maybe it's [high time to standardize Java EE converters?|http://arjan-tijms.omnifaces.org/2014/08/high-time-to-standar...] ;)
Not particularly looking forward to add CDI to the list I jotted down above.
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Werner Keil (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Werner Keil edited comment on CDI-504 at 2/9/15 6:01 AM:
---------------------------------------------------------
I agree with Antonio and without quoting everything I said on the mailing list here again (since it'll be mirrored there too;-) ) unless CDI 2 can manage a very good level of modularization, e.g. keeping such annotations in a separate "config" module, this should be postponed till a dedicated Config JSR may be welcome. We saw some very similar stuff with the rejected JSR 357. Aspects of it, especially authentication and authorization (which the 357 proposal brushed via OAuth, OpenID, etc.) are reborn with a number-twister in JSR 375 now. And while it may not contribute a lot, the Social Connector solution Agorava that emerged from Seam Social and ideas we had for 357 will certainly be inspirational to 375 and when the time comes may use some of these standards, too;-) Same with Tamaya and a possible future Config JSR.
See {{javax.decorator}} to make sense also for SE/desktop if CDI really defined such annotations they should be outside the {{javax.enterprise}} namespace at the very least.
was (Author: wernerkeil):
I agree with Antonio and without quoting everything I said on the mailing list here again (since it'll be mirrored there too;-) ) unless CDI 2 can manage a very good level of modularization, e.g. keeping such annotations in a separate "config" module, this should be postponed till a dedicated Config JSR may be welcome. We saw some very similar stuff with the rejected JSR 357. Aspects of it, especially authentication and authorization (which the 357 proposal brushed via OAuth, OpenID, etc.) are reborn with a number-twister in JSR 375 now. And while it may not contribute a lot, the Social Connector solution Agorava that emerged from Seam Social and ideas we had for 357 will certainly be inspirational to 375 and when the time comes may use some of these standards, too;-) Same with Tamaya and a possible future Config JSR.
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-504:
----------------------------------------
about 2 I think we should ensure this feature works for EE case - which is still the most common - so we shouldnt rely on these parameters. That said if they are here we should be able to use them as well so maybe let call SystemProperty just Property as a unified accessor.
about : point about not providing a spi is to avoid to do a quarter of the work only and break in 1 or 2 versions of EE spec. If there is for EE 9 a config spec then this would integrate smoothly with the spi you speak about - added for EE 9/CDI "2+1". if we add it now then we'll conflict (pretty sure)
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Werner Keil (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Werner Keil commented on CDI-504:
---------------------------------
I agree with Antonio and without quoting everything I said on the mailing list here again (since it'll be mirrored there too;-) ) unless CDI 2 can manage a very good level of modularization, e.g. keeping such annotations in a separate "config" module, this should be postponed till a dedicated Config JSR may be welcome. We saw some very similar stuff with the rejected JSR 357. Aspects of it, especially authentication and authorization (which the 357 proposal brushed via OAuth, OpenID, etc.) are reborn with a number-twister in JSR 375 now. And while it may not contribute a lot, the Social Connector solution Agorava that emerged from Seam Social and ideas we had for 357 will certainly be inspirational to 375 and when the time comes may use some of these standards, too;-) Same with Tamaya and a possible future Config JSR.
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-504:
------------------------------------------
I don't disagree with this idea but I have a few concerns or interrogations:
# As [~pmuir] stated Java have been including API for dealing with env and system property for a long time. So from my point of view here (and correct me if I'm wrong), is that the biggest interest of this feature would be typesafe injection of these config values and thus conversion from string to requested type. I understand that we would only provide a very limited set of supported type out of the box. But if we don't provide SPI to allow third party to add their own converter it could become source of frustration and it won't be in the "all is SPIable" spirit of CDI. So we open the door to include a converter SPI in the spec. I'm worried about the out of scope and anti-diet aspect of the spec here...
# In our discussion on Java SE boot in CDI-26 we have 2 {{init()}} method. One of them allows to boot the container with a parameter map {{init(Map<?,?> params)}}. What about these parameter from the config point of view? Are they only there to configure specific aspect of the container or could they be used also for configuration purpose?
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (CDI-504) have a standard CDI annotation like @ConfigProperty from deltapsike
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-504?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-504:
----------------------------------------
I don't agree Antonio, config JSR can be justified only if it brings more than wrappers so it will not match all small apps we can write so a light default would still be nice. That said I agree it can (should?) be done outside CDI itself
> have a standard CDI annotation like @ConfigProperty from deltapsike
> -------------------------------------------------------------------
>
> Key: CDI-504
> URL: https://issues.jboss.org/browse/CDI-504
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: James Strachan
>
> Docker and containerisation is the new hotness; in the docker world images are static and the main way of injecting configuration is via environment variables - so that the same image can be reused but configured at run time with different configuration values. (Changing configuration files requires either different images to be created or using custom volumes which is less ideal in a containerized world).
> So IMHO CDI should provide a simple, natural way to allow environment variables (or system properties) to be easily injected via CDI.
> Delta Spike as a @ConfigProperty annotation which works very nicely
> http://deltaspike.apache.org/documentation/configuration.html
> you can specify a name, default value and use it on an @Inject to provide a value from env vars, system properties or provide a default.
> Given how core and useful this is - it feels like it should be part of the CDI specification; its one simple annotation.
> Currently deltaspike provides a way to configure different sources and whatnot which is cool; I'd be happy if CDI just had a simpler annotation which was only bound to env vars / system properties.
> e.g. @EnvironmentProperty(name = "envvar", deafultValue="cheese")
> There could be debate on whether env vars or system properties should win if the same name is used for both; in a dockerized world I'd prefer env vars to win but folks can always tinker with their run command to make sure they pass in env vars as system properties to work around this I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months