[jira] Resolved: (CXF-3326) Fixed the test error of simple frontend
[ https://issues.apache.org/jira/browse/CXF-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CXF-3326. --- Resolution: Fixed Fix Version/s: 2.2.13 > Fixed the test error of simple frontend > --- > > Key: CXF-3326 > URL: https://issues.apache.org/jira/browse/CXF-3326 > Project: CXF > Issue Type: Bug > Components: Simple Frontend >Affects Versions: 2.2.12, 2.3.2 >Reporter: Willem Jiang >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.2.13, 2.4, 2.3.3 > > > RountripTest will be failed if it is ran after the SpringBeansTest. > Here is the mail thread[1] which discuses about it. > [1]http://cxf.547215.n5.nabble.com/Build-failure-td3378497.html -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (CXF-3325) Logging interceptors should show the HTTP method
[ https://issues.apache.org/jira/browse/CXF-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CXF-3325: - Assignee: Willem Jiang > Logging interceptors should show the HTTP method > > > Key: CXF-3325 > URL: https://issues.apache.org/jira/browse/CXF-3325 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 2.3.2 >Reporter: Dobes Vandermeer >Assignee: Willem Jiang > > The LoggingInInterceptor and LoggingOutInterceptor do not log the HTTP method > being used. I think it would be useful to log this, especially for REST > services where its common to use alternative HTTP methods (PUT, POST, GET) > compared to SOAP where it's pretty much always a POST. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (CXF-3325) Logging interceptors should show the HTTP method
[ https://issues.apache.org/jira/browse/CXF-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CXF-3325. --- Resolution: Fixed Fix Version/s: 2.3.3 2.4 > Logging interceptors should show the HTTP method > > > Key: CXF-3325 > URL: https://issues.apache.org/jira/browse/CXF-3325 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 2.3.2 >Reporter: Dobes Vandermeer >Assignee: Willem Jiang > Fix For: 2.4, 2.3.3 > > > The LoggingInInterceptor and LoggingOutInterceptor do not log the HTTP method > being used. I think it would be useful to log this, especially for REST > services where its common to use alternative HTTP methods (PUT, POST, GET) > compared to SOAP where it's pretty much always a POST. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3112) Further problem with cookies in Jax-RS (similar to closed issue 3035)
[
https://issues.apache.org/jira/browse/CXF-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993020#comment-12993020
]
stephan moeller commented on CXF-3112:
--
Sorry for posting on this issue again. We tested with CXF Version 2.3.2 and
received splitted cookie informations again, maybe the patch got lost? As a
workaround we (locally) modified
AbstractClient.setResponseBuilder
boolean splitPossible = !(HttpHeaders.SET_COOKIE
.equalsIgnoreCase(entry.getKey()) && entry.getValue()
.get(0).toUpperCase().contains(HttpHeaders.EXPIRES.toUpperCase()));
Our problem was that the cookie has 'expires' and it was checked against
'Expires' ...
> Further problem with cookies in Jax-RS (similar to closed issue 3035)
> -
>
> Key: CXF-3112
> URL: https://issues.apache.org/jira/browse/CXF-3112
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.0, 2.2.11
>Reporter: David Hagar
>Assignee: Sergey Beryozkin
> Fix For: 2.2.12, 2.3.1, 2.4
>
> Attachments: 3112_patch.diff
>
>
> Prior to version 2.2.11, multiple cookies were not handled properly by the
> method
> org.apache.cxf.jaxrs.client.AbstractClient#setResponseBuilder(HttpURLConnection,
> Exchange) -- this was resolved for some cookies, but it still breaks for
> others. Specifically, any cookie that contains an "Expires" field now gets
> split into two objects by the aforementioned method.
> For example, if the header is:
> Set-Cookie: com.wm.visitor=10789493347; Domain=.walmart.com; Expires=Thu,
> 01-Oct-2020 23:44:22 GMT; Path=/
> Then response.getMetadata().get("Set-Cookie"); will return an array of length
> 2, with values = {" com.wm.visitor=10789493347; Domain=.walmart.com;
> Expires=Thu", "01-Oct-2020 23:44:22 GMT; Path=/"
> I'm pretty sure this is a conflict of the code looking for date related
> headers conflicting with the code looking for cookie related headers.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3112) Further problem with cookies in Jax-RS (similar to closed issue 3035)
[
https://issues.apache.org/jira/browse/CXF-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993036#comment-12993036
]
Sergey Beryozkin commented on CXF-3112:
---
there's no entry.getKey().toUpperCase() in the code on the trunk :-), will
update it today. Thanks
> Further problem with cookies in Jax-RS (similar to closed issue 3035)
> -
>
> Key: CXF-3112
> URL: https://issues.apache.org/jira/browse/CXF-3112
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.0, 2.2.11
>Reporter: David Hagar
>Assignee: Sergey Beryozkin
> Fix For: 2.2.12, 2.3.1, 2.4
>
> Attachments: 3112_patch.diff
>
>
> Prior to version 2.2.11, multiple cookies were not handled properly by the
> method
> org.apache.cxf.jaxrs.client.AbstractClient#setResponseBuilder(HttpURLConnection,
> Exchange) -- this was resolved for some cookies, but it still breaks for
> others. Specifically, any cookie that contains an "Expires" field now gets
> split into two objects by the aforementioned method.
> For example, if the header is:
> Set-Cookie: com.wm.visitor=10789493347; Domain=.walmart.com; Expires=Thu,
> 01-Oct-2020 23:44:22 GMT; Path=/
> Then response.getMetadata().get("Set-Cookie"); will return an array of length
> 2, with values = {" com.wm.visitor=10789493347; Domain=.walmart.com;
> Expires=Thu", "01-Oct-2020 23:44:22 GMT; Path=/"
> I'm pretty sure this is a conflict of the code looking for date related
> headers conflicting with the code looking for cookie related headers.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CXF-3112) Further problem with cookies in Jax-RS (similar to closed issue 3035)
[
https://issues.apache.org/jira/browse/CXF-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin reopened CXF-3112:
---
> Further problem with cookies in Jax-RS (similar to closed issue 3035)
> -
>
> Key: CXF-3112
> URL: https://issues.apache.org/jira/browse/CXF-3112
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.0, 2.2.11
>Reporter: David Hagar
>Assignee: Sergey Beryozkin
> Fix For: 2.2.12, 2.3.1, 2.4
>
> Attachments: 3112_patch.diff
>
>
> Prior to version 2.2.11, multiple cookies were not handled properly by the
> method
> org.apache.cxf.jaxrs.client.AbstractClient#setResponseBuilder(HttpURLConnection,
> Exchange) -- this was resolved for some cookies, but it still breaks for
> others. Specifically, any cookie that contains an "Expires" field now gets
> split into two objects by the aforementioned method.
> For example, if the header is:
> Set-Cookie: com.wm.visitor=10789493347; Domain=.walmart.com; Expires=Thu,
> 01-Oct-2020 23:44:22 GMT; Path=/
> Then response.getMetadata().get("Set-Cookie"); will return an array of length
> 2, with values = {" com.wm.visitor=10789493347; Domain=.walmart.com;
> Expires=Thu", "01-Oct-2020 23:44:22 GMT; Path=/"
> I'm pretty sure this is a conflict of the code looking for date related
> headers conflicting with the code looking for cookie related headers.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3315) WSDL namespace becomes "http://www.springframework.org/schema/beans" after setting jaxws:endpoint attribute "serviceName"
[
https://issues.apache.org/jira/browse/CXF-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993110#comment-12993110
]
Alvin Chee commented on CXF-3315:
-
Thanks a bunch.
> WSDL namespace becomes "http://www.springframework.org/schema/beans"; after
> setting jaxws:endpoint attribute "serviceName"
> -
>
> Key: CXF-3315
> URL: https://issues.apache.org/jira/browse/CXF-3315
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.3.2
> Environment: Tomcat 5.5.32, JDK 1.5.22, Windows XP
>Reporter: Alvin Chee
>
> I've described the changes made that have caused the issue below. By default,
> the service name is SecurityEndpointImplService, which is actually " implementation>Service". I would like to set it as "SecurityService", but
> somehow it changed the target namespace in the WSDL to spring? Please advise
> a workaround if this is the expected behavior.
>
>implementorClass="com.zsg.security.endpoint.impl.SecurityEndpointImpl"
> implementor="#securityEndpoint" address="/SecurityService">
>
>implementorClass="com.zsg.security.endpoint.impl.SecurityEndpointImpl"
> serviceName="SecurityService"
> implementor="#securityEndpoint" address="/SecurityService">
>
> targetNamespace="http://impl.endpoint.security.zsg.com/";>
>
> targetNamespace="http://www.springframework.org/schema/beans";>
>
> @WebService(name = "SecurityService")
> @SOAPBinding(
> style = SOAPBinding.Style.DOCUMENT,
> use = SOAPBinding.Use.LITERAL,
> parameterStyle = ParameterStyle.WRAPPED
> )
> public interface SecurityEndpoint {
> // more code
> }
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CXF-3315) WSDL namespace becomes "http://www.springframework.org/schema/beans" after setting jaxws:endpoint attribute "serviceName"
[
https://issues.apache.org/jira/browse/CXF-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alvin Chee closed CXF-3315.
---
Resolution: Not A Problem
> WSDL namespace becomes "http://www.springframework.org/schema/beans"; after
> setting jaxws:endpoint attribute "serviceName"
> -
>
> Key: CXF-3315
> URL: https://issues.apache.org/jira/browse/CXF-3315
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.3.2
> Environment: Tomcat 5.5.32, JDK 1.5.22, Windows XP
>Reporter: Alvin Chee
>
> I've described the changes made that have caused the issue below. By default,
> the service name is SecurityEndpointImplService, which is actually " implementation>Service". I would like to set it as "SecurityService", but
> somehow it changed the target namespace in the WSDL to spring? Please advise
> a workaround if this is the expected behavior.
>
>implementorClass="com.zsg.security.endpoint.impl.SecurityEndpointImpl"
> implementor="#securityEndpoint" address="/SecurityService">
>
>implementorClass="com.zsg.security.endpoint.impl.SecurityEndpointImpl"
> serviceName="SecurityService"
> implementor="#securityEndpoint" address="/SecurityService">
>
> targetNamespace="http://impl.endpoint.security.zsg.com/";>
>
> targetNamespace="http://www.springframework.org/schema/beans";>
>
> @WebService(name = "SecurityService")
> @SOAPBinding(
> style = SOAPBinding.Style.DOCUMENT,
> use = SOAPBinding.Use.LITERAL,
> parameterStyle = ParameterStyle.WRAPPED
> )
> public interface SecurityEndpoint {
> // more code
> }
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (CXF-3112) Further problem with cookies in Jax-RS (similar to closed issue 3035)
[
https://issues.apache.org/jira/browse/CXF-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-3112.
---
Resolution: Fixed
> Further problem with cookies in Jax-RS (similar to closed issue 3035)
> -
>
> Key: CXF-3112
> URL: https://issues.apache.org/jira/browse/CXF-3112
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.0, 2.2.11
>Reporter: David Hagar
>Assignee: Sergey Beryozkin
> Fix For: 2.4, 2.3.1, 2.2.12
>
> Attachments: 3112_patch.diff
>
>
> Prior to version 2.2.11, multiple cookies were not handled properly by the
> method
> org.apache.cxf.jaxrs.client.AbstractClient#setResponseBuilder(HttpURLConnection,
> Exchange) -- this was resolved for some cookies, but it still breaks for
> others. Specifically, any cookie that contains an "Expires" field now gets
> split into two objects by the aforementioned method.
> For example, if the header is:
> Set-Cookie: com.wm.visitor=10789493347; Domain=.walmart.com; Expires=Thu,
> 01-Oct-2020 23:44:22 GMT; Path=/
> Then response.getMetadata().get("Set-Cookie"); will return an array of length
> 2, with values = {" com.wm.visitor=10789493347; Domain=.walmart.com;
> Expires=Thu", "01-Oct-2020 23:44:22 GMT; Path=/"
> I'm pretty sure this is a conflict of the code looking for date related
> headers conflicting with the code looking for cookie related headers.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (CXF-3324) JAXRSUtils: Avoid calling Message unless it'll be logged
[ https://issues.apache.org/jira/browse/CXF-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3324. --- Resolution: Fixed Assignee: Sergey Beryozkin http://svn.apache.org/viewvc?rev=1069500&view=rev thanks > JAXRSUtils: Avoid calling Message unless it'll be logged > > > Key: CXF-3324 > URL: https://issues.apache.org/jira/browse/CXF-3324 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 2.3.2 > Environment: JDK 1.6 >Reporter: Ka-Lok Fung >Assignee: Sergey Beryozkin >Priority: Minor > Labels: JAXRSUtils, log, performance > Fix For: 2.3.3 > > Attachments: CXF.Message.Hotspot.png > > Original Estimate: 1h > Remaining Estimate: 1h > > Our performance and reliability testing has shown that Message.toString() is > called many times in JAXRSUtils.selectResourceClass and > JAXRSUtils.findTargetMethod. It takes up 2.5% of our CPU when these messages > aren't even being logged. An image from the profiler showing this hotspot is > attached. > According to our tests, if you pre-check if the message is loggable (e.g., if > (LOG.isLoggable(Level.FINE))) and logging is set to the default level, the > throughput is increased by 2% and the CPU time is reduced by an equal amount. > The lines where this change would have the most impact are indicated in the > image. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3308) WS-RM change to use long instead of BigInteger for sequence numbers
[ https://issues.apache.org/jira/browse/CXF-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993229#comment-12993229 ] Dennis Sosnoski commented on CXF-3308: -- Attached patch against trunk Revision: 1069343 > WS-RM change to use long instead of BigInteger for sequence numbers > --- > > Key: CXF-3308 > URL: https://issues.apache.org/jira/browse/CXF-3308 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Reporter: Dennis Sosnoski > Attachments: final-long.diff > > > The current WS-RM code uses BigInteger for all sequence numbers, making the > code to compare and work with sequence numbers very cumbersome. Changing to > long values would still allow for over 291,271 years of continuous operation > at 1 million operations per second, so is probably sufficient. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CXF-3308) WS-RM change to use long instead of BigInteger for sequence numbers
[ https://issues.apache.org/jira/browse/CXF-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Sosnoski updated CXF-3308: - Attachment: final-long.diff > WS-RM change to use long instead of BigInteger for sequence numbers > --- > > Key: CXF-3308 > URL: https://issues.apache.org/jira/browse/CXF-3308 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Reporter: Dennis Sosnoski > Attachments: final-long.diff > > > The current WS-RM code uses BigInteger for all sequence numbers, making the > code to compare and work with sequence numbers very cumbersome. Changing to > long values would still allow for over 291,271 years of continuous operation > at 1 million operations per second, so is probably sufficient. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
ExceptionMapper causing subsequent ClassCastExceptions
I have a service method like this:
@Override
@POST
@Path("/model/create")
public Long createModel(Model model)
{
...
}
I registered an exception mapper like this:
public class CustomWebApplicationExceptionMapper extends
AbstractRestExceptionMapper implements
ExceptionMapper {
@Override
public Response toResponse(WebApplicationException exception)
{
Response response =
Response.status(Response.Status.BAD_REQUEST).type(MediaType.APPLICATION_XML).entity(someString).build();
return response;
}
...
}
}
And registered the mapper as a jaxrs:provider:
...
I have verified that in the debugger my exception mapper is getting called
and the expected response generated. Unfortunately when this response is
sent back to the client the JAXRSOutInterceptor is triggering a
ClassCastException. It appears to be because the service method returns a
Long and the Response object is a String. I changed the service method
return type above from a Long to a String and the class cast goes away.
How can I use an ExceptionMapper for any method, regardless of its return
type?
--
View this message in context:
http://cxf.547215.n5.nabble.com/ExceptionMapper-causing-subsequent-ClassCastExceptions-tp3379990p3379990.html
Sent from the cxf-issues mailing list archive at Nabble.com.
[jira] Updated: (CXF-3308) WS-RM change to use long instead of BigInteger for sequence numbers
[ https://issues.apache.org/jira/browse/CXF-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Sosnoski updated CXF-3308: - Attachment: distribution-long.diff Separate patch for distribution folder (MessageLossSimulator.java). > WS-RM change to use long instead of BigInteger for sequence numbers > --- > > Key: CXF-3308 > URL: https://issues.apache.org/jira/browse/CXF-3308 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Reporter: Dennis Sosnoski > Attachments: distribution-long.diff, final-long.diff > > > The current WS-RM code uses BigInteger for all sequence numbers, making the > code to compare and work with sequence numbers very cumbersome. Changing to > long values would still allow for over 291,271 years of continuous operation > at 1 million operations per second, so is probably sufficient. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
