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-w... I propose we focus on this in these 30 mn regards, 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.

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(a)sabot-durand.net&gt; 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-w... > > I propose we focus on this in these 30 mn > > regards, > > 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.

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(a)redhat.com&gt;: >> >> 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(a)sabot-durand.net&gt; 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-w... >>> >>> I propose we focus on this in these 30 mn >>> >>> regards, >>> >>> 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.

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(a)gmail.com&gt;: > > 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(a)redhat.com&gt;: > > > > 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(a)redhat.com&gt;: > >>> > >>> 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(a)sabot-durand.net&gt; 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-w... > >>>> > >>>> I propose we focus on this in these 30 mn > >>>> > >>>> regards, > >>>> > >>>> 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. -- Java le soir Cours Java en ligne Twitter Paris JUG Devoxx France M : +33 6 76 82 91 47

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) ; }

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(a)gmail.com&gt;: > > 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(a)gmail.com&gt;: > > 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(a)gmail.com&gt;: > >> > >> 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(a)redhat.com&gt;: > >> > > >> > 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(a)redhat.com&gt;: > >> >>> > >> >>> 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(a)sabot-durand.net&gt; 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-w... > >> >>>> > >> >>>> I propose we focus on this in these 30 mn > >> >>>> > >> >>>> regards, > >> >>>> > >> >>>> 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. > > > > > > > > -- > > 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

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(a)gmail.com&gt;: > > 2014-12-18 9:58 GMT+01:00 José Paumard <jose.paumard(a)gmail.com&gt;: > > 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(a)gmail.com&gt;: > >> > >> 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(a)gmail.com&gt;: > >> > 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(a)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(a)redhat.com&gt;: > >> >> > > >> >> > 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(a)redhat.com&gt;: > >> >> >>> > >> >> >>> 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(a)sabot-durand.net&gt; 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-w... > >> >> >>>> > >> >> >>>> I propose we focus on this in these 30 mn > >> >> >>>> > >> >> >>>> regards, > >> >> >>>> > >> >> >>>> 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. > >> > > >> > > >> > > >> > -- > >> > 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(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.

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(a)gmail.com <mailto:rmannibucau@gmail.com>>: 2014-12-18 9:58 GMT+01:00 José Paumard <jose.paumard(a)gmail.com <mailto:jose.paumard@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(a)gmail.com <mailto:rmannibucau@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(a)gmail.com <mailto:jose.paumard@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(a)gmail.com <mailto:rmannibucau@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(a)redhat.com <mailto:jharting@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(a)redhat.com <mailto:jharting@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(a)sabot-durand.net <mailto:antoine@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-w... >> >> >>>> >> >> >>>> I propose we focus on this in these 30 mn >> >> >>>> >> >> >>>> regards, >> >> >>>> >> >> >>>> Antoine >> >> >>>> _______________________________________________ >> >> >>>> cdi-dev mailing list >> >> >>>> cdi-dev(a)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(a)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(a)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(a)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. >> > >> > >> > >> > -- >> > Java le soir Cours Java en ligne >> > Twitter Paris JUG Devoxx France >> > M : +33 6 76 82 91 47 <tel:%2B33%206%2076%2082%2091%2047> > > > > -- > Java le soir Cours Java en ligne > Twitter Paris JUG Devoxx France > M : +33 6 76 82 91 47 <tel:%2B33%206%2076%2082%2091%2047> -- Java le soir <http://blog.paumard.org> Cours Java en ligne <http://blog.paumard.org/cours-tutoriaux/> Twitter <http://twitter.com/#%21/JosePaumard> Paris JUG <http://www.parisjug.org> Devoxx France <http://www.devoxx.fr> M : +33 6 76 82 91 47