[jira] [Created] (FEDIZ-220) http 400 when logout with redirect to constraint
Arnaud MERGEY created FEDIZ-220:
---
Summary: http 400 when logout with redirect to constraint
Key: FEDIZ-220
URL: https://issues.apache.org/jira/browse/FEDIZ-220
Project: CXF-Fediz
Issue Type: Bug
Components: Plugin
Affects Versions: 1.4.3
Reporter: Arnaud MERGEY
I would like to redirect to a page after logout from a SAML authentication with
tomcat plugin.
I have added this in my fediz_config.xml
{code:java}
.*logout.do.*
{code}
Then when I logout, instead of being redirected as expected I have an http 400
because the redirec url (/mycontext/logout.do?display=2) is url encoded and
becomes not valid (because of / and ?).
I looked in the code and it seems to me the issue is here
org.apache.cxf.fediz.core.handler.LogoutHandler.signoutCleanup(HttpServletRequest
request, HttpServletResponse response)
line 114
{code:java}
response.sendRedirect(URLEncoder.encode(wreply, "UTF-8"));
{code}
should be replaced with
{code:java}
response.sendRedirect(response.encodeRedirectURL(wreply);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7778) WSDLToJava does not respect error code conventions in case of error by default
Radek Postołowicz created CXF-7778: -- Summary: WSDLToJava does not respect error code conventions in case of error by default Key: CXF-7778 URL: https://issues.apache.org/jira/browse/CXF-7778 Project: CXF Issue Type: Bug Reporter: Radek Postołowicz Why does WSDLToJava need some custom property to be set in order to exit with non zero status in case of errors? See: https://github.com/apache/cxf/blob/master/tools/wsdlto/core/src/main/java/org/apache/cxf/tools/wsdlto/WSDLToJava.java#L203 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7777) FastDateFormatTest fails on JDK 1.8 / EDT
[ https://issues.apache.org/jira/browse/CXF-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Cunningham closed CXF-. --- Resolution: Invalid Meant to file this against Karaf. > FastDateFormatTest fails on JDK 1.8 / EDT > - > > Key: CXF- > URL: https://issues.apache.org/jira/browse/CXF- > Project: CXF > Issue Type: Improvement >Reporter: Tom Cunningham >Priority: Major > > FastDateFormatTest fails on JDK 1.8 / EDT. It looks like the test case > tries to add 5 days to November 5th 2017, but does not account for the fact > that November 5, 2017 was a border date for daylight savings time in the US > ([https://www.timeanddate.com/time/change/usa)]. > If we add 5 days and 1 hour, I think this test should work correctly no > matter what time zone it is run in. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7777) FastDateFormatTest fails on JDK 1.8 / EDT
Tom Cunningham created CXF-: --- Summary: FastDateFormatTest fails on JDK 1.8 / EDT Key: CXF- URL: https://issues.apache.org/jira/browse/CXF- Project: CXF Issue Type: Improvement Reporter: Tom Cunningham FastDateFormatTest fails on JDK 1.8 / EDT. It looks like the test case tries to add 5 days to November 5th 2017, but does not account for the fact that November 5, 2017 was a border date for daylight savings time in the US ([https://www.timeanddate.com/time/change/usa)]. If we add 5 days and 1 hour, I think this test should work correctly no matter what time zone it is run in. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7776) Download page should not link to unreleased code
[ https://issues.apache.org/jira/browse/CXF-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-7776. -- Resolution: Fixed > Download page should not link to unreleased code > > > Key: CXF-7776 > URL: https://issues.apache.org/jira/browse/CXF-7776 > Project: CXF > Issue Type: Bug >Reporter: Sebb >Assignee: Colm O hEigeartaigh >Priority: Major > > The download page currently has links to SNAPSHOTS. > These are not formal releases. > Links to SNAPSHOTs and source repos should be confined to developer-facing > pages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-7776) Download page should not link to unreleased code
[ https://issues.apache.org/jira/browse/CXF-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-7776: Assignee: Colm O hEigeartaigh > Download page should not link to unreleased code > > > Key: CXF-7776 > URL: https://issues.apache.org/jira/browse/CXF-7776 > Project: CXF > Issue Type: Bug >Reporter: Sebb >Assignee: Colm O hEigeartaigh >Priority: Major > > The download page currently has links to SNAPSHOTS. > These are not formal releases. > Links to SNAPSHOTs and source repos should be confined to developer-facing > pages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7776) Download page should not link to unreleased code
[ https://issues.apache.org/jira/browse/CXF-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CXF-7776: -- Description: The download page currently has links to SNAPSHOTS. These are not formal releases. Links to SNAPSHOTs and source repos should be confined to developer-facing pages. > Download page should not link to unreleased code > > > Key: CXF-7776 > URL: https://issues.apache.org/jira/browse/CXF-7776 > Project: CXF > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The download page currently has links to SNAPSHOTS. > These are not formal releases. > Links to SNAPSHOTs and source repos should be confined to developer-facing > pages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7776) Download page should not link to unreleased code
[ https://issues.apache.org/jira/browse/CXF-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CXF-7776: -- Summary: Download page should not link to unreleased code (was: D) > Download page should not link to unreleased code > > > Key: CXF-7776 > URL: https://issues.apache.org/jira/browse/CXF-7776 > Project: CXF > Issue Type: Bug >Reporter: Sebb >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7776) D
Sebb created CXF-7776: - Summary: D Key: CXF-7776 URL: https://issues.apache.org/jira/browse/CXF-7776 Project: CXF Issue Type: Bug Reporter: Sebb -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7769) Cxf with spring 4.3.17 not working
[ https://issues.apache.org/jira/browse/CXF-7769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531122#comment-16531122 ] Deva Kumaresan commented on CXF-7769: - I am Out of Office with no access to emails. Please expect delay in my response. Regards, Deva +91 44 674 21256 > Cxf with spring 4.3.17 not working > -- > > Key: CXF-7769 > URL: https://issues.apache.org/jira/browse/CXF-7769 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.18 > Environment: Spring 4.3.17 > Cxf rt-core and other cxf 2.7.18 > wss4j 1.6.18 >Reporter: Deva Kumaresan >Assignee: Colm O hEigeartaigh >Priority: Critical > Labels: and, compatibility, cxf, spring > > Hi, I am upgrading spring framework version from 4.1.16 to 4.3.17 in our web > application. > I am also using cxf version 2.7.18 and mule 3.8.0 along spring in my project > . I am using maven for building the project. > When I deploy the application in jetty 8x version, it throws the below error. > I also tried upgrading the cxf versions above 3.x also. Still same problem > comes. This looks some compatibility version. FYI i am using WSS4J jar > version 1.6.18. I tried other versions too but did not work. Please assist in > correct version of cxf for spring 4.3.17 and mule 3.8.0 and relevent wss4j. > > > Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: > Unexpected exception parsing XML document from > /WEB-INF/esf_config_deploy.xml; nested exception is or > g.springframework.beans.FatalBeanException: Invalid NamespaceHandler class > [org.mule.module.cxf.config.CxfNamespaceHandler] for namespace > [http://www.mulesoft.org/schema/mule/c > xf]: problem with handler class file or dependent class; nested exception is > java.lang.NoClassDefFoundError: *org/apache/ws/security/validate/Validator* > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7775) embedded jetty websocket gets ClassCastException: org.eclipse.jetty.servlet.ServletContextHandler$Context cannot be cast to org.eclipse.jetty.webapp.WebAppContext$Context
[ https://issues.apache.org/jira/browse/CXF-7775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531119#comment-16531119 ] Colm O hEigeartaigh commented on CXF-7775: -- Do you have a test-case that we can use to reproduce the scenario? > embedded jetty websocket gets ClassCastException: > org.eclipse.jetty.servlet.ServletContextHandler$Context cannot be cast to > org.eclipse.jetty.webapp.WebAppContext$Context > -- > > Key: CXF-7775 > URL: https://issues.apache.org/jira/browse/CXF-7775 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.5 >Reporter: Bin >Priority: Major > > After upgrade from jetty 9.2.5.v20141112 to 9.4.11.v20180605 and cxf from > v3.1.5 to v3.2.5, the websocket server code used to work, now getting > ClassCastException: > > 17:08:07.810 [qtp1128117613-31] WARN org.eclipse.jetty.server.HttpChannel > [HttpChannel.java:573] [] - /websocket/ > java.lang.ClassCastException: > org.eclipse.jetty.servlet.ServletContextHandler$Context cannot be cast to > org.eclipse.jetty.webapp.WebAppContext$Context > at > org.apache.cxf.transport.websocket.jetty9.Jetty9WebSocketDestination.getServer(Jetty9WebSocketDestination.java:125) > at > org.apache.cxf.transport.websocket.jetty9.Jetty9WebSocketDestination.getWebSocketFactory(Jetty9WebSocketDestination.java:132) > at > org.apache.cxf.transport.websocket.jetty9.Jetty9WebSocketDestination.invoke(Jetty9WebSocketDestination.java:102) > at > org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) > at > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) > at > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) > at > org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:216) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at org.eclipse.jetty.server.Server.handle(Server.java:531) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) > at > org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:291) > at > org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:151) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) > at > org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) > at > org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) >
[jira] [Resolved] (CXF-7769) Cxf with spring 4.3.17 not working
[ https://issues.apache.org/jira/browse/CXF-7769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-7769. -- Resolution: Not A Problem > Cxf with spring 4.3.17 not working > -- > > Key: CXF-7769 > URL: https://issues.apache.org/jira/browse/CXF-7769 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.18 > Environment: Spring 4.3.17 > Cxf rt-core and other cxf 2.7.18 > wss4j 1.6.18 >Reporter: Deva Kumaresan >Assignee: Colm O hEigeartaigh >Priority: Critical > Labels: and, compatibility, cxf, spring > > Hi, I am upgrading spring framework version from 4.1.16 to 4.3.17 in our web > application. > I am also using cxf version 2.7.18 and mule 3.8.0 along spring in my project > . I am using maven for building the project. > When I deploy the application in jetty 8x version, it throws the below error. > I also tried upgrading the cxf versions above 3.x also. Still same problem > comes. This looks some compatibility version. FYI i am using WSS4J jar > version 1.6.18. I tried other versions too but did not work. Please assist in > correct version of cxf for spring 4.3.17 and mule 3.8.0 and relevent wss4j. > > > Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: > Unexpected exception parsing XML document from > /WEB-INF/esf_config_deploy.xml; nested exception is or > g.springframework.beans.FatalBeanException: Invalid NamespaceHandler class > [org.mule.module.cxf.config.CxfNamespaceHandler] for namespace > [http://www.mulesoft.org/schema/mule/c > xf]: problem with handler class file or dependent class; nested exception is > java.lang.NoClassDefFoundError: *org/apache/ws/security/validate/Validator* > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CXF-7774) JMS Reply Queue handles leaking on IBM MQ.
[ https://issues.apache.org/jira/browse/CXF-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531077#comment-16531077 ] Freeman Fang edited comment on CXF-7774 at 7/3/18 9:22 AM: --- Yes, at least it's the Activemq way, thought not sure about IBM implementation. Btw, the fix for CXF-7768 also closes the JMS MessageConsumer which get registered to the replyDestination, previously MessageConsumer can hold replyDestination to be closed when close the connection. Anyway, it may worth of trying the latest CXF snapshot with your testcase was (Author: ffang): Yes, at least it's the Activemq way, thought not sure IBM implementation. Btw, the fix for CXF-7768 also closes the JMS MessageConsumer which get registered to the replyDestination, previously MessageConsumer can hold replyDestination to be closed when close the connection. Anyway, if may worth of trying the latest CXF snapshot with your testcase > JMS Reply Queue handles leaking on IBM MQ. > -- > > Key: CXF-7774 > URL: https://issues.apache.org/jira/browse/CXF-7774 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.11 >Reporter: Richard McLaren >Priority: Major > > Using 3.1.11 and JMS we are seeing handles for our Reply Queue are being left > open. > This is using a SpringBoot application and IBM MQ client jars. > The most likely suspect is in JMSConduit the field > staticReplyDestination is set to null on a JMSException but the existing > MQQueue is never closed. > I have tried simulating the problem in IntelliJ by forcing a JMSException > during the SendExchange. > Should there be a "ResourceCloser.close( > staticReplyDestination);" immediately prior to setting > staticReplyDestination to null? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7774) JMS Reply Queue handles leaking on IBM MQ.
[ https://issues.apache.org/jira/browse/CXF-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531077#comment-16531077 ] Freeman Fang commented on CXF-7774: --- Yes, at least it's the Activemq way, thought not sure IBM implementation. Btw, the fix for CXF-7768 also closes the JMS MessageConsumer which get registered to the replyDestination, previously MessageConsumer can hold replyDestination to be closed when close the connection. Anyway, if may worth of trying the latest CXF snapshot with your testcase > JMS Reply Queue handles leaking on IBM MQ. > -- > > Key: CXF-7774 > URL: https://issues.apache.org/jira/browse/CXF-7774 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.11 >Reporter: Richard McLaren >Priority: Major > > Using 3.1.11 and JMS we are seeing handles for our Reply Queue are being left > open. > This is using a SpringBoot application and IBM MQ client jars. > The most likely suspect is in JMSConduit the field > staticReplyDestination is set to null on a JMSException but the existing > MQQueue is never closed. > I have tried simulating the problem in IntelliJ by forcing a JMSException > during the SendExchange. > Should there be a "ResourceCloser.close( > staticReplyDestination);" immediately prior to setting > staticReplyDestination to null? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7774) JMS Reply Queue handles leaking on IBM MQ.
[ https://issues.apache.org/jira/browse/CXF-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531053#comment-16531053 ] Richard McLaren commented on CXF-7774: -- I have had a look at the fix for CXF-7768 and if you are referring to the jmsListener.shutdown then this is not applicable since we never set up a jmsListener. This is because we do not specify a message selector. We use IBM style where correlation id is not set and the receive is based on the message id instead. Are you expecting that closing the connection will automatically close the staticReplyDestination? > JMS Reply Queue handles leaking on IBM MQ. > -- > > Key: CXF-7774 > URL: https://issues.apache.org/jira/browse/CXF-7774 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.11 >Reporter: Richard McLaren >Priority: Major > > Using 3.1.11 and JMS we are seeing handles for our Reply Queue are being left > open. > This is using a SpringBoot application and IBM MQ client jars. > The most likely suspect is in JMSConduit the field > staticReplyDestination is set to null on a JMSException but the existing > MQQueue is never closed. > I have tried simulating the problem in IntelliJ by forcing a JMSException > during the SendExchange. > Should there be a "ResourceCloser.close( > staticReplyDestination);" immediately prior to setting > staticReplyDestination to null? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
