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