1 of 1 people found this helpful
According to §11.15 the EJB specification:
"The container must make a component’s EJBContext interface available either through injection using the Resource annotation or in JNDI under the name java:comp/EJBContext"
So, no, the EJBContext is not required to be accessible via JNDI. WildFly makes it available via injection using the Resource annotation. The issue here is that your Infinispan entry processor is not managed by WildFly, and thus does not have the proper context to resolve an EJBContext, even via the Resource annotation. Rather, what you'll want to do is create the entry processor using a pre-resolved EJBContext so that you can use it when the entry processor fires. If you paste the appropriate code, I can hopefully help with the wiring.
Hi, thank you for taking the time to provide some insight.
You are probably correct in your identification of the problem, that the EJBContext is not available because the entry processor is not managed by WildFly. Further, I agree that creating the entry processor using a pre-resolved EJBContext would make it usable.
However, the EntryProcessor instantiation in my situation is out of my hands. Infinispan's infrastructure performing the caching is serializing an EntryProcessor instance on one WildFly node (where EJB Context is available and being utilized), then the serialized EntryProcessor is sent (Infinispan, not my code) to another clustered node and Infinispan infrastructure de-serializes and executes the "process" method before any of my code is executed. Since that's the case, I don't really have an opportunity / hook / place to create the entry processor using pre-resolved EJBContext. It's out of my hands in the Infinispan infrastructure.