tomee-users mailing list archives

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message