cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <>
Subject [jira] Commented: (CXF-3170) NullPointerException in
Date Fri, 21 Jan 2011 19:17:44 GMT


Gary Gregory commented on CXF-3170:

Hi Daniel,

I do not have a test case for this and creating one is not something I can take the time to
do ATM. 

What I can give you is a description of what we were doing based on message I dug up when
we were dealing with this issue.

Here it goes.

Sent: Monday, December 06, 2010 09:17

There is a story about NPE exception .

    2010-11-25 22:59:59,275 [28@qtp0-4] WARN : Interceptor for {}LdeWebServiceProviderService
has thrown exception, unwinding now
            at org.apache.cxf.staxutils.StaxUtils.readDocElements(
            at org.apache.cxf.staxutils.StaxUtils.readDocElements(
            at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(

The chain of actions, which cause an error:
1)	I have opened page with url http://localhost:8070/wsdl.
2)	After that browser is restarting. When the browser had started It tries to get favion.ico
for our page. In our  case- http://localhost:8070/favicon.ico
3)	Jetty.xml config was set up to handle all requests to port 8070 with SoapServletCxf (It
has context defined to "/*").  And there is no surprise that we got NPE in it. 
(in case with validations we also get validation error)

I see 2 ways how we can solve this problem  :

1)	Change context of SoapServletCxf from ("/*") to ("smth/*"). And accordantly we should change
ContextPath of FileFilterResourseHandler to "smth/wsdl". 
But in this case we will get some problems in LWSB ( e.g. we will get "Connection refused"
 in attempt to connect to LDE through SOAP)
2)	We can change SoapServletCxf to make one ignore favicon.ico request. But IMO it's not good

Sent: Tuesday, December 07, 2010 10:58

I found the way how we can solve "favicon problem" with some config changing and without changing
of any contextPaths. 
Jetty has special class for this purposes - org.eclipse.jetty.server.handler.DefaultHandler.
It will serve the requests which was not handled by other handlers. (like "/favicon.ico")
But in this case we need to change a little bit structure of our  jetty.xml

<Configure class="org.eclipse.jetty.server.Server" id="Server">
      <Set name="handler">
            <New class="org.eclipse.jetty.server.handler.ContextHandlerCollection">
                  ...All out current handlers like FileFilterHandler, SoapServlet, etc

Now (New code In bold.):

<Configure class="org.eclipse.jetty.server.Server" id="Server">

<Set name="handler">
      <New id="Handlers" class="org.eclipse.jetty.server.handler.ContextHandlerCollection">
            <Set name="handlers">
            <Array type="org.eclipse.jetty.server.Handler">
                        <New id="Contexts" class="org.eclipse.jetty.server.handler.ContextHandlerCollection">
                             ...All out current handlers like FileFilterHandler, SoapServlet,
                        <New id="DefaultHandler" class="org.eclipse.jetty.server.handler.DefaultHandler"

So we need to add  DefaultHandler on the same level as old ContextHandlerCollection and wrap
these handlers up by new ContextHandlerCollection. 

P.S. In additional - in DefaultHandler  we can set option whether we should serve favicon
and show icon or not...
Sent: Tuesday, December 14, 2010 14:41

Testing show that, unfortunately,  this scheme with jetty.xml doesn't work.  (see prev emails)

ContextHandlerCollection (CHC ) use contexts of all contained handlers.
Our CHC  can handle the following contexts:
1)	/wsdl   (FileFilterHandler)
2)	/*  (SoapServlet)
3)	DefaultHandler wich doesn't has context and uses in the root context. 

When we get request /favicon.ico it will execute  SoapServlet to handle it. Because of context
So far we have SoapServlet with context "/*" I see only one way to solve "favicon problem"
through Jetty config.
I think we need to add  context "/favicon.ico" for DefaultHandler.  Like this:

            <New class="org.eclipse.jetty.server.handler.ContextHandler">
                  <Set name="ContextPath">/favicon.ico</Set>
                  <Set name="handler">
                  <New id="DefaultHandler" class="org.eclipse.jetty.server.handler.DefaultHandler">

May be it looks like not good solution, but I don't see another way. 

> NullPointerException in
> ------------------------------------------
>                 Key: CXF-3170
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>    Affects Versions: 2.3.1
>         Environment: Java version: 1.6.0_21
> Java home: C:\Program Files\Java\jdk1.6.0_21\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows"
>            Reporter: Gary Gregory
>             Fix For: NeedMoreInfo
> We get the following NPE:
> {noformat}
> java.lang.NullPointerException
> 	at org.apache.cxf.staxutils.StaxUtils.readDocElements(
> 	at org.apache.cxf.staxutils.StaxUtils.readDocElements(
> 	at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(
> 	at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(
> 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> 	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(
> 	at org.apache.cxf.transport.servlet.ServletDestination.invoke(
> 	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(
> 	at org.apache.cxf.transport.servlet.ServletController.invoke(
> 	at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(
> 	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(
> 	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(
> 	at javax.servlet.http.HttpServlet.service(
> 	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(
> 	at org.eclipse.jetty.servlet.ServletHolder.handle(
> 	at org.eclipse.jetty.servlet.ServletHandler.doHandle(
> 	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(
> 	at org.eclipse.jetty.servlet.ServletHandler.doScope(
> 	at org.eclipse.jetty.server.handler.ContextHandler.doScope(
> 	at org.eclipse.jetty.server.handler.ScopedHandler.handle(
> 	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(
> 	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> 	at org.eclipse.jetty.server.Server.handle(
> 	at org.eclipse.jetty.server.HttpConnection.handleRequest(
> 	at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(
> 	at org.eclipse.jetty.http.HttpParser.parseNext(
> 	at org.eclipse.jetty.http.HttpParser.parseAvailable(
> 	at org.eclipse.jetty.server.HttpConnection.handle(
> 	at
> 	at org.eclipse.jetty.util.thread.OldQueuedThreadPool$
> {noformat}
> This is due to the way we configure Jetty and CXF in a jetty.xml file, so it our fault
so to speak.
> BUT, it would be nice to either get: a civilized error message or some default fall through
behavior (that does not blow up in an NPE)
> But still

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message