[cdi-dev] Today's meeting will be shorter and about SE
John D. Ament
john.d.ament at gmail.com
Thu Dec 18 07:26:02 EST 2014
I would recommend that at least some of these comments make their way into
the google doc. Things like BeanManager come from there.
I simply dropped a huge code snippet in here since there was no easy way to
include it in the doc.
On Thu, Dec 18, 2014 at 5:57 AM, José Paumard <jose.paumard at gmail.com>
wrote:
>
> Yes, there are good use cases for letting the user provide his own ES to
> have async calls executed in them. They are the same kind of use cases we
> have for CompletionStage.
>
> José
>
> 2014-12-18 10:18 GMT+01:00 Romain Manni-Bucau <rmannibucau at gmail.com>:
>>
>> 2014-12-18 9:58 GMT+01:00 José Paumard <jose.paumard at gmail.com>:
>> > From what we wrote about async events, ES can be submitted through the
>> > fireAsync call, following the patterns of CompletionStage. We can also
>> > submit a default ES while building a CDI container (a you wrote), and
>> if we
>> > dont the default ES will probably be the default ForkJoinPool.
>> >
>> > So we may have more than one ES, making things more complicated than the
>> > pattern you wrote. I think that having the user to close all the ESes
>> will
>> > lead to the same pattern again and again :
>> > for (ES es : cdi.getESes()) {
>> > myShutdown(es) ;
>> > }
>> >
>>
>> Sorry I missed something here: how can we get multiple ES? Basically
>> if CDI needs a ES behing the scene I expect it expose few config like
>> potential concurrent calls number etc...In such a case I'm not sure if
>> having multiple ES would be a good idea.
>>
>> > I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or
>> > cdi.awaitTermination(...) or whatever we call those methods, to
>> encapsulate
>> > this code. Seems cleaner to me. It might look like CDI is becoming an ES
>> > itself, but it's delegation, not inheritance.
>> >
>> >
>> >
>> > 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau <rmannibucau at gmail.com>:
>> >>
>> >> Why exposing them? When not simply exposing the executor service (in
>> >> "init" method).
>> >>
>> >> CDIContainer cdi =
>> CDIContainer.init(singletonMap(ExecutorService.class,
>> >> myEs));
>> >> // do something awesome
>> >> shutdownAsIwant(myEs);
>> >> cdi.close();
>> >>
>> >> Would avoid to have a lot of method several users will not care about.
>> >>
>> >> By default it would do a if (timeout <= 0 ||
>> >> !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r
>> >> : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); }
>> >> } } with timeout a property of the init map with a default in
>> >> CDIContainer (constant)
>> >>
>> >> wdyt?
>> >>
>> >>
>> >> Romain Manni-Bucau
>> >> @rmannibucau
>> >> http://www.tomitribe.com
>> >> http://rmannibucau.wordpress.com
>> >> https://github.com/rmannibucau
>> >>
>> >>
>> >> 2014-12-18 9:19 GMT+01:00 José Paumard <jose.paumard at gmail.com>:
>> >> > I think we need to think more about how to close the Container.
>> >> >
>> >> > We need to take into account the fact that there wil be async process
>> >> > running in ExecutorServices (SE) or ManagedExecutorServices (EE). So
>> the
>> >> > shutting down the container will mean shutting down these ES too.
>> >> >
>> >> > So I think we should need to carefully look at the way ES are closed.
>> >> > The
>> >> > question being : what do we do with async tasks that are still
>> running :
>> >> > should we abruptely interrupt them ? give them a chance to complete ?
>> >> > All
>> >> > these are exposed in different methods of ES : shutdown(),
>> shutdownNow()
>> >> > and
>> >> > awaitTermination(timeout). Since the container will have to call one
>> of
>> >> > these methods per ES it will manage, I think we should also expose
>> them.
>> >> >
>> >> > José
>> >> >
>> >> >
>> >> > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau <rmannibucau at gmail.com
>> >:
>> >> >>
>> >> >> ServiceLoader.load(<api>) = ServiceLoader.load(<api>, tccl)
>> >> >>
>> >> >> I was thinking to a plain servlet engine (tomcat to not say any
>> name)
>> >> >> and CDI container API to boot in webapps. Having cdi API in tomcat
>> >> >> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for
>> >> >> instance). This would mean using one webapp classloader to find the
>> >> >> booter/container. This is fine excepted if the instance is cached.
>> >> >>
>> >> >> Same thought in more complicated about OSGi but I guess it is not
>> yet
>> >> >> the target.
>> >> >>
>> >> >>
>> >> >> Romain Manni-Bucau
>> >> >> @rmannibucau
>> >> >> http://www.tomitribe.com
>> >> >> http://rmannibucau.wordpress.com
>> >> >> https://github.com/rmannibucau
>> >> >>
>> >> >>
>> >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>> >> >> >
>> >> >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote:
>> >> >> >>
>> >> >> >> Hi guys,
>> >> >> >>
>> >> >> >> - why shutdown and not AutoClosable?
>> >> >> >
>> >> >> > I like this idea.
>> >> >> >>
>> >> >> >> - about instance: it uses TCCL to load the impls, not sure it is
>> >> >> >> intended but depending the deployment it can be an issue (is this
>> >> >> >> api
>> >> >> >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?)
>> +
>> >> >> >> most of javax SPI creates a new instance each time "creator" is
>> >> >> >> called.
>> >> >> >
>> >> >> > I don't follow. Who uses TCCL?
>> >> >> >>
>> >> >> >> - Why Booter and not Container (better than factory IMO)? 1) for
>> >> >> >> consistency with other spec, 2) why can I shutdown a booter ;)?
>> >> >> >
>> >> >> > Exactly
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> Romain Manni-Bucau
>> >> >> >> @rmannibucau
>> >> >> >> http://www.tomitribe.com
>> >> >> >> http://rmannibucau.wordpress.com
>> >> >> >> https://github.com/rmannibucau
>> >> >> >>
>> >> >> >>
>> >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>> >> >> >>>
>> >> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote:
>> >> >> >>>
>> >> >> >>> I thought today's meeting was pretty good. Based on one of the
>> >> >> >>> discussion
>> >> >> >>> points, I wanted to try putting together an interface that
>> >> >> >>> described
>> >> >> >>> the
>> >> >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too
>> >> >> >>> well,
>> >> >> >>> I
>> >> >> >>> cannot assign a static variable in an interface the way I can
>> in an
>> >> >> >>> abstract
>> >> >> >>> class. More importantly, it doesn't give us the private level
>> >> >> >>> expectation I
>> >> >> >>> would look for in this case. I best I could come up with using
>> an
>> >> >> >>> interface
>> >> >> >>> is:
>> >> >> >>>
>> >> >> >>> public interface CDIBooter {
>> >> >> >>> default BeanManager initialize() {
>> >> >> >>> return initialize(new HashMap<>());
>> >> >> >>> }
>> >> >> >>>
>> >> >> >>> BeanManager initialize(Map<?,?> properties);
>> >> >> >>>
>> >> >> >>> Why BeanManager? I think it would be better to return CDI or its
>> >> >> >>> subclass
>> >> >> >>> rather than this low-level SPI. With the CDI class we get more
>> >> >> >>> user-friendly
>> >> >> >>> Instance<T> for free. We could also expose Event<T> similarly.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> void shutdown();
>> >> >> >>>
>> >> >> >>> class BootHolder {
>> >> >> >>>
>> >> >> >>> static CDIBooter instance = null;
>> >> >> >>>
>> >> >> >>> }
>> >> >> >>>
>> >> >> >>> static CDIBooter instance() {
>> >> >> >>> if(BootHolder.instance == null) {
>> >> >> >>> ServiceLoader<CDIBooter> serviceLoader =
>> >> >> >>> ServiceLoader.load(CDIBooter.class);
>> >> >> >>> for(CDIBooter booter : serviceLoader) {
>> >> >> >>> BootHolder.instance = booter;
>> >> >> >>> break;
>> >> >> >>> }
>> >> >> >>> }
>> >> >> >>> return BootHolder.instance;
>> >> >> >>> }
>> >> >> >>> }
>> >> >> >>>
>> >> >> >>> where as the abstract class is a bit briefer, while also being
>> >> >> >>> private.
>> >> >> >>>
>> >> >> >>> public abstract class CDIBooter {
>> >> >> >>> public BeanManager initialize() {
>> >> >> >>> return initialize(new HashMap<>());
>> >> >> >>> }
>> >> >> >>>
>> >> >> >>> public abstract BeanManager initialize(Map<?,?>
>> properties);
>> >> >> >>>
>> >> >> >>> public abstract void shutdown();
>> >> >> >>>
>> >> >> >>> private static CDIBooter instance = null;
>> >> >> >>>
>> >> >> >>> public static CDIBooter instance() {
>> >> >> >>> if(instance == null) {
>> >> >> >>> ServiceLoader<CDIBooter> serviceLoader =
>> >> >> >>> ServiceLoader.load(CDIBooter.class);
>> >> >> >>> for(CDIBooter booter : serviceLoader) {
>> >> >> >>> instance = booter;
>> >> >> >>> break;
>> >> >> >>> }
>> >> >> >>> }
>> >> >> >>> return instance;
>> >> >> >>> }
>> >> >> >>> }
>> >> >> >>>
>> >> >> >>> Obviously ignore concurrency issues, etc. It does look to be
>> safer
>> >> >> >>> to
>> >> >> >>> do
>> >> >> >>> an
>> >> >> >>> abstract class, rather than a factory-interface.
>> >> >> >>>
>> >> >> >>> John
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand
>> >> >> >>> <antoine at sabot-durand.net> wrote:
>> >> >> >>>>
>> >> >> >>>> Hi all,
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> I have business matter and will have to shorten the meeting
>> >> >> >>>> tonight
>> >> >> >>>> (half
>> >> >> >>>> an hour instead of 1h).
>> >> >> >>>>
>> >> >> >>>> I updated the SE doc and Antonio added useful annexes :
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing
>> >> >> >>>>
>> >> >> >>>> I propose we focus on this in these 30 mn
>> >> >> >>>>
>> >> >> >>>> regards,
>> >> >> >>>>
>> >> >> >>>> Antoine
>> >> >> >>>> _______________________________________________
>> >> >> >>>> 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.
>> >> >> >
>> >> >> >
>> >> >> _______________________________________________
>> >> >> 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.
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Java le soir Cours Java en ligne
>> >> > Twitter Paris JUG Devoxx France
>> >> > M : +33 6 76 82 91 47
>> >
>> >
>> >
>> > --
>> > Java le soir Cours Java en ligne
>> > Twitter Paris JUG Devoxx France
>> > M : +33 6 76 82 91 47
>>
>
>
> --
> Java le soir <http://blog.paumard.org> Cours Java en ligne
> <http://blog.paumard.org/cours-tutoriaux/>
> Twitter <http://twitter.com/#!/JosePaumard> Paris JUG
> <http://www.parisjug.org> Devoxx France <http://www.devoxx.fr>
> M : +33 6 76 82 91 47
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/dd583504/attachment-0001.html
More information about the cdi-dev
mailing list