Wow, you are fast. That workaround works. Thank you very much.
Geoff
> On 1 Jun 2017, at 6:55 PM, Romain Manni-Bucau <rmannibucau@gmail.com> 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 <geoff.callender.jumpstart@gmail.com>:
>
>> 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 <rmannibucau@gmail.com>
>> 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 <rmannibucau@gmail.com>
>>>> wrote:
>>>>>
>>>>> Le 24 mai 2017 15:39, "JumpStart" <geoff.callender.jumpstart@gmail.com
>>>
>>>> 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 <rmannibucau@gmail.com
>>>
>>>>> 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 <
>> rmannibucau@gmail.com>
>>>>>> 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
>>>>
>>>>
>>
>>
|