JSF warning is logged before custom exception handler is called (Glassfish/Payara)

[Timothy Falconer]

I've written a custom exception handler for JSF, and it works correctly. The exception I'm trying to handle is getting caught and processed correctly by the handler.

My problem is that the following warning is put in the log file BEFORE the exception handler is called, which I don't want.

I have tried changing the log levels for the exception, FacesException, and ConsoleHandler, and it's STILL showing the warning.

I'm using Payara 4.1.2.172.

Ideas?

---

[2017-09-15T09:43:38.621-0400] [Payara 4.1] [WARNING] [] [javax.enterprise.resource.webcontainer.jsf.lifecycle] [tid: _ThreadID=33 _ThreadName=http-thread-pool::http-listener-1(5)] [timeMillis: 1505483018621] [levelValue: 900] [[
  #{ myController.doCreateFoldersSave }: net.client.project.exceptions.XCannotExport
javax.faces.FacesException: #{ myController.doCreateFoldersSave }: net.client.project.exceptions.XCannotExport
    at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118)
    at javax.faces.component.UICommand.broadcast(UICommand.java:315)
    at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
    at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
    at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1606)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:258)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:654)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:593)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
    at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:371)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:466)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:169)
    at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
    at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
    at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573)
    at java.lang.Thread.run(Thread.java:745)
Caused by: javax.faces.el.EvaluationException: net.client.project.exceptions.XCannotExport
    at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:101)
    at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
    ... 35 more
Caused by: net.client.project.exceptions.XCannotExport
    at net.client.project.export.CtBaseExport.open(CtBaseExport.java:79)
    at net.client.project.cases.MyController.doCreateFoldersSave(CtCaseController.java:2461)
    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 com.sun.el.parser.AstValue.invoke(AstValue.java:289)
    at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
    at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
    at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
    at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
    at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87)
    ... 36 more
]]

[Timothy Falconer]

(edit) This seems to work, but I'm not happy about such a global change:

asadmin set-log-levels javax.enterprise.resource.webcontainer.jsf.lifecycle=SEVERE

[Ondrej Mihályi]

Hi,

The exception net.client.project.exceptions.XCannotExport doesn't seem to come from Payara Server. Is this exception defined in your application?

Ondro

--
You received this message because you are subscribed to the Google Groups "Payara Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to payara-forum+unsubscribe@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/payara-forum/07a85098-79d7-460e-a242-c34a392a5f51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Timothy Falconer]

Yes, this is the exception I'm handling correctly in my custom exception handler.  That part works.  It's the logging of the exception before reaching the handler that's the problem.

To unsubscribe from this group and stop receiving emails from it, send an email to payara-forum...@googlegroups.com.

[Korbinian]

can it be related to https://github.com/payara/Payara/issues/1886 ?

To unsubscribe from this group and stop receiving emails from it, send an email to payara-forum...@googlegroups.com.

[Ondrej Mihályi]

I agree with Korbinian, it seems to be the same or similar issue as in https://github.com/payara/Payara/issues/1886

Timothy, would you please upload a test project to the github issue, which demonstrates the unnecessary warning messages? We will test if the fix for the original issue also fixes this issue and if not, we'll try to fix it too.

As a workaround, you should be able to hide the warnings by configuring the logger javax.enterprise.resource.webcontainer.jsf.lifecycle to the level SEVERE.

Ondro

[Timothy Falconer]

Ondro, thanks.  I had already figured out the lifecycle=SEVERE thing.  Will make the test case when I have time.