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 <[email protected]> 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 <[email protected]>:
>
>> Wow, you are fast. That workaround works. Thank you very much.
>>
>> Geoff
>>
>>> On 1 Jun 2017, at 6:55 PM, Romain Manni-Bucau <[email protected]>
>> 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 <[email protected]>
>>>> 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 <
>> [email protected]>
>>>>>> 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 <
>> [email protected]
>>>>>
>>>>>>> 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 <
>>>> [email protected]>
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
