All,
I have the flip side of this change available as well.
https://github.com/johnament/cdi/blob/6fbd7d834e11295a3a4490294cde0ad18be...
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.
John
PS - One of the use cases I put in the JIRA ticket was around quartz
integration. This is what the resulting integration looks like
public class CDIJobListener implements JobListener {
public static final String CONTEXT_NAME =
"CDIJobListener.cdi_context";
@Override
public String getName() {
return "cdi";
}
@Override
public void jobToBeExecuted(JobExecutionContext
jobExecutionContext) {
BeanManager beanManager = CDI.current().getBeanManager();
ManagedContext requestContext =
beanManager.activateContext(RequestScoped.class);
jobExecutionContext.getMergedJobDataMap().put(CONTEXT_NAME,
requestContext);
}
@Override
public void jobExecutionVetoed(JobExecutionContext
jobExecutionContext) {
ManagedContext managedContext =
(ManagedContext)jobExecutionContext.getMergedJobDataMap().get(CONTEXT_NAME);
managedContext.deactivate();
}
@Override
public void jobWasExecuted(JobExecutionContext jobExecutionContext,
JobExecutionException e) {
jobExecutionVetoed(jobExecutionContext);
}
}
On Fri, Jun 24, 2016 at 5:28 PM John D. Ament <john.d.ament(a)gmail.com>
wrote:
All,
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
https://github.com/johnament/cdi/commit/f4cb91dca0eeb7edef5d4238f55ca413a...
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.
Let me know your thoughts.
John