<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
But we should only be shutting down thread pools that we manage.
Just like CompletableFuture won't shut down your thread pool if you
pass it to *Async method.<br>
<div class="moz-cite-prefix">On 12/18/2014 11:57 AM, José Paumard
wrote:<br>
</div>
<blockquote
cite="mid:CAKWkJ_K=vka3e89kPWp9tN1ngFCpW1XY13fJ5YC-pX7QMTAhGA@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>José</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-12-18 10:18 GMT+01:00 Romain
Manni-Bucau <span dir="ltr"><<a moz-do-not-send="true"
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"><span
class="">2014-12-18 9:58 GMT+01:00 José Paumard <<a
moz-do-not-send="true"
href="mailto:jose.paumard@gmail.com">jose.paumard@gmail.com</a>>:<br>
> From what we wrote about async events, ES can be
submitted through the<br>
> fireAsync call, following the patterns of
CompletionStage. We can also<br>
> submit a default ES while building a CDI container (a
you wrote), and if we<br>
> dont the default ES will probably be the default
ForkJoinPool.<br>
><br>
> So we may have more than one ES, making things more
complicated than the<br>
> pattern you wrote. I think that having the user to
close all the ESes will<br>
> lead to the same pattern again and again :<br>
> for (ES es : cdi.getESes()) {<br>
> myShutdown(es) ;<br>
> }<br>
><br>
<br>
</span>Sorry I missed something here: how can we get
multiple ES? Basically<br>
if CDI needs a ES behing the scene I expect it expose few
config like<br>
potential concurrent calls number etc...In such a case I'm
not sure if<br>
having multiple ES would be a good idea.<br>
<div class="HOEnZb">
<div class="h5"><br>
> I'd prefer to have a cdi.shutdown(),
cdi.shudownNow() or<br>
> cdi.awaitTermination(...) or whatever we call those
methods, to encapsulate<br>
> this code. Seems cleaner to me. It might look like
CDI is becoming an ES<br>
> itself, but it's delegation, not inheritance.<br>
><br>
><br>
><br>
> 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau <<a
moz-do-not-send="true"
href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>:<br>
>><br>
>> Why exposing them? When not simply exposing the
executor service (in<br>
>> "init" method).<br>
>><br>
>> CDIContainer cdi =
CDIContainer.init(singletonMap(ExecutorService.class,<br>
>> 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>
>><br>
>><br>
>> Romain Manni-Bucau<br>
>> @rmannibucau<br>
>> <a moz-do-not-send="true"
href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
>> <a moz-do-not-send="true"
href="http://rmannibucau.wordpress.com"
target="_blank">http://rmannibucau.wordpress.com</a><br>
>> <a moz-do-not-send="true"
href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
>><br>
>><br>
>> 2014-12-18 9:19 GMT+01:00 José Paumard <<a
moz-do-not-send="true"
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.<br>
>> > 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 ?<br>
>> > All<br>
>> > these are exposed in different methods of
ES : shutdown(), shutdownNow()<br>
>> > 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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
>> >> <a moz-do-not-send="true"
href="http://rmannibucau.wordpress.com"
target="_blank">http://rmannibucau.wordpress.com</a><br>
>> >> <a moz-do-not-send="true"
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 moz-do-not-send="true"
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<br>
>> >> >> 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 moz-do-not-send="true"
href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
>> >> >> <a moz-do-not-send="true"
href="http://rmannibucau.wordpress.com"
target="_blank">http://rmannibucau.wordpress.com</a><br>
>> >> >> <a moz-do-not-send="true"
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 moz-do-not-send="true"
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<br>
>> >> >>> described<br>
>> >> >>> the<br>
>> >> >>> boot paradigm.
Unfortunately even in Java 8 it doesn't work too<br>
>> >> >>> 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<br>
>> >> >>> 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
moz-do-not-send="true"
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<br>
>> >> >>>> tonight<br>
>> >> >>>> (half<br>
>> >> >>>> an hour instead of
1h).<br>
>> >> >>>><br>
>> >> >>>> I updated the SE doc
and Antonio added useful annexes :<br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>> <a
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> >> >>>> <a
moz-do-not-send="true"
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<br>
>> >> >>>> licenses<br>
>> >> >>>> the<br>
>> >> >>>> code under the Apache
License, Version 2<br>
>> >> >>>> (<a
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> >> >>> <a
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> >> >>> <a
moz-do-not-send="true"
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
moz-do-not-send="true"
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>
>> >> cdi-dev mailing list<br>
>> >> <a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> >> <a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
>> > Java le soir Cours Java en ligne<br>
>> > Twitter Paris JUG Devoxx France<br>
>> > M : <a moz-do-not-send="true"
href="tel:%2B33%206%2076%2082%2091%2047"
value="+33676829147">+33 6 76 82 91 47</a><br>
><br>
><br>
><br>
> --<br>
> Java le soir Cours Java en ligne<br>
> Twitter Paris JUG Devoxx France<br>
> M : <a moz-do-not-send="true"
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 moz-do-not-send="true" href="http://blog.paumard.org"
target="_blank">Java le soir</a> <a moz-do-not-send="true"
href="http://blog.paumard.org/cours-tutoriaux/"
target="_blank">Cours Java en ligne</a></div>
<div><a moz-do-not-send="true"
href="http://twitter.com/#%21/JosePaumard" target="_blank">Twitter</a> <a
moz-do-not-send="true" href="http://www.parisjug.org"
target="_blank">Paris JUG</a> <a moz-do-not-send="true"
href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div>
<div>M : +33 6 76 82 91 47</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>