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 <[email protected]>: > @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" <[email protected]> > 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" <[email protected]> > 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 > >
