<div dir="ltr">All,<div><br></div><div>I have the flip side of this change available as well. </div><div><br></div><div><a href="https://github.com/johnament/cdi/blob/6fbd7d834e11295a3a4490294cde0ad18bee6b33/api/src/test/java/org/jboss/cdi/api/test/ContextManagementExample.java">https://github.com/johnament/cdi/blob/6fbd7d834e11295a3a4490294cde0ad18bee6b33/api/src/test/java/org/jboss/cdi/api/test/ContextManagementExample.java</a><br></div><div><br></div><div>In this version, activation is done directly from BeanManager instead of the secondary context object. I'm also thinking with this commit that ManagedContext should actually be "UnmanagedContext" to clarify that its not being handled in the container.</div><div><br></div><div>John</div><div><br></div><div>PS - One of the use cases I put in the JIRA ticket was around quartz integration. This is what the resulting integration looks like</div><div><br></div><div><div> public class CDIJobListener implements JobListener {</div><div><br></div><div> public static final String CONTEXT_NAME = "CDIJobListener.cdi_context";</div><div><br></div><div> @Override</div><div> public String getName() {</div><div> return "cdi";</div><div> }</div><div><br></div><div> @Override</div><div> public void jobToBeExecuted(JobExecutionContext jobExecutionContext) {</div><div> BeanManager beanManager = CDI.current().getBeanManager();</div><div> ManagedContext requestContext = beanManager.activateContext(RequestScoped.class);</div><div> jobExecutionContext.getMergedJobDataMap().put(CONTEXT_NAME, requestContext);</div><div> }</div><div><br></div><div> @Override</div><div> public void jobExecutionVetoed(JobExecutionContext jobExecutionContext) {</div><div> ManagedContext managedContext = (ManagedContext)jobExecutionContext.getMergedJobDataMap().get(CONTEXT_NAME);</div><div> managedContext.deactivate();</div><div> }</div><div><br></div><div> @Override</div><div> public void jobWasExecuted(JobExecutionContext jobExecutionContext, JobExecutionException e) {</div><div> jobExecutionVetoed(jobExecutionContext);</div><div> }</div><div> }</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 24, 2016 at 5:28 PM John D. Ament <<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">All,<div><br></div><div>One of the discussion points from today was around where activation belongs. I pushed up a branch with a rough example of what this might look like</div><div><br></div><div><a href="https://github.com/johnament/cdi/commit/f4cb91dca0eeb7edef5d4238f55ca413a0711e26" target="_blank">https://github.com/johnament/cdi/commit/f4cb91dca0eeb7edef5d4238f55ca413a0711e26</a><br></div><div><br></div><div>One of my concerns with doing this is that to get a context object from the bean manager, it needs to be active. This is in the javadocs: Obtains an active {@linkplain javax.enterprise.context.spi.Context context object} for the given. If we change this, it risks breaking compatibility.</div><div><br></div><div>Let me know your thoughts.</div></div><div dir="ltr"><div><br></div><div>John</div></div></blockquote></div>