cxf-issues mailing list archives

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

    [ https://issues.apache.org/jira/browse/CXF-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984878#action_12984878
] 

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 {http://soap.comm.server.appinterface.seagullsw.com/}LdeWebServiceProviderService
has thrown exception, unwinding now
        java.lang.NullPointerException
            at org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:961)
            at org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:949)
            at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:185)

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
way..

----
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

Was:
<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">
                  <Item>
                        <New id="Contexts" class="org.eclipse.jetty.server.handler.ContextHandlerCollection">
                             ...All out current handlers like FileFilterHandler, SoapServlet,
etc
                        </New>      
                  </Item>
                  <Item>
                        <New id="DefaultHandler" class="org.eclipse.jetty.server.handler.DefaultHandler"
/>
                  </Item>

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 StaxUtils.java:961
> ------------------------------------------
>
>                 Key: CXF-3170
>                 URL: https://issues.apache.org/jira/browse/CXF-3170
>             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(StaxUtils.java:961)
> 	at org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:949)
> 	at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:185)
> 	at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:73)
> 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:247)
> 	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113)
> 	at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97)
> 	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:458)
> 	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:146)
> 	at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148)
> 	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> 	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:108)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
> 	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> 	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:527)
> 	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:423)
> 	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:930)
> 	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:358)
> 	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:866)
> 	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> 	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:245)
> 	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113)
> 	at org.eclipse.jetty.server.Server.handle(Server.java:351)
> 	at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:594)
> 	at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1042)
> 	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549)
> 	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211)
> 	at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:424)
> 	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:506)
> 	at org.eclipse.jetty.util.thread.OldQueuedThreadPool$PoolThread.run(OldQueuedThreadPool.java:524)
> {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.


Mime
View raw message