tomee-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Zowalla (JIRA)" <>
Subject [jira] [Commented] (TOMEE-2143) AbstractOwbBean.destroy(..) hits NPE in MyFaces 2.2.12 when cleaning up a user's Session and related "ViewScopeBeanHolder"
Date Wed, 15 Nov 2017 12:33:00 GMT


Richard Zowalla commented on TOMEE-2143:

Any ideas on this issue so far?

> AbstractOwbBean.destroy(..) hits NPE in MyFaces 2.2.12 when cleaning up a user's Session
and related  "ViewScopeBeanHolder"
> ---------------------------------------------------------------------------------------------------------------------------
>                 Key: TOMEE-2143
>                 URL:
>             Project: TomEE
>          Issue Type: Bug
>          Components: TomEE Core Server
>    Affects Versions: 7.0.3, 7.0.4
>         Environment: TomEE 7.0.4 (plus)
> MyFaces 2.2.12, Omnifaces 2.6.5
> Shiro 1.3.2
> Java 1.8.0-U151 (Oracle)
> MacOS 10.13
>            Reporter: Martin Wiesner
> In an *EAR*-bundled application with several EJB jars and two WAR files, when I logout
from my JSF-application via this piece of code here:
> {code:java}
>     public void logout() throws IOException {
>         SecurityUtils.getSubject().logout();
>         Faces.invalidateSession();
>         Faces.redirect("login.xhtml");
>     }
> {code}
> The moment the user session is invalidated, the redirect to the login screen is triggered
sucessfully. However, I encounter the following stack trace within my standalone installation
of TomEE plus (taken from catalina.out):
> {code:java}
> [http-nio-8080-exec-8] org.apache.webbeans.component.AbstractOwbBean.destroy Exception
thrown while destroying bean instance : [ViewScopeBeanHolder, WebBeansType:MANAGED, Name:null,
API Types:[org.apache.myfaces.cdi.view.ViewScopeBeanHolder,java.lang.Object,],
>  java.lang.NullPointerException
> 	at org.apache.myfaces.cdi.view.ViewScopeContextImpl.destroyAllActive(
> 	at org.apache.myfaces.cdi.view.ViewScopeContextImpl.destroyAllActive(
> 	at org.apache.myfaces.cdi.view.ViewScopeBeanHolder.destroyBeansOnPreDestroy(
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> 	at java.lang.reflect.Method.invoke(
> 	at org.apache.webbeans.intercept.LifecycleInterceptorInvocationContext.proceed(
> 	at org.apache.webbeans.portable.InjectionTargetImpl.preDestroy(
> 	at org.apache.webbeans.component.AbstractOwbBean.destroy(
> 	at org.apache.webbeans.context.AbstractContext.destroyInstance(
> 	at org.apache.webbeans.context.AbstractContext.destroyInstance(
> 	at org.apache.webbeans.context.AbstractContext.destroy(
> 	at org.apache.webbeans.web.context.WebContextsService.destroyRequestContext(
> 	at org.apache.openejb.cdi.CdiAppContextsService.destroyRequestContext(
> 	at org.apache.webbeans.web.context.WebContextsService.endContext(
> 	at org.apache.openejb.server.httpd.BeginWebBeansListener.requestDestroyed(
> 	at org.apache.catalina.core.StandardContext.fireRequestDestroyEvent(
> 	at org.apache.catalina.core.StandardHostValve.invoke(
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(
> 	at org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCapturer.invoke(
> 	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(
> 	at org.apache.catalina.core.StandardEngineValve.invoke(
> 	at org.apache.catalina.connector.CoyoteAdapter.service(
> 	at org.apache.coyote.http11.Http11Processor.service(
> 	at org.apache.coyote.AbstractProcessorLight.process(
> 	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
> 	at$SocketProcessor.doRun(
> 	at
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(
> 	at java.util.concurrent.ThreadPoolExecutor$
> 	at org.apache.tomcat.util.threads.TaskThread$
> {code}
> h3. Observations: 
> 1. Interestingly, this only appears with the EAR bundle. When started as a standalone
WAR bundle from "webapps" folder or via the _tomee-maven-plugin_ the exceptions do not occur.

> 2. A re-login can be conducted successfully. Yet, most request result in a 500 error
as ViewScoped beans got errors such as: " javax.enterprise.context.ContextNotActiveException:
WebBeans context with scope type annotation @SessionScoped does not exist within current thread"
and the web-application becomes unusable...
> 3. When using "Mojarra" instead of the pre-bundled (i.e., container-wide) MyFaces JSF
implementation (in version 2.2.x or 2.3.x) it also does not occur, neither in EAR nor WAR
use cases.
> 4. Somehow, it seems to be a mix of OpenWebBeans, TomEE (EAR) and MyFaces problem...
> I found this discussion, which seems pretty similar to what I observe here:
> This thread discusses on observations made in TomEE 7.0.2. So, as there was no official
fix/solution back then, I suspect other versions such as 7.0.2 and 7.0.3 might also be affected.
I will confirm on this via comments.
> Looking for a solution/fix for the EAR variant (like [~acornett] in the aforementioned
thread) as this is production code which can't be broken into it's pieces. The problem/solution
offered by him "Creating/modifying the session in JASPIC login code...." does not apply to
my case, as I do not (willingly) modify the session on login code.
> Any help much appreciated.

This message was sent by Atlassian JIRA

View raw message