<div dir="ltr"><div>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. </div><div><br></div>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 : <div>for (ES es : cdi.getESes()) {</div><div> myShutdown(es) ;</div><div>}</div><div><br></div><div>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. </div><div><div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why exposing them? When not simply exposing the executor service (in<br>
"init" method).<br>
<br>
CDIContainer cdi = CDIContainer.init(singletonMap(ExecutorService.class, myEs));<br>
// do something awesome<br>
shutdownAsIwant(myEs);<br>
cdi.close();<br>
<br>
Would avoid to have a lot of method several users will not care about.<br>
<br>
By default it would do a if (timeout <= 0 ||<br>
!defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r<br>
: defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); }<br>
} } with timeout a property of the init map with a default in<br>
CDIContainer (constant)<br>
<br>
wdyt?<br>
<span class="im HOEnZb"><br>
<br>
Romain Manni-Bucau<br>
@rmannibucau<br>
<a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
<a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
<a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">2014-12-18 9:19 GMT+01:00 José Paumard <<a href="mailto:jose.paumard@gmail.com">jose.paumard@gmail.com</a>>:<br>
> I think we need to think more about how to close the Container.<br>
><br>
> We need to take into account the fact that there wil be async process<br>
> running in ExecutorServices (SE) or ManagedExecutorServices (EE). So the<br>
> shutting down the container will mean shutting down these ES too.<br>
><br>
> So I think we should need to carefully look at the way ES are closed. The<br>
> question being : what do we do with async tasks that are still running :<br>
> should we abruptely interrupt them ? give them a chance to complete ? All<br>
> these are exposed in different methods of ES : shutdown(), shutdownNow() and<br>
> awaitTermination(timeout). Since the container will have to call one of<br>
> these methods per ES it will manage, I think we should also expose them.<br>
><br>
> José<br>
><br>
><br>
> 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>:<br>
>><br>
>> ServiceLoader.load(<api>) = ServiceLoader.load(<api>, tccl)<br>
>><br>
>> I was thinking to a plain servlet engine (tomcat to not say any name)<br>
>> and CDI container API to boot in webapps. Having cdi API in tomcat<br>
>> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2 for<br>
>> instance). This would mean using one webapp classloader to find the<br>
>> booter/container. This is fine excepted if the instance is cached.<br>
>><br>
>> Same thought in more complicated about OSGi but I guess it is not yet<br>
>> the target.<br>
>><br>
>><br>
>> Romain Manni-Bucau<br>
>> @rmannibucau<br>
>> <a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
>> <a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
>> <a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
>><br>
>><br>
>> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>>:<br>
>> ><br>
>> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote:<br>
>> >><br>
>> >> Hi guys,<br>
>> >><br>
>> >> - why shutdown and not AutoClosable?<br>
>> ><br>
>> > I like this idea.<br>
>> >><br>
>> >> - about instance: it uses TCCL to load the impls, not sure it is<br>
>> >> intended but depending the deployment it can be an issue (is this api<br>
>> >> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) +<br>
>> >> most of javax SPI creates a new instance each time "creator" is<br>
>> >> called.<br>
>> ><br>
>> > I don't follow. Who uses TCCL?<br>
>> >><br>
>> >> - Why Booter and not Container (better than factory IMO)? 1) for<br>
>> >> consistency with other spec, 2) why can I shutdown a booter ;)?<br>
>> ><br>
>> > Exactly<br>
>> ><br>
>> >><br>
>> >><br>
>> >><br>
>> >> Romain Manni-Bucau<br>
>> >> @rmannibucau<br>
>> >> <a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
>> >> <a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
>> >> <a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
>> >><br>
>> >><br>
>> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>>:<br>
>> >>><br>
>> >>> On 12/18/2014 04:33 AM, John D. Ament wrote:<br>
>> >>><br>
>> >>> I thought today's meeting was pretty good. Based on one of the<br>
>> >>> discussion<br>
>> >>> points, I wanted to try putting together an interface that described<br>
>> >>> the<br>
>> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work too well,<br>
>> >>> I<br>
>> >>> cannot assign a static variable in an interface the way I can in an<br>
>> >>> abstract<br>
>> >>> class. More importantly, it doesn't give us the private level<br>
>> >>> expectation I<br>
>> >>> would look for in this case. I best I could come up with using an<br>
>> >>> interface<br>
>> >>> is:<br>
>> >>><br>
>> >>> public interface CDIBooter {<br>
>> >>> default BeanManager initialize() {<br>
>> >>> return initialize(new HashMap<>());<br>
>> >>> }<br>
>> >>><br>
>> >>> BeanManager initialize(Map<?,?> properties);<br>
>> >>><br>
>> >>> Why BeanManager? I think it would be better to return CDI or its<br>
>> >>> subclass<br>
>> >>> rather than this low-level SPI. With the CDI class we get more<br>
>> >>> user-friendly<br>
>> >>> Instance<T> for free. We could also expose Event<T> similarly.<br>
>> >>><br>
>> >>><br>
>> >>> void shutdown();<br>
>> >>><br>
>> >>> class BootHolder {<br>
>> >>><br>
>> >>> static CDIBooter instance = null;<br>
>> >>><br>
>> >>> }<br>
>> >>><br>
>> >>> static CDIBooter instance() {<br>
>> >>> if(BootHolder.instance == null) {<br>
>> >>> ServiceLoader<CDIBooter> serviceLoader =<br>
>> >>> ServiceLoader.load(CDIBooter.class);<br>
>> >>> for(CDIBooter booter : serviceLoader) {<br>
>> >>> BootHolder.instance = booter;<br>
>> >>> break;<br>
>> >>> }<br>
>> >>> }<br>
>> >>> return BootHolder.instance;<br>
>> >>> }<br>
>> >>> }<br>
>> >>><br>
>> >>> where as the abstract class is a bit briefer, while also being<br>
>> >>> private.<br>
>> >>><br>
>> >>> public abstract class CDIBooter {<br>
>> >>> public BeanManager initialize() {<br>
>> >>> return initialize(new HashMap<>());<br>
>> >>> }<br>
>> >>><br>
>> >>> public abstract BeanManager initialize(Map<?,?> properties);<br>
>> >>><br>
>> >>> public abstract void shutdown();<br>
>> >>><br>
>> >>> private static CDIBooter instance = null;<br>
>> >>><br>
>> >>> public static CDIBooter instance() {<br>
>> >>> if(instance == null) {<br>
>> >>> ServiceLoader<CDIBooter> serviceLoader =<br>
>> >>> ServiceLoader.load(CDIBooter.class);<br>
>> >>> for(CDIBooter booter : serviceLoader) {<br>
>> >>> instance = booter;<br>
>> >>> break;<br>
>> >>> }<br>
>> >>> }<br>
>> >>> return instance;<br>
>> >>> }<br>
>> >>> }<br>
>> >>><br>
>> >>> Obviously ignore concurrency issues, etc. It does look to be safer to<br>
>> >>> do<br>
>> >>> an<br>
>> >>> abstract class, rather than a factory-interface.<br>
>> >>><br>
>> >>> John<br>
>> >>><br>
>> >>><br>
>> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand<br>
>> >>> <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>> wrote:<br>
>> >>>><br>
>> >>>> Hi all,<br>
>> >>>><br>
>> >>>><br>
>> >>>> I have business matter and will have to shorten the meeting tonight<br>
>> >>>> (half<br>
>> >>>> an hour instead of 1h).<br>
>> >>>><br>
>> >>>> I updated the SE doc and Antonio added useful annexes :<br>
>> >>>><br>
>> >>>><br>
>> >>>> <a href="https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing</a><br>
>> >>>><br>
>> >>>> I propose we focus on this in these 30 mn<br>
>> >>>><br>
>> >>>> regards,<br>
>> >>>><br>
>> >>>> Antoine<br>
>> >>>> _______________________________________________<br>
>> >>>> cdi-dev mailing list<br>
>> >>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> >>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>> >>>><br>
>> >>>> Note that for all code provided on this list, the provider licenses<br>
>> >>>> the<br>
>> >>>> code under the Apache License, Version 2<br>
>> >>>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
>> >>>> ideas<br>
>> >>>> provided on this list, the provider waives all patent and other<br>
>> >>>> intellectual<br>
>> >>>> property rights inherent in such information.<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> _______________________________________________<br>
>> >>> cdi-dev mailing list<br>
>> >>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> >>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>> >>><br>
>> >>> Note that for all code provided on this list, the provider licenses<br>
>> >>> the<br>
>> >>> code<br>
>> >>> under the Apache License, Version 2<br>
>> >>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> >>> provided on this list, the provider waives all patent and other<br>
>> >>> intellectual<br>
>> >>> property rights inherent in such information.<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> _______________________________________________<br>
>> >>> cdi-dev mailing list<br>
>> >>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> >>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>> >>><br>
>> >>> Note that for all code provided on this list, the provider licenses<br>
>> >>> the<br>
>> >>> code<br>
>> >>> under the Apache License, Version 2<br>
>> >>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> >>> provided on this list, the provider waives all patent and other<br>
>> >>> intellectual<br>
>> >>> property rights inherent in such information.<br>
>> ><br>
>> ><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses the<br>
>> code under the Apache License, Version 2<br>
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> provided on this list, the provider waives all patent and other intellectual<br>
>> property rights inherent in such information.<br>
><br>
><br>
><br>
> --<br>
> Java le soir Cours Java en ligne<br>
> Twitter Paris JUG Devoxx France<br>
> M : <a href="tel:%2B33%206%2076%2082%2091%2047" value="+33676829147">+33 6 76 82 91 47</a><br>
</div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div><a href="http://blog.paumard.org" target="_blank">Java le soir</a> <a href="http://blog.paumard.org/cours-tutoriaux/" target="_blank">Cours Java en ligne</a></div><div><a href="http://twitter.com/#!/JosePaumard" target="_blank">Twitter</a> <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div><div>M : +33 6 76 82 91 47</div></div>
</div>