tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From JumpStart <geoff.callender.jumpst...@gmail.com>
Subject Re: Upgrading OpenEJB Standalone to 7.0.3
Date Thu, 01 Jun 2017 11:27:00 GMT
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
>>>> 
>>>> 
>> 
>> 


Mime
View raw message