Wow, you are fast. That workaround works. Thank you very much. Geoff
> On 1 Jun 2017, at 6:55 PM, Romain Manni-Bucau <[email protected]> wrote: > > Hmm, i can see the error but it is weird, think you can workaround it using > @Resource(name = "java:comp/EJBContext") or @Resource(lookup = > "java:comp/EJBContext") > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2017-06-01 11:49 GMT+02:00 JumpStart <[email protected]>: > >> I’ve created an almost minimal project with instructions in the README. >> Please take it for a spin! >> >> https://github.com/geoffcallender/xpro_min >> >> Geoff >> >>> On 25 May 2017, at 6:34 PM, Romain Manni-Bucau <[email protected]> >> wrote: >>> >>> it is the right way but we still need a sample reproducing the issue >> since >>> I think it is more linked to ear/scanning than anything else. The fact >>> InjectionProcessor issue this warning just means something went wrong >>> before. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://blog-rmannibucau.rhcloud.com> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github <https://github.com/ >> rmannibucau> | >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory >>> <https://javaeefactory-rmannibucau.rhcloud.com> >>> >>> 2017-05-25 10:48 GMT+02:00 JumpStart <geoff.callender.jumpstart@ >> gmail.com>: >>> >>>> @Interceptors is definitely where the problem is occurring. This warning >>>> message... >>>> >>>> WARN [LogStreamAsync.Thread] (Log4jLogStream.java:59) - Injection data >> not >>>> found in JNDI context: jndiName='comp/env/com.goxpro. >>>> xpro.business.domain.base.BaseService/context', target=com.goxpro.xpro. >>>> business.domain.base.BaseService/context >>>> >>>> …is coming from org.apache.openejb.InjectionProcessor . In debug I see >>>> that it successfully finds this jodi name: >>>> >>>> “comp/env/com.goxpro.xpro.business.domain.base.BaseService/em" >>>> >>>> …but not this jodi name… >>>> >>>> “comp/env/com.goxpro.xpro.business.domain.base.BaseService/context" >>>> >>>> Here’s BaseService: >>>> >>>> public abstract class BaseService { >>>> >>>> private final String demoModeStr = System.getProperty(“demo"); >>>> >>>> @PersistenceContext(unitName = "xpro") >>>> protected EntityManager em; >>>> >>>> @Resource >>>> protected SessionContext context; >>>> … >>>> } >>>> >>>> The warning comes from InjectionProcessor.fillInjectionProperties(final >>>> ObjectRecipe objectRecipe) >>>> which is down the stack from StatelessInstanceManager.create(final >>>> ThreadContext callContext, final BeanContext beanContext) >>>> where callContext is SecurityManagerService, which is a subclass of >>>> BaseService. >>>> >>>> @Stateless >>>> @Local(ISecurityManagerServiceLocal.class) >>>> @Remote(ISecurityManagerServiceRemote.class) >>>> @Interceptors({ UsernameCacheRefresher.class }) >>>> public class SecurityManagerService extends BaseService >>>> implements ISecurityManagerServiceLocal, >>>> ISecurityManagerServiceRemote { >>>> >>>> So, is @Resource no longer the right way to inject SessionContext? >>>> >>>>> On 24 May 2017, at 9:43 PM, Romain Manni-Bucau <[email protected]> >>>> wrote: >>>>> >>>>> Le 24 mai 2017 15:39, "JumpStart" <[email protected] >>> >>>> a >>>>> écrit : >>>>> >>>>> Some good news. I’ve commented out the @Interceptors line in each >> session >>>>> bean and now they can be called just fine! I’ll dig a bit deeper into >> why >>>>> the interceptor is failing. >>>>> >>>>> Producing a sample is going to be hard. If I do, will you require it to >>>> be >>>>> a working maven project (please no)? What’s the minimum you’re looking >>>> for? >>>>> >>>>> >>>>> Command line buildable (= dont assume we can use the same IDE with the >>>> same >>>>> config as you). Maven/gradle/ant/Makefile are ok. >>>>> >>>>> >>>>>> On 24 May 2017, at 8:08 PM, Romain Manni-Bucau <[email protected] >>> >>>>> wrote: >>>>>> >>>>>> Le 24 mai 2017 14:05, "JumpStart" <geoff.callender.jumpstart@ >> gmail.com> >>>> a >>>>>> écrit : >>>>>> >>>>>> The deployment is a collapsed EAR. >>>>>> >>>>>> If it’s a scanning issue, it wasn’t one before the upgrade. >>>>>> >>>>>> I’ve not needed @Interceptor before. The javadoc says it’s not needed >>>>> “This >>>>>> annotation is optional if the Interceptors <http://docs.oracle.com/ >>>>>> javaee/6/api/javax/interceptor/Interceptors.html> annotation ... used >>>> to >>>>>> associate the interceptor with the target class.” ( >>>> http://docs.oracle.com/ >>>>>> javaee/6/api/javax/interceptor/Interceptor.html < >>>> http://docs.oracle.com/ >>>>>> javaee/6/api/javax/interceptor/Interceptor.html>). I’ve just tried it >>>>>> anyway and the result is the same. >>>>>> >>>>>> Surely the key to this problem has to be in the following message? >>>>>> >>>>>> WARN [LogStreamAsync.Thread] (Log4jLogStream.java:59) - Injection data >>>> not >>>>>> found in JNDI context: jndiName='comp/env/com.goxpro. >>>>>> xpro.business.domain.base.BaseService/context', >> target=com.goxpro.xpro. >>>>>> business.domain.base.BaseService/context >>>>>> >>>>>> >>>>>> >>>>>> Well this message is a consequence so yes but it doesnt help much :(. >>>> C1n >>>>>> you push a sample on github using 7.x or 4.7 reproducing the issue? >>>>>> >>>>>> >>>>>>> On 24 May 2017, at 6:57 PM, Romain Manni-Bucau < >> [email protected]> >>>>>> wrote: >>>>>>> >>>>>>> How is the deployment/packaging? Can it be a scanning issue? You dont >>>> add >>>>>>> @Interceptor on the interceptor? >>>>>>> >>>>>>> >>>>>>> Le 24 mai 2017 11:28, "JumpStart" <geoff.callender.jumpstart@ >> gmail.com> >>>> a >>>>>>> écrit : >>>>>>> >>>>>>>> I’m upgrading from 4.5.2 to 7.0.3. Since the upgrade, I have an >>>>>>>> interceptor that fails and consequently session beans can’t be >>>> invoked. >>>>> I >>>>>>>> found the same error when I tried to upgrade to 4.6.0.2. Was there a >>>>> JNDI >>>>>>>> change between 4.5.2 and 4.6.0.2? >>>>>>>> >>>>>>>> >>>>>>>> WARN [LogStreamAsync.Thread] (Log4jLogStream.java:59) - Injection >> data >>>>>>>> not found in JNDI context: jndiName='comp/env/com.goxpro. >>>>>>>> xpro.business.domain.base.BaseService/context', >>>> target=com.goxpro.xpro. >>>>>>>> business.domain.base.BaseService/context >>>>>>>> WARN [LogStreamAsync.Thread] (Log4jLogStream.java:59) - Injection >> data >>>>>>>> not found in JNDI context: jndiName='comp/env/com.goxpro. >>>>>>>> xpro.business.domain.base.UsernameCacheRefresher/context', >>>>>>>> target=com.goxpro.xpro.business.domain.base. >>>>>> UsernameCacheRefresher/context >>>>>>>> WARN [LogStreamAsync.Thread] (Log4jLogStream.java:59) - Injection >> data >>>>>>>> not found in JNDI context: jndiName='comp/env/com.goxpro. >>>>>>>> xpro.business.domain.base.UsernameCacheRefresher/context', >>>>>>>> target=com.goxpro.xpro.business.domain.base. >>>>>> UsernameCacheRefresher/context >>>>>>>> WARN [LogStreamAsync.Thread] (Log4jLogStream.java:59) - Injection >> data >>>>>>>> not found in JNDI context: jndiName='comp/env/com.goxpro. >>>>>>>> xpro.business.domain.base.UsernameCacheRefresher/context', >>>>>>>> target=com.goxpro.xpro.business.domain.base. >>>>>> UsernameCacheRefresher/context >>>>>>>> ERROR [LogStreamAsync.Thread] (Log4jLogStream.java:51) - >>>>>>>> EjbTransactionUtil.handleSystemException: null >>>>>>>> java.lang.NullPointerException >>>>>>>> at com.goxpro.xpro.business.domain.base.UsernameCacheRefresher. >>>>>>>> refreshUsernameCache(UsernameCacheRefresher.java:38) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke( >>>>>>>> NativeMethodAccessorImpl.java:62) >>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke( >>>>>>>> DelegatingMethodAccessorImpl.java:43) >>>>>>>> at java.lang.reflect.Method.invoke(Method.java:497) >>>>>>>> at org.apache.openejb.core.interceptor. >>>>>>>> ReflectionInvocationContext$Invocation.invoke( >>>>>> ReflectionInvocationContext. >>>>>>>> java:205) >>>>>>>> at org.apache.openejb.core.interceptor. >>>>>>>> ReflectionInvocationContext.proceed(ReflectionInvocationContext. >>>>> java:186) >>>>>>>> at org.apache.openejb.monitoring.StatsInterceptor.record( >>>>>>>> StatsInterceptor.java:181) >>>>>>>> at org.apache.openejb.monitoring.StatsInterceptor.invoke( >>>>>>>> StatsInterceptor.java:100) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke( >>>>>>>> NativeMethodAccessorImpl.java:62) >>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke( >>>>>>>> DelegatingMethodAccessorImpl.java:43) >>>>>>>> at java.lang.reflect.Method.invoke(Method.java:497) >>>>>>>> at org.apache.openejb.core.interceptor. >>>>>>>> ReflectionInvocationContext$Invocation.invoke( >>>>>> ReflectionInvocationContext. >>>>>>>> java:205) >>>>>>>> at org.apache.openejb.core.interceptor. >>>>>>>> ReflectionInvocationContext.proceed(ReflectionInvocationContext. >>>>> java:186) >>>>>>>> at org.apache.openejb.core.interceptor.InterceptorStack. >>>>>>>> invoke(InterceptorStack.java:85) >>>>>>>> at org.apache.openejb.core.stateless.StatelessContainer._ >>>>>>>> invoke(StatelessContainer.java:252) >>>>>>>> at org.apache.openejb.core.stateless.StatelessContainer. >>>>>>>> invoke(StatelessContainer.java:212) >>>>>>>> at org.apache.openejb.core.ivm.EjbObjectProxyHandler. >>>>>>>> synchronizedBusinessMethod(EjbObjectProxyHandler.java:265) >>>>>>>> at org.apache.openejb.core.ivm.EjbObjectProxyHandler. >>>>>>>> businessMethod(EjbObjectProxyHandler.java:260) >>>>>>>> at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke( >>>>>>>> EjbObjectProxyHandler.java:89) >>>>>>>> at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke( >>>>>>>> BaseEjbProxyHandler.java:347) >>>>>>>> at com.sun.proxy.$Proxy206.passivateEligibleClients(Unknown >>>>>>>> Source) >>>>>>>> at com.goxpro.xpro.web.daemons.InactiveClientsManagerTask. >>>> doNext( >>>>>>>> InactiveClientsManagerTask.java:65) >>>>>>>> at com.goxpro.xpro.web.daemons.AbstractTaskRunner.run( >>>>>>>> AbstractTaskRunner.java:124) >>>>>>>> at java.util.TimerThread.mainLoop(Timer.java:555) >>>>>>>> at java.util.TimerThread.run(Timer.java:505) >>>>>>>> >>>>>>>> >>>>>>>> The NPE line is indicated in this source... >>>>>>>> >>>>>>>> >>>>>>>> public class UsernameCacheRefresher { >>>>>>>> >>>>>>>> @Resource >>>>>>>> private javax.ejb.SessionContext context; >>>>>>>> >>>>>>>> private static final Logger logger = LoggerFactory.getLogger( >>>>>>>> BaseService.class); >>>>>>>> >>>>>>>> @AroundInvoke >>>>>>>> public Object refreshUsernameCache(InvocationContext ic) throws >>>>>>>> Exception { >>>>>>>> >>>>>>>> Principal callerPrincipal = >> context.getCallerPrincipal(); >>>>>>>> <<< Line 38. NPE happens here. >>>>>>>> >>>>>>>> if (callerPrincipal != null) { >>>>>>>> UsernameCache.setThreadUsername( >>>>>>>> callerPrincipal.getName()); >>>>>>>> } >>>>>>>> else { >>>>>>>> // Is this even possible? Isn't there a default >>>>>>>> principal of guest (OpenEJB) or anonymous (JBoss)? >>>>>>>> logger.error("WATCH OUT - UsernameCacheRefresher >>>>>>>> found callerPrincipal is null!!!!!!!!!!!!!"); >>>>>>>> UsernameCache.setThreadUsername(null); >>>>>>>> } >>>>>>>> >>>>>>>> return ic.proceed(); >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Here’s an example of how it gets used… >>>>>>>> >>>>>>>> >>>>>>>> @Stateless >>>>>>>> @Local(IEmailManagerServiceLocal.class) >>>>>>>> @Remote(IEmailManagerServiceRemote.class) >>>>>>>> @Interceptors({ UsernameCacheRefresher.class }) >>>>>>>> public class EmailManagerService extends BaseService implements >>>>>>>> IEmailManagerServiceLocal, IEmailManagerServiceRemote { >>>>>>>> … >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Thanks in advance, >>>>>>>> >>>>>>>> Geoff >>>> >>>> >> >>
