Issues with Attachments: week of 2011-01-03
CXF - Monday, January 3, 2011 7 Issues with Attachments (sorted oldest to newest) [CXF-2770] There is no way to specify autoRewriteSoapAddress from a spring context file. - Created: 2010-04-19 - Updated: 2010-12-19 - Type: Bug - Fix Versions: [] - Reporter: Yaytay - Assigned: Unassigned - Attachments: [SpringConfigureAutoRewriteSoapAddress.diff] - https://issues.apache.org:443/jira/browse/CXF-2770 [CXF-2775] CLONE -CXF http-jetty transport do not call the jetty server engine shutdown when the server stop - Created: 2010-04-21 - Updated: 2010-12-20 - Type: Bug - Fix Versions: [] - Reporter: Chris Wilson - Assigned: Willem Jiang - Attachments: [CxfServerRestartTimeoutTest.java] - https://issues.apache.org:443/jira/browse/CXF-2775 [CXF-3129] wsdl2java: place @Generated annotation on generated code - Created: 2010-11-16 - Updated: 2010-12-30 - Type: New Feature - Fix Versions: [] - Reporter: Andrew Spencer - Assigned: Unassigned - Attachments: [Patch+for+CXF+3129+-+version+2.patch, Patch+for+CXF+3129.txt] - https://issues.apache.org:443/jira/browse/CXF-3129 [CXF-3160] Reduce Code duplication between http transport variants - Created: 2010-12-01 - Updated: 2010-12-08 - Type: Improvement - Fix Versions: [] - Reporter: Christian Schneider - Assigned: Christian Schneider - Attachments: [CXF-3160-1.patch, CXF-3160-2.patch, CXF-3160-3.patch] - https://issues.apache.org:443/jira/browse/CXF-3160 [CXF-3218] apparent regression introduced between 2.2.8 and 2.2.9: http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT not supported - Created: 2010-12-24 - Updated: 2010-12-30 - Type: Bug - Fix Versions: [] - Reporter: John J. Franey - Assigned: Unassigned - Attachments: [scencr.zip] - https://issues.apache.org:443/jira/browse/CXF-3218 [CXF-3219] WS-RMs' DestinationSequence does not update the ack range in the RMStore - Created: 2010-12-25 - Updated: 2010-12-25 - Type: Bug - Fix Versions: [2.3.2] - Reporter: Aki Yoshida - Assigned: Unassigned - Attachments: [rt-ws-rm-2.3.x-fixes-diff.txt] - https://issues.apache.org:443/jira/browse/CXF-3219 [CXF-3226] Going to a JAX-RS resource that contains a space in the path returns a 404 response code - Created: 2011-01-01 - Updated: 2011-01-01 - Type: Bug - Fix Versions: [2.3.2] - Reporter: Jason Downey - Assigned: Unassigned - Attachments: [cxf_jax_rs_space_bug.zip, patch.diff] - https://issues.apache.org:443/jira/browse/CXF-3226
[jira] Resolved: (CXF-3227) Introduce DataBinding implementation wrapping JAX-RS providers
[ https://issues.apache.org/jira/browse/CXF-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3227. --- Resolution: Fixed > Introduce DataBinding implementation wrapping JAX-RS providers > -- > > Key: CXF-3227 > URL: https://issues.apache.org/jira/browse/CXF-3227 > Project: CXF > Issue Type: Task > Components: JAX-RS >Affects Versions: 2.3.2, 2.4 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.3.2, 2.4 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3226) Going to a JAX-RS resource that contains a space in the path returns a 404 response code
[ https://issues.apache.org/jira/browse/CXF-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976859#action_12976859 ] Sergey Beryozkin commented on CXF-3226: --- Hi But what happens if you have "the%20%space" Path value or similar ? If we decode at the servlet level then we won't be able to match "the%20%space" ? Can JAX-RS Path can not contain WSPaces in the actual literal name ? Do you think this is still a valid JIRA ? thanks, Sergey > Going to a JAX-RS resource that contains a space in the path returns a 404 > response code > > > Key: CXF-3226 > URL: https://issues.apache.org/jira/browse/CXF-3226 > Project: CXF > Issue Type: Bug >Affects Versions: 2.3.1 > Environment: Java 1.6_22 > Apache CXF 2.3.1 >Reporter: Jason Downey > Fix For: 2.3.2 > > Attachments: cxf_jax_rs_space_bug.zip, patch.diff > > > If you go to a JAX-RS resource that contains a space in the path, the Apache > CXF JAX-RS runtime returns a 404 response code. In the STDERR log, you'll see > the following message: > Jan 1, 2011 3:05:01 PM org.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod > WARNING: .No operation matching request path /has%20space is found, HTTP > Method : GET, ContentType : */*, Accept : > application/xml,application/xhtml+xml,image/png,text/html;q=0.9,text/plain;q=0.8,*/*;q=0.5,. > The cause for this problem may be found in > AbstractServerController.getBaseURL. It assumes pathInfo is always decoded > but in the JAX-RS situation, it may actually still be encoded. > Relevant sample code + patch attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-3129) wsdl2java: place @Generated annotation on generated code
[ https://issues.apache.org/jira/browse/CXF-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned CXF-3129: Assignee: Daniel Kulp > wsdl2java: place @Generated annotation on generated code > > > Key: CXF-3129 > URL: https://issues.apache.org/jira/browse/CXF-3129 > Project: CXF > Issue Type: New Feature > Components: Tooling >Affects Versions: 2.3.0 >Reporter: Andrew Spencer >Assignee: Daniel Kulp >Priority: Minor > Attachments: Patch for CXF 3129 - version 2.patch, Patch for CXF > 3129.txt > > > It would be considerate on the part of CXF to place @Generated on the Java > source generated by wsdl2java. > @Generated is in the javax.annotation package and is a marker for generated > code. It allows code quality tools to ignore the generated code, as > described in this feature request for Sonar: > http://jira.codehaus.org/browse/SONAR-1042 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CXF Premature End Of File ?
Hello, I finally had time to look at this project again. I rewrote it over the christmas vacation, but still there seem to be some recursive calls. As soon as I call webservice it brings a premature end of file, because the same team is called over and over again. However, I cannot find it. Does anyone have an idea? Is the bidirectional usage of eclipselink not possible? >From what the wsdl should do now is provide a reverence between: team --> references a project team --> references a list of members Member --> references a team Member --> references a list of memberskills Alistair http://export.webservice.expertfinder.org/";> − − http://export.ifc.expertfinder.org";> − − − − − − − − − − − − − − − http://export.webservice.expertfinder.org/";> http://export.ifc.expertfinder.org"/> − − − − − − − − − http://schemas.xmlsoap.org/soap/http"/> − − − − − http://localhost:9090/expertFinder"/> -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-Premature-End-Of-File-tp3249208p3325936.html Sent from the cxf-issues mailing list archive at Nabble.com.
[jira] Resolved: (CXF-3129) wsdl2java: place @Generated annotation on generated code
[ https://issues.apache.org/jira/browse/CXF-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3129. -- Resolution: Fixed Fix Version/s: 2.3.2 Patch applied. I did fix the unit test as well as added the CXF version in the comments field of the class level annotation. Everything looked good though. Thanks! > wsdl2java: place @Generated annotation on generated code > > > Key: CXF-3129 > URL: https://issues.apache.org/jira/browse/CXF-3129 > Project: CXF > Issue Type: New Feature > Components: Tooling >Affects Versions: 2.3.0 >Reporter: Andrew Spencer >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.3.2 > > Attachments: Patch for CXF 3129 - version 2.patch, Patch for CXF > 3129.txt > > > It would be considerate on the part of CXF to place @Generated on the Java > source generated by wsdl2java. > @Generated is in the javax.annotation package and is a marker for generated > code. It allows code quality tools to ignore the generated code, as > described in this feature request for Sonar: > http://jira.codehaus.org/browse/SONAR-1042 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3175) Unmarshalling does not follow JAXB rules.
[
https://issues.apache.org/jira/browse/CXF-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-3175:
-
Fix Version/s: NeedMoreInfo
I tried to reproduce this and couldn't. Can you create a small test case and
attach it?
The common cause of something like this would be a classloader issue with the
jaxb annotations in OSGi. Not sure if that would be your case though.
> Unmarshalling does not follow JAXB rules.
> -
>
> Key: CXF-3175
> URL: https://issues.apache.org/jira/browse/CXF-3175
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.3.1
>Reporter: David J. M. Karlsen
>Priority: Blocker
> Fix For: NeedMoreInfo
>
>
> I have a soapheader element which is declared as:
> {noformat}
>
>
>
>
> {noformat}
> The JAXB2 generated code (through the cxf-codegen maven plugin will be:
> {noformat}
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "EDBHeaderType", propOrder = {
> "sourceApplication"
> })
> public class EDBHeaderType {
> @XmlElement(name = "SourceApplication", required = true)
> protected String sourceApplication;
> {noformat}
> which is OK, BUT - then I get this on service invocation from a client:
> {noformat}
> Caused by: javax.xml.bind.UnmarshalException: unexpected element
> (uri:"http://edb.com/ws/WSCommon_v21";, local:"SourceApplication"). Expected
> elements are
> <{http://edb.com<{http://edb.com/ws/WSCommon_v21}sourceApplication>
> {noformat}
> Check the casing! It expects lowercase elements, although they are declared
> uppercase. This is not correct.
> If I change it to lowercase it will in fact pass validation (but not adhere
> to the schema which declared it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2697) REST and web methods taking arguments called without argument leads to IllegalArgumentException: wrong number of arguments exception
[
https://issues.apache.org/jira/browse/CXF-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2697.
--
Resolution: Fixed
Fix Version/s: (was: 2.2.7)
2.3.2
Patch applied. thanks!
> REST and web methods taking arguments called without argument leads to
> IllegalArgumentException: wrong number of arguments exception
>
>
> Key: CXF-2697
> URL: https://issues.apache.org/jira/browse/CXF-2697
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime, JAXB Databinding
>Affects Versions: 2.2.5
> Environment: using JAXD Databinding, JAX-WS with REST
>Reporter: Dieter Freismuth
>Assignee: Daniel Kulp
> Fix For: 2.3.2
>
> Attachments: dfreis.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> if an @WebMethod taking an @WebParam argument is called without the argument
> via REST the IllegalArgumentException is thrown.
> WebMethod:
> public String sayHi(@WebParam(name="text") String text,
> @WebParam(name="text2") String text2);
> this works if only one (text or text2) parameter is given within the HTTP GET
> Rest call and the second parameter is missing.
> Does not work if both parameters are missing!
> The Reason can be found within URIMappingInterceptor.keepInOrder method' s
> first line:
> if (params == null || params.size() == 0) {
> return params;
> }
> should be replaced by:
> if (params == null) {
> return params;
> }
> this change will add all required 'null' values for all missing parameters
> given within wsdl.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3047) org.apache.cxf.interceptor.Fault: Unmarshalling Error: UndeclaredPrefix: Cannot resolve 's:string' as a QName: the prefix 's' is not declared.
[
https://issues.apache.org/jira/browse/CXF-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3047.
--
Resolution: Fixed
Fix Version/s: 2.3.2
Patch applied. Thanks!
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: UndeclaredPrefix:
> Cannot resolve 's:string' as a QName: the prefix 's' is not declared.
> --
>
> Key: CXF-3047
> URL: https://issues.apache.org/jira/browse/CXF-3047
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.10
>Reporter: Marc Giger
>Assignee: Daniel Kulp
> Fix For: 2.3.2
>
> Attachments: cxf-test.tar.gz, JAXBEncoderDecoder.java.patch
>
>
> see also https://issues.apache.org/jira/browse/CXF-2340
> I've attached a sample project (stolen from CXF-2340 and modified) to show
> the problem.
> DefaultValidationEventHandler: [FATAL_ERROR]: UndeclaredPrefix: Cannot
> resolve 's:string' as a QName: the prefix 's' is not declared.
> Location: line 4
> 07.10.2010 11:45:12 org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNUNG: Interceptor for
> {http://server.type_substitution.fromjava/}SedansServicePorts#{http://server.type_substitution.fromjava/}GetSedansOperation
> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: UndeclaredPrefix:
> Cannot resolve 's:string' as a QName: the prefix 's' is not declared.
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:773)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:624)
> at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:150)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:198)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:244)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110)
> at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178)
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:324)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> at
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)
> Caused by: javax.xml.bind.UnmarshalException
> - with linked exception:
> [org.xml.sax.SAXParseException: UndeclaredPrefix: Cannot resolve 's:string'
> as a QName: the prefix 's' is not declared.]
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:425)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.un
[jira] Resolved: (CXF-3183) http-osgi transport not registered on proper id
[ https://issues.apache.org/jira/browse/CXF-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3183. -- Resolution: Fixed Freeman already fixed this. > http-osgi transport not registered on proper id > --- > > Key: CXF-3183 > URL: https://issues.apache.org/jira/browse/CXF-3183 > Project: CXF > Issue Type: Bug >Affects Versions: 2.3.0, 2.3.1 >Reporter: Daniel Kulp >Assignee: Daniel Kulp > Fix For: 2.3.2 > > > The OSGi http transport is not propertly registered on the > http://cxf.apache.org/transports/http transportId. Thus, the > SOAPTransportFactory cannot properly map it and OSGi services fail to start. > Workaround is to add a transportId="http://schemas.xmlsoap.org/wsdl/http/"; to > the jaxws:endpoint definitions in the spring-dm beans.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-2770) There is no way to specify autoRewriteSoapAddress from a spring context file.
[
https://issues.apache.org/jira/browse/CXF-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp reassigned CXF-2770:
Assignee: Daniel Kulp
> There is no way to specify autoRewriteSoapAddress from a spring context file.
> -
>
> Key: CXF-2770
> URL: https://issues.apache.org/jira/browse/CXF-2770
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.7
>Reporter: Yaytay
>Assignee: Daniel Kulp
>Priority: Minor
> Attachments: SpringConfigureAutoRewriteSoapAddress.diff
>
>
> I need to be able to use the autoRewriteSoapAddress facility in conjunction
> with CXF.
> This:
> address="http://0.0.0.0:8080/Maths"; depends-on="jetty-factory" >
>
>
>
>
> Queried as this: http://localhost:8080/Maths?wsdl
> Produces this: http://0.0.0.0:8080/Maths*"; />
> It seems that the properties are only set on the endpoint
> (AbstractWSDLBasedEndpointFactory:176), but autoRewriteSoapAddress is looked
> for on the EndpointInfo (WSDLQueryHandler:278).
> It's not at all clear to me what the correct fix is - somehow we need to be
> able to specify properties on the EndpointInfo.
> This is a relatively minor problem for code that makes use of just CXF
> (because one can write code to iterate the endpoints, get the infos and set
> the property), but for projects that use CXF within something else it's a
> bigger problem - for example I want to use CXF with Camel, configured
> entirely with a spring context file.
> The code I use to walk the endpoints and set the property is, roughly:
> String[] serverRegistryNames = beanFactory.getBeanNamesForType(
> ServerRegistry.class );
> for ( String serverRegistryName : serverRegistryNames )
> {
> ServerRegistry serverRegistry = ( ServerRegistry )
> beanFactory.getBean( serverRegistryName );
> List servers = serverRegistry.getServers();
> for ( Server server : servers )
> {
> server.getEndpoint().getEndpointInfo().setProperty(
> "autoRewriteSoapAddress", true );
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2770) There is no way to specify autoRewriteSoapAddress from a spring context file.
[
https://issues.apache.org/jira/browse/CXF-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2770.
--
Resolution: Fixed
Fix Version/s: 2.3.2
> There is no way to specify autoRewriteSoapAddress from a spring context file.
> -
>
> Key: CXF-2770
> URL: https://issues.apache.org/jira/browse/CXF-2770
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.7
>Reporter: Yaytay
>Assignee: Daniel Kulp
>Priority: Minor
> Fix For: 2.3.2
>
> Attachments: SpringConfigureAutoRewriteSoapAddress.diff
>
>
> I need to be able to use the autoRewriteSoapAddress facility in conjunction
> with CXF.
> This:
> address="http://0.0.0.0:8080/Maths"; depends-on="jetty-factory" >
>
>
>
>
> Queried as this: http://localhost:8080/Maths?wsdl
> Produces this: http://0.0.0.0:8080/Maths*"; />
> It seems that the properties are only set on the endpoint
> (AbstractWSDLBasedEndpointFactory:176), but autoRewriteSoapAddress is looked
> for on the EndpointInfo (WSDLQueryHandler:278).
> It's not at all clear to me what the correct fix is - somehow we need to be
> able to specify properties on the EndpointInfo.
> This is a relatively minor problem for code that makes use of just CXF
> (because one can write code to iterate the endpoints, get the infos and set
> the property), but for projects that use CXF within something else it's a
> bigger problem - for example I want to use CXF with Camel, configured
> entirely with a spring context file.
> The code I use to walk the endpoints and set the property is, roughly:
> String[] serverRegistryNames = beanFactory.getBeanNamesForType(
> ServerRegistry.class );
> for ( String serverRegistryName : serverRegistryNames )
> {
> ServerRegistry serverRegistry = ( ServerRegistry )
> beanFactory.getBean( serverRegistryName );
> List servers = serverRegistry.getServers();
> for ( Server server : servers )
> {
> server.getEndpoint().getEndpointInfo().setProperty(
> "autoRewriteSoapAddress", true );
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3226) Going to a JAX-RS resource that contains a space in the path returns a 404 response code
[
https://issues.apache.org/jira/browse/CXF-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977116#action_12977116
]
Jason Downey commented on CXF-3226:
---
If you want to match @Path("the%20%space"), per RFC3986, the client should
already have encoded this parameter as "the%2520%25space" and then the JAX-RS
runtime should appropriately find the resource.
Looking @ the JAX-RS 1.1 specification, @Path can contain spaces! If you look
at page 14 (in section 3.4), there is this sample:
1 @Path("widget list/{id}")
2 @Path("widget%20list/{id}")
The specification states that these two lines are equivalent.
In my humble opinion (and I'll defer to you since you know the code way better
than me), the key problem that needs to be addressed is that the base URL value
needs to be calculated correctly. The fix doesn't necessarily have to be in
AbstractServerController. You could subclass AbstractServerController and then
provide your own implementation of getBaseURL to do the appropriate work. This
ServerController would then only be used within CXFNonSpringJaxrsServlet.
On the JIRA question, yes, I think it's a valid JIRA issue but I'm welcome to
discussing that :-)
> Going to a JAX-RS resource that contains a space in the path returns a 404
> response code
>
>
> Key: CXF-3226
> URL: https://issues.apache.org/jira/browse/CXF-3226
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: Java 1.6_22
> Apache CXF 2.3.1
>Reporter: Jason Downey
> Fix For: 2.3.2
>
> Attachments: cxf_jax_rs_space_bug.zip, patch.diff
>
>
> If you go to a JAX-RS resource that contains a space in the path, the Apache
> CXF JAX-RS runtime returns a 404 response code. In the STDERR log, you'll see
> the following message:
> Jan 1, 2011 3:05:01 PM org.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod
> WARNING: .No operation matching request path /has%20space is found, HTTP
> Method : GET, ContentType : */*, Accept :
> application/xml,application/xhtml+xml,image/png,text/html;q=0.9,text/plain;q=0.8,*/*;q=0.5,.
> The cause for this problem may be found in
> AbstractServerController.getBaseURL. It assumes pathInfo is always decoded
> but in the JAX-RS situation, it may actually still be encoded.
> Relevant sample code + patch attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3216) Refactor http authentication to make it more flexible and simpler
[ https://issues.apache.org/jira/browse/CXF-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977150#action_12977150 ] Christian Schneider commented on CXF-3216: -- Committed another change to move auth stuff to a separate package. I also changed the interface of HttpAuthSupplier as we are incompatible after the move anyway. The change in the interface is not absolutely necessary. If there are objections I can roll back. > Refactor http authentication to make it more flexible and simpler > - > > Key: CXF-3216 > URL: https://issues.apache.org/jira/browse/CXF-3216 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.3.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.4 > > Attachments: CXF-3216-1.patch, CXF-3216-2.patch > > > The http authentication should be completely based on authSupplier. The > HttpConduit should simply delegate to it. > We should also remove some of the other auth config options besides > authorizationPolicy on conduit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3228) SOAPMessage does not recognize SOAPMessage.WRITE_XML_DECLARATION
SOAPMessage does not recognize SOAPMessage.WRITE_XML_DECLARATION
Key: CXF-3228
URL: https://issues.apache.org/jira/browse/CXF-3228
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Reporter: David Liu
Hi,
It could be a bug in cxf's @WebServiceProvider implementation that we cannot
control the output xml encoding by setting SOAPMessage.CHARACTER_SET_ENCODING.
The encoding ( {quote}{quote} ) response
message was not changed when I change CHARACTER_SET_ENCODING to UTF-16.
Please see my test class:
{quote}
@WebServiceProvider
@ServiceMode(value = Service.Mode.MESSAGE)
public class CalculatorProvider implements Provider {
@Override
public SOAPMessage invoke(SOAPMessage request) {
long start = System.currentTimeMillis();
System.out.println("* start at " + start);
try {
MessageFactory mf = MessageFactory.newInstance();
SOAPMessage soapMsg = mf.createMessage();
soapMsg.setProperty(SOAPMessage.CHARACTER_SET_ENCODING, "UTF-16");
soapMsg.setProperty(SOAPMessage.WRITE_XML_DECLARATION, "false");
soapMsg.getSOAPBody().addBodyElement(new QName("mytest"));
soapMsg.saveChanges();
return soapMsg;
} catch (SOAPException e) {
throw new RuntimeException(e);
}
}
public static void main(String[] args) {
System.out.println("Starting Server");
CalculatorProvider implementor = new CalculatorProvider();
String address = "http://localhost:7650/Calculator";;
Endpoint.publish(address, implementor);
}
}
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
