search

payara / Payara

Payara Server is an open source middleware platform that supports reliable and secure deployments of Java EE (Jakarta EE) and MicroProfile applications in any environment: on premise, in the cloud or hybrid.
http://www.payara.fish
Other
883 stars 306 forks source link

NPE in FilterDefDecorator #1905

Closed beachmountain closed 7 years ago

beachmountain commented 7 years ago

Description

We have a server/client application where the server side is a Java EE application deployed in Payara. With version 173 of Payara the client can no longer connect to the server (it worked in version 172).

Expected Outcome

The client should be able to connect to the server.

Current Outcome

The client can not connect to the server. The server logs this error message each time the client tries to connect:

[2017-08-25T14:42:31.594+0200] [Payara 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=41 _ThreadName=http-thread-pool::http-listener-1(2)] [timeMillis: 1503664951594] [levelValue: 900] [[
  StandardWrapperValve[cometd]: Servlet.service() for servlet cometd threw exception
java.lang.NullPointerException
    at com.sun.enterprise.web.deploy.FilterDefDecorator.isAsyncSupported(FilterDefDecorator.java:117)
    at org.apache.catalina.core.ApplicationFilterConfig.isAsyncSupported(ApplicationFilterConfig.java:180)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:225)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
    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:480)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:180)
    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(Unknown Source)
]]

Debugging the FilterDefDecorator tells me that the classname of the problem filter is "org.jboss.weld.probe.ProbeFilter" and the filtername is "weld-probe-filter". The Boolean "asyncSupported" is null.

The org.glassfish.web.deployment.descriptor.ServletFilterDescriptor class contains these lines (72-73):

    /** async supported */
    private Boolean asyncSupported = null;

and the org.glassfish.weld.WeldDeployer class creates the Probefilter if in development mode (lines 577-589):

if (developmentMode) {
                    // if development mode enabled then for WAR register ProbeFilter and register ProbeExtension for every deployment
                    ServletFilterDescriptor servletFilter = new ServletFilterDescriptor();
                    servletFilter.setClassName(PROBE_FILTER_CLASS_NAME);
                    servletFilter.setName(PROBE_FILTER_NAME);
                    wDesc.addServletFilter(servletFilter);

                    ServletFilterMappingDescriptor servletFilterMapping = new ServletFilterMappingDescriptor();
                    servletFilterMapping.setName(PROBE_FILTER_NAME);
                    servletFilterMapping.addURLPattern(PROBE_FILTER_URL_PATTERN);
                    servletFilterMapping.addDispatcher(PROBE_FILTER_DISPATCHER_TYPE);
                    wDesc.addServletFilterMapping(servletFilterMapping);
                }

The call stack:

FilterDefDecorator.isAsyncSupported:117 
ApplicationFilterConfig.isAsyncSupported:180    
ApplicationFilterChain.internalDoFilter:225 
ApplicationFilterChain.doFilter:208 
StandardWrapperValve.invoke:256 
StandardContextValve.invoke:160 
StandardPipeline.doInvoke:654   
StandardPipeline.invoke:593 
WebPipeline.invoke:99   
StandardHostValve.invoke:155    
CoyoteAdapter.doService:371 
CoyoteAdapter.service:238   
ContainerMapper$HttpHandlerCallable.call:480    
ContainerMapper.service:180 
Hidden Source Calls 
Thread.run

I have tried to disable the "CDI Development Mode" option for our application (with restart and redeploy), and made sure debug mode is off in the JVM settings, but still get the same error.

Steps to reproduce (Only for bug reports)

Sorry but I can't give you this as our software is proprietary.

Samples

N/A

Environment

mikecroft commented 7 years ago

Hello,

I understand that you can't share source code but we will need to know roughly what's happening or we can't help. How could we reproduce your scenario? You say it's client/server and I can see you're using cometd, but how is it implemented?

If you can't even share that detail, then probably the only thing I could suggest is a support contract where we can discuss things with you under a signed NDA. Our professional level of support includes phone support and screensharing. You can either buy online or send an email to sales@payara.fish

beachmountain commented 7 years ago

Hi,

Thank you for your reply!

I can understand that you need more details, I was kinda hoping the stack trace would contain something that made the problem easy to spot, but I know that was a long shot. I will let our developers look further into this and see if it is something we can solve ourselves. You can close the issue if you want to, and if we come up with enough information so that you can reproduce this I will add that information to this issue in the future.

smillidge commented 7 years ago

I'm afraid the stack trace doesn't really help. Just says the filter for the filter definition is null. Which tbh is pretty weird given it is passed in in the constructor and accessed in the constructor. I would suggest debugging https://github.com/payara/Payara/blob/master/appserver/web/web-glue/src/main/java/com/sun/enterprise/web/deploy/FilterDefDecorator.java if it is difficult to reproduce in a test case.

beachmountain commented 7 years ago

Thank you for your kind reply. I have debugged the FilterDefDecorator and updated the issue description. Perhaps this information can be of any help. I think our problems may be related to the new feature of integration with the Weld (CDI) development mode (It seems to be turned on by default when deploying?).

I do apologize for any errors in the formatting and reporting of this issue. This is my first issue reported on Github and I am eager to improve. Debugging other code than our own is also a bit new to me. I will do my best to supply more information if needed.

smillidge commented 7 years ago

Thanks that is a big hint to us knowing that it is the new Weld Probe Filter.

smillidge commented 7 years ago

Any hints on how to reproduce the error would be good. We have tested this with many web applications and isn't causing problems. Is your Servlet asynch? Are you also registering ServletFilters? Any thing a bit out of the ordinary your web application is doing in initialisation would help.

jGauravGupta commented 7 years ago

Thanks @beachmountain for the info, I have reproduced this issue. Internal issue ref : PAYARA-2019

beachmountain commented 7 years ago

Thank you guys! Yes, our servlet is asynch. I just want to add that I discovered that we had development mode turned on in production since we in the web.xml in our War had `

org.jboss.weld.development true

` After removing this our application works as expected again.