Issues with Attachments: week of 2010-12-06
CXF - Monday, December 6, 2010 7 Issues with Attachments (sorted oldest to newest) [CXF-3005] Add support for jsonp in CXF JAX-RS - Created: 2010-09-22 - Updated: 2010-11-11 - Type: New Feature - Fix Versions: [] - Reporter: Josh Holtzman - Assigned: Unassigned - Attachments: [cxf_jsonp.diff] - https://issues.apache.org:443/jira/browse/CXF-3005 [CXF-3040] Upgrade to XMLBeans 2.5.0 - Created: 2010-10-06 - Updated: 2010-11-09 - Type: Improvement - Fix Versions: [] - Reporter: Stephane Nicoll - Assigned: Unassigned - Attachments: [CXF_JAR_FILES.pdf] - https://issues.apache.org:443/jira/browse/CXF-3040 [CXF-3113] Meaningful Exception for HTTP Exceptions - Created: 2010-11-08 - Updated: 2010-11-15 - Type: Improvement - Fix Versions: [] - Reporter: Sébastien - Assigned: Unassigned - Attachments: [com.bsb.sf.sample.service.math.ws.HelloWorldWebServiceTestIt.txt] - https://issues.apache.org:443/jira/browse/CXF-3113 [CXF-3145] Refactor toSQL method as visitor pattern - Created: 2010-11-21 - Updated: 2010-11-24 - Type: Improvement - Fix Versions: [] - Reporter: Brian Topping - Assigned: Unassigned - Attachments: [cxf3145.patch] - https://issues.apache.org:443/jira/browse/CXF-3145 [CXF-3156] Have web service client cache SAML tokens used in SOAP calls - Created: 2010-11-29 - Updated: 2010-12-01 - Type: Wish - Fix Versions: [] - Reporter: Glen Mazza - Assigned: Unassigned - Attachments: [20101129DoubleItMetroWSTrust.zip] - https://issues.apache.org:443/jira/browse/CXF-3156 [CXF-3160] Reduce Code duplication between http transport variants - Created: 2010-12-01 - Updated: 2010-12-05 - Type: Improvement - Fix Versions: [] - Reporter: Christian Schneider - Assigned: Christian Schneider - Attachments: [CXF-3160-1.patch, CXF-3160-2.patch] - https://issues.apache.org:443/jira/browse/CXF-3160 [CXF-3161] Marshalling object fails with JAXB and CXF, throws nullpointerexception - Created: 2010-12-02 - Updated: 2010-12-02 - Type: Bug - Fix Versions: [] - Reporter: Paul Jutten - Assigned: Unassigned - Attachments: [JaxBProject.zip] - https://issues.apache.org:443/jira/browse/CXF-3161
[jira] Updated: (CXF-3095) Jax WS - Schema Locations are ignored since CXF-2851 was implemented
[
https://issues.apache.org/jira/browse/CXF-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Claude Souvignet updated CXF-3095:
---
Attachment: wsVal.zip
wsVal.zip maven project that iluustrate this issue
> Jax WS - Schema Locations are ignored since CXF-2851 was implemented
>
>
> Key: CXF-3095
> URL: https://issues.apache.org/jira/browse/CXF-3095
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.10, 2.2.11
> Environment: running in tomcat 6
>Reporter: Patrick Leamon
> Fix For: NeedMoreInfo
>
> Attachments: wsVal.zip
>
>
> I'm having very odd schema validation issues since moving from cxf 2.0.11 to
> cxf 2.2.10.
> The beans.xml I'm using to configure the web service looks something like:
> {code:xml}
> implementor="com.blah.LocationServiceImpl"
> address="/services/location">
>
>
>
>
>
> classpath:xsd/common-types.xsd
>
> classpath:xsd/location-types..xsd
>
> classpath:xsd/location-service.xsd
>
>
> {code}
> The first five requests that I send to this web service function correctly.
> Any further requests result in:
> Unmarshalling Error: cvc-elt.1: Cannot find the declaration of element
> 'ns1:locationElement'
> Previously in 2.0.11 this was working fine, regardless of the number of
> requests being sent.
> *edit* Reverting to 2.2.9 works perfectly. It looks like the code path that
> reads in schemaLocations was disabled by the fix to CXF-2851.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3095) Jax WS - Schema Locations are ignored since CXF-2851 was implemented
[
https://issues.apache.org/jira/browse/CXF-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12967131#action_12967131
]
Jean-Claude Souvignet commented on CXF-3095:
Hi,
I have same issue :
org.apache.cxf.interceptor.Fault: Marshalling Error: cvc-elt.1: Cannot find the
declaration of element 'ckReponse'.
I test with CXF 2.2.7, 2.2.9 et 2.2.10.
A complete maven project that illustrate it is joined (wsVal.zip)
Do there are a way to validate only the request and not the response ?
> Jax WS - Schema Locations are ignored since CXF-2851 was implemented
>
>
> Key: CXF-3095
> URL: https://issues.apache.org/jira/browse/CXF-3095
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.10, 2.2.11
> Environment: running in tomcat 6
>Reporter: Patrick Leamon
> Fix For: NeedMoreInfo
>
> Attachments: wsVal.zip
>
>
> I'm having very odd schema validation issues since moving from cxf 2.0.11 to
> cxf 2.2.10.
> The beans.xml I'm using to configure the web service looks something like:
> {code:xml}
> implementor="com.blah.LocationServiceImpl"
> address="/services/location">
>
>
>
>
>
> classpath:xsd/common-types.xsd
>
> classpath:xsd/location-types..xsd
>
> classpath:xsd/location-service.xsd
>
>
> {code}
> The first five requests that I send to this web service function correctly.
> Any further requests result in:
> Unmarshalling Error: cvc-elt.1: Cannot find the declaration of element
> 'ns1:locationElement'
> Previously in 2.0.11 this was working fine, regardless of the number of
> requests being sent.
> *edit* Reverting to 2.2.9 works perfectly. It looks like the code path that
> reads in schemaLocations was disabled by the fix to CXF-2851.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3160) Reduce Code duplication between http transport variants
[ https://issues.apache.org/jira/browse/CXF-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12967159#action_12967159 ] Sergey Beryozkin commented on CXF-3160: --- Hi Christian I was involved a bit awhile back into the discussions surrounding query handlers. Example, CXF offers a default WSDLQueryHandler and someone can write a custom one and which will be used instead of it. But generally, the query handlers are for handling HTTP queries, those starting with '?' and thus it would make sense IMHO to keep them dealing with HTTP queries only. I would not 'overload' them. As far as service listings are concerned - please note that it is possible to configure CXFServlet to use alternative path segments for service listings, ex, "/listings" instead of '/services'. There could be a jaxrs system test verifying it, but mentioning it just in case. It would be nice to make it easy for users to customize the way the service listings are presented, such that a user handler or custom servlet extending CXFServlet can be presented with all the information needed to build a view. cheers, Sergey > Reduce Code duplication between http transport variants > --- > > Key: CXF-3160 > URL: https://issues.apache.org/jira/browse/CXF-3160 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.3.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Attachments: CXF-3160-1.patch, CXF-3160-2.patch > > > We still have to much duplicated or very similar code in the http transports. > Moving header code from AbstractHttpDestination to Headers > Moving invokeDestination from ServletController to AbstractServletController > to share this code with http-osgi > Moving invoke from ServletDestination to AbstractHttpDestination to share > this code with http-osgi > Removing doMessage from OsgiDestination > Removing invokeDestination from OsgiServletcontroller > Ignoring some mock based tests that do not work anymore. Will have to do some > work on them > There are some small changes in the behaviour for http-osgi as we are now > using the servlet code here. It would be great if Sergey or Dan could review > this. Idon´t think the differences are important but I am not sure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3167) Provide access to incoming message when processing an outgoing message
Provide access to incoming message when processing an outgoing message
--
Key: CXF-3167
URL: https://issues.apache.org/jira/browse/CXF-3167
Project: CXF
Issue Type: Improvement
Components: Core
Affects Versions: 2.3.0
Reporter: Oliver Wulff
CXF can act as an intermediary where it is on the one hand a service provider
and on the other hand the service implementation consumes other services.
Within the outgoing interceptor chain (service consumer) it must get access to
the incoming message.
An interceptor can access the incoming message with the following API:
message.get("PREVIOUS_MESSAGE");
Implementation proposal:
...
private Message previousMessage;
...
private PhaseInterceptorChain(PhaseInterceptorChain src) {
...
//
previousMessage = PhaseInterceptorChain.getCurrentMessage();
if (previousMessage != null) {
LOG.fine("Previous message available");
} else {
LOG.finest("No previous message available");
}
...
@SuppressWarnings("unchecked")
public synchronized boolean doIntercept(Message message) {
updateIterator();
pausedMessage = message;
// add the incoming message to the current message
if (previousMessage != null) {
message.put("PREVIOUS_MESSAGE", previousMessage);
}
Message oldMessage = CURRENT_MESSAGE.get();
...
have to do some testing on this
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3150) WebApplicationException and Response do not implement a useful toString()/getMessage() method
[ https://issues.apache.org/jira/browse/CXF-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3150. --- Resolution: Fixed Fix Version/s: 2.4 2.3.2 Assignee: Sergey Beryozkin I've introduced two exception classes. One is ServerWebApplicationException which extends WebApplicationException and make it easy to get to the status, headers, and the response message if any. ServerWebApplicationException is thrown only if the request has actually been made and the server returned a status >=400. The other one is ClientWebApplicationException which is thrown in cases when no request has actually been made for whatever reasons. It extends the RuntimeException. Thus the client code which expects WebApplicationException be thrown even when no request has been made will become broken given this change. However - as you rightly noticed, WebApplicationException currently thrown on 2.3.0/2.3.1 are of little use in case of the client errors - thus I think this change is actually fixing an issue and thus is needed. Note - you do not have to use ServerWebApplicationException if you need to check the status, etc. You can get a JAX-RS Response from WebApplicationException too, ServerWebApplicationException just makes it easier to deal with the Response. Besides, you can always get to the underlying response even with catching a runtime exception, this code will work for proxies : Client client = WebClient.client(proxy); // this one works for WebClient client.getResponse() Finally - you can register a custom WebApplicationExceptionMapper on the server side and include a stack trace if you wish - CXF JAX-RS just does not sent the actual code details by default. http://svn.apache.org/viewvc?rev=1042724&view=rev Any comments - let me know please thanks, Sergey > WebApplicationException and Response do not implement a useful > toString()/getMessage() method > - > > Key: CXF-3150 > URL: https://issues.apache.org/jira/browse/CXF-3150 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.3.0 >Reporter: Dobes Vandermeer >Assignee: Sergey Beryozkin > Fix For: 2.3.2, 2.4 > > > When using the client API, the WebApplicationExceptions are very opaque, it > just says "WebApplicationException". > It would be nice if the printStackTrace() on these would, without additional > work, print out at least the status code and possibly the response body if it > meets some criteria (any way I can send back a useful error message from the > server would be great). The WebApplicationExceptions thrown by the client > itself also seem to be lacking much useful information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3168) Usage of whitespace in @Path regular expressions raises service deployment errors
Usage of whitespace in @Path regular expressions raises service deployment
errors
-
Key: CXF-3168
URL: https://issues.apache.org/jira/browse/CXF-3168
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.3.0
Reporter: Glen Mazza
Priority: Minor
Fix For: 2.3.1
See: http://www.corneliadavis.com/blog/index.php/tag/rest-cxf-regex/
The following regular expression works fine (for an elephant maintenance system
at a zoo):
@Path("/{id:\\d+}")
public Person getElephantSubresource(@PathParam("id") int id);
However, placing spaces around the colon delimiter as follows:
@Path("/{id : \\d+}")
public Person getElephantSubresource(@PathParam("id") int id);
... causes these exceptions to occur at service deployment time:
org.springframework.beans.PropertyBatchUpdateException; nested
PropertyAccessExceptions (1) are:
PropertyAccessException 1: org.springframework.beans.MethodInvocationException:
Property 'serviceBeans' threw exception; nested exception is
java.util.regex.PatternSyntaxException: Illegal repetition near index 0
/{id : \d+}(/.*)?
^
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1361)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1086)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:22
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.util.regex.PatternSyntaxException: Illegal repetition near
index 0
/{id : \d+}(/.*)?
^
at java.util.regex.Pattern.error(Pattern.java:1713)
at java.util.regex.Pattern.closure(Pattern.java:2775)
at java.util.regex.Pattern.sequence(Pattern.java:1889)
at java.util.regex.Pattern.expr(Pattern.java:1752)
at java.util.regex.Pattern.compile(Pattern.java:1460)
at java.util.regex.Pattern.(Pattern.java:1133)
at java.util.regex.Pattern.compile(Pattern.java:823)
at org.apache.cxf.jaxrs.model.URITemplate.(URITemplate.java:89)
at
org.apache.cxf.jaxrs.model.URITemplate.createTemplate(URITemplate.java:302)
at
org.apache.cxf.jaxrs.model.URITemplate.createTemplate(URITemplate.java:289)
at
org.apache.cxf.jaxrs.utils.ResourceUtils.createOperationInfo(ResourceUtils.java:328)
at
org.apache.cxf.jaxrs.utils.ResourceUtils.evaluateResourceClass(ResourceUtils.java:204)
The version with spaces is as shown on page 47 of Bill Burke's RESTFul Java
with JAX-RS book (O'Reilly).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3095) Jax WS - Schema Locations are ignored since CXF-2851 was implemented
[
https://issues.apache.org/jira/browse/CXF-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968435#action_12968435
]
Jason Mihalick commented on CXF-3095:
-
Ok, my earlier comments are still valid. I have confirmed that my schemas
configured under the schemaLocation elements are being picked up because when I
change the name of a schema file to something invalid, I get an error from cxf
saying "Could not load schema". So the schemas are being detected, but at
runtime when parsing they are not being passed down in to the XMLSchemaFactory.
> Jax WS - Schema Locations are ignored since CXF-2851 was implemented
>
>
> Key: CXF-3095
> URL: https://issues.apache.org/jira/browse/CXF-3095
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.10, 2.2.11
> Environment: running in tomcat 6
>Reporter: Patrick Leamon
> Fix For: NeedMoreInfo
>
> Attachments: wsVal.zip
>
>
> I'm having very odd schema validation issues since moving from cxf 2.0.11 to
> cxf 2.2.10.
> The beans.xml I'm using to configure the web service looks something like:
> {code:xml}
> implementor="com.blah.LocationServiceImpl"
> address="/services/location">
>
>
>
>
>
> classpath:xsd/common-types.xsd
>
> classpath:xsd/location-types..xsd
>
> classpath:xsd/location-service.xsd
>
>
> {code}
> The first five requests that I send to this web service function correctly.
> Any further requests result in:
> Unmarshalling Error: cvc-elt.1: Cannot find the declaration of element
> 'ns1:locationElement'
> Previously in 2.0.11 this was working fine, regardless of the number of
> requests being sent.
> *edit* Reverting to 2.2.9 works perfectly. It looks like the code path that
> reads in schemaLocations was disabled by the fix to CXF-2851.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3169) Duplicate declaration for namespace prefix 'tns'
Duplicate declaration for namespace prefix 'tns'
Key: CXF-3169
URL: https://issues.apache.org/jira/browse/CXF-3169
Project: CXF
Issue Type: Bug
Affects Versions: 2.3.0
Environment: Windows XP, Server 2003, 2008. WebSphere Portal, WebLogic
Reporter: Mark Brewer
Fix For: 2.3.0
Receiving the following error:
[12/6/10 17:05:28:140 EST] 0068 PhaseIntercep I Interceptor has thrown
exception, unwinding now Unmarshalling Error: Duplicate declaration for
namespace prefix 'tns'.
at [row,col {unknown-source}]: [1,506]
[12/6/10 17:05:28:187 EST] 0068 DispatcherPor E
org.springframework.web.portlet.FrameworkPortlet processRequest Could not
complete request
javax.xml.ws.WebServiceException:
org.apache.cxf.interceptor.Fault: Unmarshalling Error: Duplicate declaration
for namespace prefix 'tns'.
at [row,col {unknown-source}]: [1,506]
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:142)
at $Proxy1218.retrieveRegionList(Unknown Source)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3168) Usage of whitespace in @Path regular expressions raises service deployment errors
[
https://issues.apache.org/jira/browse/CXF-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-3168.
---
Resolution: Fixed
Fix Version/s: (was: 2.3.1)
2.4
2.3.2
Assignee: Sergey Beryozkin
> Usage of whitespace in @Path regular expressions raises service deployment
> errors
> -
>
> Key: CXF-3168
> URL: https://issues.apache.org/jira/browse/CXF-3168
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.0
>Reporter: Glen Mazza
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 2.3.2, 2.4
>
>
> See: http://www.corneliadavis.com/blog/index.php/tag/rest-cxf-regex/
> The following regular expression works fine (for an elephant maintenance
> system at a zoo):
> @Path("/{id:\\d+}")
> public Person getElephantSubresource(@PathParam("id") int id);
> However, placing spaces around the colon delimiter as follows:
> @Path("/{id : \\d+}")
> public Person getElephantSubresource(@PathParam("id") int id);
> ... causes these exceptions to occur at service deployment time:
> org.springframework.beans.PropertyBatchUpdateException; nested
> PropertyAccessExceptions (1) are:
> PropertyAccessException 1:
> org.springframework.beans.MethodInvocationException: Property 'serviceBeans'
> threw exception; nested exception is java.util.regex.PatternSyntaxException:
> Illegal repetition near index 0
> /{id : \d+}(/.*)?
> ^
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1361)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1086)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:22
>
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.util.regex.PatternSyntaxException: Illegal repetition near
> index 0
> /{id : \d+}(/.*)?
> ^
> at java.util.regex.Pattern.error(Pattern.java:1713)
> at java.util.regex.Pattern.closure(Pattern.java:2775)
> at java.util.regex.Pattern.sequence(Pattern.java:1889)
> at java.util.regex.Pattern.expr(Pattern.java:1752)
> at java.util.regex.Pattern.compile(Pattern.java:1460)
> at java.util.regex.Pattern.(Pattern.java:1133)
> at java.util.regex.Pattern.compile(Pattern.java:823)
> at org.apache.cxf.jaxrs.model.URITemplate.(URITemplate.java:89)
> at
> org.apache.cxf.jaxrs.model.URITemplate.createTemplate(URITemplate.java:302)
> at
> org.apache.cxf.jaxrs.model.URITemplate.createTemplate(URITemplate.java:289)
> at
> org.apache.cxf.jaxrs.utils.ResourceUtils.createOperationInfo(ResourceUtils.java:328)
> at
> org.apache.cxf.jaxrs.utils.ResourceUtils.evaluateResourceClass(ResourceUtils.java:204)
> The version with spaces is as shown on page 47 of Bill Burke's RESTFul Java
> with JAX-RS book (O'Reilly).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3150) WebApplicationException and Response do not implement a useful toString()/getMessage() method
[ https://issues.apache.org/jira/browse/CXF-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968490#action_12968490 ] Dobes Vandermeer commented on CXF-3150: --- Looks good, thanks! That'll save some time when writing unit tests. > WebApplicationException and Response do not implement a useful > toString()/getMessage() method > - > > Key: CXF-3150 > URL: https://issues.apache.org/jira/browse/CXF-3150 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.3.0 >Reporter: Dobes Vandermeer >Assignee: Sergey Beryozkin > Fix For: 2.3.2, 2.4 > > > When using the client API, the WebApplicationExceptions are very opaque, it > just says "WebApplicationException". > It would be nice if the printStackTrace() on these would, without additional > work, print out at least the status code and possibly the response body if it > meets some criteria (any way I can send back a useful error message from the > server would be great). The WebApplicationExceptions thrown by the client > itself also seem to be lacking much useful information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3170) NullPointerException in StaxUtils.java:961
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
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.
