[cdi-dev] Shutting down CDI Instances

Antonio Goncalves antonio.goncalves at gmail.com
Thu Apr 16 05:02:17 EDT 2015


*Option 2*. I can't think of the option 1 pattern in Java EE. If you look
at JPA for example, you can see sentences such as :


*"The Persistence class is available in a Java EE container environment as
well; however, support for the Java SE bootstrapping APIs is not required
in container environments."*

*"Both JTA entity managers and resource-local entity managers are required
to be supported in Java EE web containers and EJB containers. (...) In
general, in Java SE environments only resource-local entity managers are
supported."*


So I think Java EE developers are more confortable on using a same API, and
depending on the environment (EE or SE) things might happen this way, or
that way (ex. throwing an exception).

Antonio



On Tue, Mar 31, 2015 at 5:19 PM, JJ Snyder <j.j.snyder at oracle.com> wrote:

>  Option 2
> On 03/24/2015 02:00 PM, John D. Ament wrote:
>
> 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 listcdi-dev at lists.jboss.orghttps://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.
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150416/fbdda04a/attachment.html 


More information about the cdi-dev mailing list