2015-10-19 9:17 GMT+02:00 Martin Kouba <mkouba@redhat.com>:

Dne 19.10.2015 v 08:44 Romain Manni-Bucau napsal(a):

would be super cool to not have to write an extension for that, cant we
use applicationscope init event or an prioritized event at this moment -
avoiding the spi is a must for end user usage IMO?

Not possible, it's too late. ApplicationScoped init event is fired after the deployment validation. Well, maybe it's not that explicitly defined but it wouldn't make much sense to fire it before validation as you have to resolve a set of validated observers, usually declared on validated beans.

we speak about cdi 2.0 so all is possible, i think all places would work but to be used it should respect the lightweight programmatic model of business beans of CDI. The SPI is always a "let's do differently" - was only my point.

Side note: since you add beans you should do it before the validation as well but means you cant skip Extension which is a pain :(

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-10-19 8:40 GMT+02:00 Martin Kouba <mkouba@redhat.com
<mailto:mkouba@redhat.com>>:

In CDI 2.0 we propose to support lambdas in the bean builder API -
currently available as a weld experimental feature in AfterBeanDiscovery
and Weld SE - see also [1] and [2].

For observers a similar builder might be useful.

Martin

[1]
http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api

[2]
https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java

Dne 17.10.2015 v 13:51 Sven Linstaedt napsal(a):
> Just one question: Who is on charge and is able of managing this
> unmanaged instances, e.g. lifecycle, serialization, concurrency (e.g.
> when dealing with closures)?
>
> Functional programming and DI seem to be somehow disjunct in this case.
> E.g. manually setting up observers seem to better fit extension than
> normal application code.
>
> On the other side, specifying producer methods or fields, that are
> injectable and return lambda expressions seems to be a no brainier for
> CDI, is not it? As long as they are not scoped in a serializable context.
>
> Have a nice weekend
> Sven
>
> -- sent by phone
>
> Am 17.10.2015 um 11:06 schrieb David Blevins <david.blevins@gmail.com <mailto:david.blevins@gmail.com>
> <mailto:david.blevins@gmail.com <mailto:david.blevins@gmail.com>>>:

>
>> In brainstorming mode about fun that could be made possible with
Java
>> 8 and Java EE.
>>
>> Question in my mind is: is there some way we could make it possible
>> for Lambdas or Method Refs to be CDI beans?
>>
>> It goes against the grain obviously as CDI creation is very much a
>> “Don’t call us, we’ll call you” kind of thing. The VM dynamically
>> creates a wrapper object around the Lambda or method reference
and it
>> implements the given interface.
>>
>> To make it work, there would need to be some non-producer method way
>> of saying “put this thing in the context with these qualifiers”.
>>
>> Imagine a method somewhere that would allow you to:
>>
>> public <T> void addObserver(java.util.function.Consumer<T>
>> observer, Annotation... qualifiers);
>>
>>
>> Then you could take advantage as follows:
>>
>> final List<URI> uris = new ArrayList<>();
>> // @Observes URI
>> addObserver((Consumer<URI>) uris::add);
>>
>> // @Observes Thread
>> addObserver(Runtime.getRuntime()::addShutdownHook);
>>
>> // @Observes Runnable
>> addObserver((Consumer<Runnable>)
>> Executors.newFixedThreadPool(3)::submit);
>>
>> // @Observes URI
>> addObserver((Consumer<URI>) System.out::println, new
>> AnnotationLiteral<Fine>() {
>> });
>>
>> // @Observes Handler
>> final Logger logger = Logger.getLogger("somewhere");
>> addObserver(logger::addHandler); // add handlers via event
>>
>> // @Observes @Fine String
>> addObserver((Consumer<String>) logger::fine, new
>> AnnotationLiteral<Fine>() {});
>> }
>>
>>
>>
>> -David
>>
>>
>>
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
<mailto: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.
>
>
> _______________________________________________
> 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.
>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
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.

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic