[cdi-dev] Today's meeting will be shorter and about SE
Romain Manni-Bucau
rmannibucau at gmail.com
Thu Dec 18 04:18:59 EST 2014
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
More information about the cdi-dev
mailing list