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 Fri, 02 Jun 2017 06:08:14 GMT
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 <geoff.callender.jumpstart@gmail.com>:

> 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 <rmannibucau@gmail.com>
> 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 <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