Upgrading OpenEJB Standalone to 7.0.3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Upgrading OpenEJB Standalone to 7.0.3

JumpStart
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

Romain Manni-Bucau
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" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

JumpStart
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

> On 24 May 2017, at 6:57 PM, Romain Manni-Bucau <[hidden email]> 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" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

Romain Manni-Bucau
Le 24 mai 2017 14:05, "JumpStart" <[hidden email]> 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 <[hidden email]>
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" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

JumpStart
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?

> On 24 May 2017, at 8:08 PM, Romain Manni-Bucau <[hidden email]> wrote:
>
> Le 24 mai 2017 14:05, "JumpStart" <[hidden email]> 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 <[hidden email]>
> 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" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

Romain Manni-Bucau
Le 24 mai 2017 15:39, "JumpStart" <[hidden email]> 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 <[hidden email]>
wrote:
>
> Le 24 mai 2017 14:05, "JumpStart" <[hidden email]> 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 <[hidden email]>
> 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" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

JumpStart
@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 <[hidden email]> wrote:
>
> Le 24 mai 2017 15:39, "JumpStart" <[hidden email]> 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 <[hidden email]>
> wrote:
>>
>> Le 24 mai 2017 14:05, "JumpStart" <[hidden email]> 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 <[hidden email]>
>> 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" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

Romain Manni-Bucau
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 <[hidden email]>:

> @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 <[hidden email]>
> wrote:
> >
> > Le 24 mai 2017 15:39, "JumpStart" <[hidden email]>
> 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 <[hidden email]>
> > wrote:
> >>
> >> Le 24 mai 2017 14:05, "JumpStart" <[hidden email]>
> 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 <[hidden email]>
> >> 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" <[hidden email]>
> 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
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

JumpStart
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 <[hidden email]> 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 <[hidden email]>:
>
>> @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 <[hidden email]>
>> wrote:
>>>
>>> Le 24 mai 2017 15:39, "JumpStart" <[hidden email]>
>> 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 <[hidden email]>
>>> wrote:
>>>>
>>>> Le 24 mai 2017 14:05, "JumpStart" <[hidden email]>
>> 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 <[hidden email]>
>>>> 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" <[hidden email]>
>> 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
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

Romain Manni-Bucau
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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>
> >> wrote:
> >>>
> >>> Le 24 mai 2017 15:39, "JumpStart" <[hidden email]
> >
> >> 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 <[hidden email]
> >
> >>> 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 <
> [hidden email]>
> >>>> 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
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

JumpStart
Wow, you are fast. That workaround works. Thank you very much.

Geoff

> On 1 Jun 2017, at 6:55 PM, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>:
>
>> 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 <[hidden email]>
>> 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 <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Le 24 mai 2017 15:39, "JumpStart" <[hidden email]
>>>
>>>> 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 <[hidden email]
>>>
>>>>> 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 <
>> [hidden email]>
>>>>>> 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
>>>>
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

Romain Manni-Bucau
think i know what's happening, not really sure how to solve properly it
since it can be due to your integration: jetty is mutating the context
packages (how new InitialContext() is resolved) and indeed we use jetty
JNDI space instead of openejb one which has the binding. Maybe try starting
openejb before jetty or enforcing openejb package first
in javax.naming.Context#URL_PKG_PREFIXES system property (I'm not sure
there the manipulation jetty does)


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 13:27 GMT+02:00 JumpStart <[hidden email]>:

> Wow, you are fast. That workaround works. Thank you very much.
>
> Geoff
>
> > On 1 Jun 2017, at 6:55 PM, Romain Manni-Bucau <[hidden email]>
> 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 <[hidden email]>
> >> 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 <
> [hidden email]>
> >>>> 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 <
> [hidden email]
> >>>
> >>>>> 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 <
> >> [hidden email]>
> >>>>>> 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
> >>>>
> >>>>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

JumpStart
Instead, I would be happy to switch to embedded TomEE, instead of embedded Jetty, if that’s practical and there are good step-by-step instructions.

For me, I just need to know what to put into web/src/test/conf/, RunTomEE.java (like my RunJetty.java), which jars to use, and essential system properties.

For a wider audience, IMHO something like this page about Jetty would be great:

        https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty <https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty>

