in these choices I prefer 2 as well

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


Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber

2015-03-26 12:51 GMT+01:00 Pete Muir <pmuir@redhat.com>:
I think I prefer (2).

> On 26 Mar 2015, at 10:56, Antoine Sabot-Durand <antoine@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@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@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@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@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.