[cdi-dev] Shutting down CDI Instances

Romain Manni-Bucau rmannibucau at gmail.com
Thu Mar 26 08:23:11 EDT 2015


in these choices I prefer 2 as well

maybe stupid but why not firing an event? evt.fire(new
StandaloneContainerShutdown());


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-03-26 12:51 GMT+01:00 Pete Muir <pmuir at redhat.com>:

> I think I prefer (2).
>
> > On 26 Mar 2015, at 10:56, Antoine Sabot-Durand <antoine at sabot-durand.net>
> wrote:
> >
> > After second thought, option 1 is my favorite. It’ll be easier to
> dedicate this subclass to SE bootstrap instead of forbidden usage of some
> methods in CDI (option 2). Concerning option 3, I don’t see the benefit on
> option 1.
> >
> >
> >
> >> Le 24 mars 2015 à 19:00, John D. Ament <john.d.ament at gmail.com> a
> écrit :
> >>
> >> All,
> >>
> >> In discussion today w/ Jozef, we found that the way of shutting down a
> container in the proposed SE API precluded the notion that multiple
> containers could be running.  While we're not necessarily going to handle
> multiple containers right now, we don't want to preclude the idea either.
> With that said, there were three different approaches though up to handle
> how to shutdown a launched container.  it obivously would only work with an
> SE booted container, but part of this does give a pointer in how we may
> implement initialize.
> >>
> >> Option 1 - Subclass CDI.  The returned CDI instance when bootstrapped
> would return this subclass of CDI that has shutdown capability.
> >>
> >> Option 2 - Add method to CDI.  Add the shutdown method to CDI directly,
> and throw an exception if called in an EE environment.
> >>
> >> Option 3 - Return a different object all together when initializing.
> Return something else from initialize, e.g. CDIContext, which has a
> shutdown method when you initialize.  That class would also have a getter
> for the CDI instance backing it.
> >>
> >> Let us know your thoughts.
> >>
> >> Thanks,
> >>
> >> John
> >> _______________________________________________
> >> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150326/213f7633/attachment.html 


More information about the cdi-dev mailing list