[
https://issues.apache.org/jira/browse/TOMEE-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Wiesner updated TOMEE-2143:
----------------------------------
Environment:
TomEE 7.0.4 (plus)
MyFaces 2.2.12, Omnifaces 2.6.8
Shiro 1.4.0
Java 1.8.0-U171 (OpenJDK / Oracle)
OS: MacOS 10.13.x, Windows 10 (1607, 1709, 1803)
was:
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
> AbstractOwbBean.destroy(..) hits NPE in MyFaces 2.2.12 when cleaning up a
> user's Session and related "ViewScopeBeanHolder"
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: TOMEE-2143
> URL: https://issues.apache.org/jira/browse/TOMEE-2143
> 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.8
> Shiro 1.4.0
> Java 1.8.0-U171 (OpenJDK / Oracle)
> OS: MacOS 10.13.x, Windows 10 (1607, 1709, 1803)
> Reporter: Martin Wiesner
> Priority: Major
>
> 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.io.Serializable],
> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]]
> java.lang.NullPointerException
> at
> org.apache.myfaces.cdi.view.ViewScopeContextImpl.destroyAllActive(ViewScopeContextImpl.java:229)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextImpl.destroyAllActive(ViewScopeContextImpl.java:223)
> at
> org.apache.myfaces.cdi.view.ViewScopeBeanHolder.destroyBeansOnPreDestroy(ViewScopeBeanHolder.java:221)
> 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:498)
> at
> org.apache.webbeans.intercept.LifecycleInterceptorInvocationContext.proceed(LifecycleInterceptorInvocationContext.java:103)
> at
> org.apache.webbeans.portable.InjectionTargetImpl.preDestroy(InjectionTargetImpl.java:352)
> at
> org.apache.webbeans.component.AbstractOwbBean.destroy(AbstractOwbBean.java:179)
> at
> org.apache.webbeans.context.AbstractContext.destroyInstance(AbstractContext.java:206)
> at
> org.apache.webbeans.context.AbstractContext.destroyInstance(AbstractContext.java:192)
> at
> org.apache.webbeans.context.AbstractContext.destroy(AbstractContext.java:218)
> at
> org.apache.webbeans.web.context.WebContextsService.destroyRequestContext(WebContextsService.java:408)
> at
> org.apache.openejb.cdi.CdiAppContextsService.destroyRequestContext(CdiAppContextsService.java:113)
> at
> org.apache.webbeans.web.context.WebContextsService.endContext(WebContextsService.java:223)
> at
> org.apache.openejb.server.httpd.BeginWebBeansListener.requestDestroyed(BeginWebBeansListener.java:99)
> at
> org.apache.catalina.core.StandardContext.fireRequestDestroyEvent(StandardContext.java:5974)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
> at
> org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCapturer.invoke(OpenEJBSecurityListener.java:97)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1457)
> at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> {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:
> http://tomee-openejb.979440.n4.nabble.com/Intermittent-ViewScoped-Bean-Errors-td4680554.html
> 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
(v7.6.3#76005)