> On 1 Jun 2017, at 7:37 PM, Romain Manni-Bucau <[hidden email]> wrote:
>
> think i know what's happening, not really sure how to solve properly it
> since it can be due to your integration: jetty is mutating the context
> packages (how new InitialContext() is resolved) and indeed we use jetty
> JNDI space instead of openejb one which has the binding. Maybe try starting
> openejb before jetty or enforcing openejb package first
> in javax.naming.Context#URL_PKG_PREFIXES system property (I'm not sure
> there the manipulation jetty does)
>
>
> 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 13:27 GMT+02:00 JumpStart <[hidden email]>:
>
>> Wow, you are fast. That workaround works. Thank you very much.
>>
>> Geoff
>>
>>> On 1 Jun 2017, at 6:55 PM, Romain Manni-Bucau <[hidden email]>
>> 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 <[hidden email]>
>>>> 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 <
>> [hidden email]>
>>>>>> 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 <
>> [hidden email]
>>>>>
>>>>>>> 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 <
>>>> [hidden email]>
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

Romain Manni-Bucau
Hi

Does http://tomee.apache.org/advanced/tomee-embedded/ helps?


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-02 5:45 GMT+02:00 JumpStart <[hidden email]>:

> Instead, I would be happy to switch to embedded TomEE, instead of embedded
> Jetty, if that’s practical and there are good step-by-step instructions.
>
> For me, I just need to know what to put into web/src/test/conf/,
> RunTomEE.java (like my RunJetty.java), which jars to use, and essential
> system properties.
>
> For a wider audience, IMHO something like this page about Jetty would be
> great:
>
>         https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty <
> https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty>
>
> > On 1 Jun 2017, at 7:37 PM, Romain Manni-Bucau <[hidden email]>
> wrote:
> >
> > think i know what's happening, not really sure how to solve properly it
> > since it can be due to your integration: jetty is mutating the context
> > packages (how new InitialContext() is resolved) and indeed we use jetty
> > JNDI space instead of openejb one which has the binding. Maybe try
> starting
> > openejb before jetty or enforcing openejb package first
> > in javax.naming.Context#URL_PKG_PREFIXES system property (I'm not sure
> > there the manipulation jetty does)
> >
> >
> > 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 13:27 GMT+02:00 JumpStart <geoff.callender.jumpstart@
> gmail.com>:
> >
> >> Wow, you are fast. That workaround works. Thank you very much.
> >>
> >> Geoff
> >>
> >>> On 1 Jun 2017, at 6:55 PM, Romain Manni-Bucau <[hidden email]>
> >> 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 <
> [hidden email]>
> >>>> 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 <
> >> [hidden email]>
> >>>>>> 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 <
> >> [hidden email]
> >>>>>
> >>>>>>> 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 <
> >>>> [hidden email]>
> >>>>>>>> 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
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

JumpStart
Yes, but not as a starting point. It is mostly a reference document, whereas I need a "getting started guide”, with a really basic, working example that tells me:

- What to put in my conf/ directory. I presume tomee.xml is required, but is it, and does it need to be modified?
- What to put in my RunTomEE class. Will the example find my tommy.xml? Does it need to? How will it find my exploded WAR that’s in collapsed EAR format? That page leaves me guessing.
- Which jars need to be in the classpath. I have absolutely no idea, and I’d rather not include everything from tomee's lib.
- What’s a good set of system properties to set. There are so many possible combinations, so I’d like to be given initial ones that work.

I did actually try working from that page a couple of days ago, but had to abandon it after a lot of trial and error, and I’m still left with all the above questions unanswered.

Geoff

> On 2 Jun 2017, at 2:08 PM, Romain Manni-Bucau <[hidden email]> wrote:
>
> Hi
>
> Does http://tomee.apache.org/advanced/tomee-embedded/ helps?
>
>
> 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-02 5:45 GMT+02:00 JumpStart <[hidden email]>:
>
>> Instead, I would be happy to switch to embedded TomEE, instead of embedded
>> Jetty, if that’s practical and there are good step-by-step instructions.
>>
>> For me, I just need to know what to put into web/src/test/conf/,
>> RunTomEE.java (like my RunJetty.java), which jars to use, and essential
>> system properties.
>>
>> For a wider audience, IMHO something like this page about Jetty would be
>> great:
>>
>>        https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty <
>> https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty>
>>
>>> On 1 Jun 2017, at 7:37 PM, Romain Manni-Bucau <[hidden email]>
>> wrote:
>>>
>>> think i know what's happening, not really sure how to solve properly it
>>> since it can be due to your integration: jetty is mutating the context
>>> packages (how new InitialContext() is resolved) and indeed we use jetty
>>> JNDI space instead of openejb one which has the binding. Maybe try
>> starting
>>> openejb before jetty or enforcing openejb package first
>>> in javax.naming.Context#URL_PKG_PREFIXES system property (I'm not sure
>>> there the manipulation jetty does)
>>>
>>>
>>> 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 13:27 GMT+02:00 JumpStart <geoff.callender.jumpstart@
>> gmail.com>:
>>>
>>>> Wow, you are fast. That workaround works. Thank you very much.
>>>>
>>>> Geoff
>>>>
>>>>> On 1 Jun 2017, at 6:55 PM, Romain Manni-Bucau <[hidden email]>
>>>> 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 <
>> [hidden email]>
>>>>>> 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 <
>>>> [hidden email]>
>>>>>>>> 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 <
>>>> [hidden email]
>>>>>>>
>>>>>>>>> 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 <
>>>>>> [hidden email]>
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrading OpenEJB Standalone to 7.0.3

