[cdi-dev] Today's meeting will be shorter and about SE
Werner Keil
werner.keil at gmail.com
Thu Dec 18 07:46:36 EST 2014
I suppose the part "Specifications that define an SPI" only covers those
under the EE umbrella, though the document is about SE?
Werner
On Thu, Dec 18, 2014 at 1:26 PM, <cdi-dev-request at lists.jboss.org> wrote:
>
> Send cdi-dev mailing list submissions to
> cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Today's meeting will be shorter and about SE (John D. Ament)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 18 Dec 2014 07:26:02 -0500
> From: "John D. Ament" <john.d.ament at gmail.com>
> Subject: Re: [cdi-dev] Today's meeting will be shorter and about SE
> To: Jos? Paumard <jose.paumard at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CAOqetn-dUX8HP5v9hCYKP-i8eViK69ZXDf0urtqUv1GtL=
> 10RA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.html
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 49, Issue 23
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/818f3d0a/attachment-0001.html
More information about the cdi-dev
mailing list