Romain Manni-Bucau
2017-06-02 9:01 GMT+02:00 JumpStart <[hidden email]>:

> Yes, but not as a starting point. It is mostly a reference document,
> whereas I need a "getting started guide”, with a really basic, working
> example that tells me:
>

Hmm, have to admit I would appreciate once you get it working some help to
improve that area of the doc


>
> - What to put in my conf/ directory. I presume tomee.xml is required, but
> is it, and does it need to be modified?
>

Well depends, I'm tempted to say conf folder doesnt have to exist by
default, tomee.xml is fully replaceable by properties syntax but you can
point to any tomee.xml with openejb.location flag.


> - What to put in my RunTomEE class. Will the example find my tommy.xml?
> Does it need to? How will it find my exploded WAR that’s in collapsed EAR
> format? That page leaves me guessing.
>

there is a conf option which will check at classpath or file path,
deployClasspath will deploy the classpath but you can also define as
properties or in tomee.xml a Deployments of what to deploy. That said I
think you can deploy the classpath (even if it can require a small
adjustment of the packaging worse case) which will make your app easier to
debug, run and package.


> - Which jars need to be in the classpath. I have absolutely no idea, and
> I’d rather not include everything from tomee's lib.
>

Well tomee-embedded is tomee so you need tomee stack, you can create a
maven pom with tomee-embedded dependency and just run mvn
dependency:copy-dependencies to get the full stack, there are few parts you
can exclude like activemq but that's it mainly.


> - What’s a good set of system properties to set. There are so many
> possible combinations, so I’d like to be given initial ones that work.
>

Nothing special until you need it.


>
> I did actually try working from that page a couple of days ago, but had to
> abandon it after a lot of trial and error, and I’m still left with all the
> above questions unanswered.
>
> Geoff
>
> > On 2 Jun 2017, at 2:08 PM, Romain Manni-Bucau <[hidden email]>
> wrote:
> >
> > Hi
> >
> > Does http://tomee.apache.org/advanced/tomee-embedded/ helps?
> >
> >
> > 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-02 5:45 GMT+02:00 JumpStart <[hidden email]
> >:
> >
> >> Instead, I would be happy to switch to embedded TomEE, instead of
> embedded
> >> Jetty, if that’s practical and there are good step-by-step instructions.
> >>
> >> For me, I just need to know what to put into web/src/test/conf/,
> >> RunTomEE.java (like my RunJetty.java), which jars to use, and essential
> >> system properties.
> >>
> >> For a wider audience, IMHO something like this page about Jetty would be
> >> great:
> >>
> >>        https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty <
> >> https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty>
> >>
> >>> On 1 Jun 2017, at 7:37 PM, Romain Manni-Bucau <[hidden email]>
> >> wrote:
> >>>
> >>> think i know what's happening, not really sure how to solve properly it
> >>> since it can be due to your integration: jetty is mutating the context
> >>> packages (how new InitialContext() is resolved) and indeed we use jetty
> >>> JNDI space instead of openejb one which has the binding. Maybe try
> >> starting
> >>> openejb before jetty or enforcing openejb package first
> >>> in javax.naming.Context#URL_PKG_PREFIXES system property (I'm not sure
> >>> there the manipulation jetty does)
> >>>
> >>>
> >>> 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 13:27 GMT+02:00 JumpStart <geoff.callender.jumpstart@
> >> gmail.com>:
> >>>
> >>>> Wow, you are fast. That workaround works. Thank you very much.
> >>>>
> >>>> Geoff
> >>>>
> >>>>> On 1 Jun 2017, at 6:55 PM, Romain Manni-Bucau <[hidden email]
> >
> >>>> 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 <
> >> [hidden email]>
> >>>>>> 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 <
> >>>> [hidden email]>
> >>>>>>>> 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 <
> >>>> [hidden email]
> >>>>>>>
> >>>>>>>>> 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 <
> >>>>>> [hidden email]>
> >>>>>>>>>> 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
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Loading...