Fwd: ApacheCon EU call for papers
All, Please see the message below regarding the ApacheCon EU call for papers. I haven't submitted anything (yet). Before I do, I'd really like to know what it is that you - the users of Tomcat - would like to hear about at this conference. To put it another way, if your line manager (or whoever would have to sign off on you attending the conference) was going to say If there are going to be presentations about Tomcat and XXX then you definitely should go what is the value of XXX? Cheers, Mark Original Message Subject: ApacheCon EU call for papers Date: Wed, 28 May 2014 12:12:02 -0400 From: Rich Bowen A reminder, now that we're in the final weeks, that the ApacheCon EU call for papers is open, and will close June 25th, end of the day in whatever timezone is latest. http://events.linuxfoundation.org//events/apachecon-europe/program/cfp Please get the word out to your dev@ and users@ mailing lists that we are looking for presentations for this event, and, if possible, reach out personally to the people that you think should be representing your project at ApacheCon this year. Remember, if you want your project represented at ApacheCon, it's up to you to hunt down those presentations. If you want to have a full track, or a half track, or even multiple days, please work with your experts to craft a track that covers the right aspects and expertise levels of your project and related projects. Thanks for anything you can to do help get the word out about the CFP, so that we can have the best ApacheCon content yet. -- Rich, conference chair http://apachecon.eu @apachecon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding user session id to access log with %S doesn't work?
On 09/06/2014 01:41, Fred Toth wrote: Hi Dan, Yes, the rest of the log is correct, and yes, I am certain I have an active session (I can see the cookie in my browser). Then something is messed up in your configuration. I've just checked this works and it does. You'll need to provide your full server.xml (comments removed please). Replace and passwords with *** or similar. Marl Thanks, Fred On 6/8/2014 4:30 PM, Daniel Mikusa wrote: On Jun 8, 2014 4:01 PM, Fred Toth ft...@synernet.com wrote: Hi, This feature is in the doc since at least tomcat 5. I'm using tomcat 7.0.47 and I just tried to add the user session id to the access log by adding %S to the pattern attribute. However, it's not working. All I'm getting is - in the log. Have to ask, but are you sure that the request has an active session? Usually when you see - it means the value is absent for that request. Is there some trick to this? I haven't found anything online or in bugzilla. Also posted to stack overflow: Not aware of any tricks. AccessLogValve is pretty straightforward. Is the rest of the log record correct? Dan http://stackoverflow.com/questions/24110188/cant-configure-tomcat-access-log-session-id-with-s Thanks, Fred - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding user session id to access log with %S doesn't work?
Mark Thomas wrote: On 09/06/2014 01:41, Fred Toth wrote: Hi Dan, Yes, the rest of the log is correct, and yes, I am certain I have an active session (I can see the cookie in my browser). Then something is messed up in your configuration. I've just checked this works and it does. You'll need to provide your full server.xml (comments removed please). Replace and passwords with *** or similar. Does the fact of having a session necessarily imply that the corresponding user is authenticated ? Marl Thanks, Fred On 6/8/2014 4:30 PM, Daniel Mikusa wrote: On Jun 8, 2014 4:01 PM, Fred Toth ft...@synernet.com wrote: Hi, This feature is in the doc since at least tomcat 5. I'm using tomcat 7.0.47 and I just tried to add the user session id to the access log by adding %S to the pattern attribute. However, it's not working. All I'm getting is - in the log. Have to ask, but are you sure that the request has an active session? Usually when you see - it means the value is absent for that request. Is there some trick to this? I haven't found anything online or in bugzilla. Also posted to stack overflow: Not aware of any tricks. AccessLogValve is pretty straightforward. Is the rest of the log record correct? Dan http://stackoverflow.com/questions/24110188/cant-configure-tomcat-access-log-session-id-with-s Thanks, Fred - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding user session id to access log with %S doesn't work?
On 09/06/2014 10:59, André Warnier wrote: Mark Thomas wrote: On 09/06/2014 01:41, Fred Toth wrote: Hi Dan, Yes, the rest of the log is correct, and yes, I am certain I have an active session (I can see the cookie in my browser). Then something is messed up in your configuration. I've just checked this works and it does. You'll need to provide your full server.xml (comments removed please). Replace any passwords with *** or similar. Does the fact of having a session necessarily imply that the corresponding user is authenticated ? No. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Decoded URL set on asynchronous request
Is there any information that I should add to this to get some help? Or should I just go straight and create a bug report for this (as this might not be a message targeting the users mailing list but Tomcat's developers)? Thanks, Jimmy On Thu, Jun 5, 2014 at 2:04 PM, Jimmy Royer jimlero...@gmail.com wrote: Hello, I am using this combo of components: * Apache Tomcat 8.0.8 * Apache CXF 2.7.11 * Servlet 3.0 * JAX-RS 2.0 * JDK 1.7.0_45 * Windows 7 * Chrome browser with the Advanced REST Client plug-in I developed some web services using REST that leverages CXF ability to do asynchronous methods, and under the hood, that uses Apache Tomcat. This is working fine overall, the setup and configuration are all good. There is one exception though. This is when I make a request to an async web service that uses a space in the URL, encoded to a %20. The encoding itself works fine, but internally, when Tomcat resumes the Servlet 3 continuation, it passes to some class the previously decoded path and sets it on the request URL. The request is then passed to the CXF layer, that expects a valid URL with no space and tries to instantiate a URL object from it, and fails. Here is the stack trace I got: 05-Jun-2014 12:33:37.426 SEVERE [http-apr-8080-exec-10] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [CXFServlet] in context with path [] threw exception [java.lang.RuntimeException: java.lang.IllegalArgumentException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents] with root cause java.net.URISyntaxException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents at java.net.URI$Parser.fail(URI.java:2829) at java.net.URI$Parser.checkChars(URI.java:3002) at java.net.URI$Parser.parseHierarchical(URI.java:3086) at java.net.URI$Parser.parse(URI.java:3034) at java.net.URI.init(URI.java:595) at java.net.URI.create(URI.java:857) at org.apache.cxf.transport.servlet.BaseUrlHelper.getBaseURL(BaseUrlHelper.java:49) at org.apache.cxf.transport.servlet.ServletController.getBaseURL(ServletController.java:78) at org.apache.cxf.transport.servlet.ServletController.updateDestination(ServletController.java:87) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:200) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:211) at javax.servlet.http.HttpServlet.service(HttpServlet.java:618) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721) at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:639) at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:605) at org.apache.catalina.core.AsyncContextImpl$1.run(AsyncContextImpl.java:208) at org.apache.catalina.core.AsyncContextImpl.doInternalDispatch(AsyncContextImpl.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:78) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:405) at org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1636) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:646) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:277) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2451) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2440) at
Re: Decoded URL set on asynchronous request
On Mon, Jun 9, 2014 at 8:46 AM, Jimmy Royer jimlero...@gmail.com wrote: Is there any information that I should add to this to get some help? Any chance you could put together a sample app or unit test to replicate the problem? Ideally without third party components like CXF. It would make it easier someone on the list to recreate the problem and thus easier for someone to help. Or should I just go straight and create a bug report for this (as this might not be a message targeting the users mailing list but Tomcat's developers)? The users list is always a good first place to start. As an FYI, don't top post. Reply inline like this, or just at the bottom. It's the convention followed on the list. Dan On Thu, Jun 5, 2014 at 2:04 PM, Jimmy Royer jimlero...@gmail.com wrote: Hello, I am using this combo of components: * Apache Tomcat 8.0.8 * Apache CXF 2.7.11 * Servlet 3.0 * JAX-RS 2.0 * JDK 1.7.0_45 * Windows 7 * Chrome browser with the Advanced REST Client plug-in I developed some web services using REST that leverages CXF ability to do asynchronous methods, and under the hood, that uses Apache Tomcat. This is working fine overall, the setup and configuration are all good. There is one exception though. This is when I make a request to an async web service that uses a space in the URL, encoded to a %20. The encoding itself works fine, but internally, when Tomcat resumes the Servlet 3 continuation, it passes to some class the previously decoded path and sets it on the request URL. The request is then passed to the CXF layer, that expects a valid URL with no space and tries to instantiate a URL object from it, and fails. Here is the stack trace I got: 05-Jun-2014 12:33:37.426 SEVERE [http-apr-8080-exec-10] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [CXFServlet] in context with path [] threw exception [java.lang.RuntimeException: java.lang.IllegalArgumentException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents] with root cause java.net.URISyntaxException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents at java.net.URI$Parser.fail(URI.java:2829) at java.net.URI$Parser.checkChars(URI.java:3002) at java.net.URI$Parser.parseHierarchical(URI.java:3086) at java.net.URI$Parser.parse(URI.java:3034) at java.net.URI.init(URI.java:595) at java.net.URI.create(URI.java:857) at org.apache.cxf.transport.servlet.BaseUrlHelper.getBaseURL(BaseUrlHelper.java:49) at org.apache.cxf.transport.servlet.ServletController.getBaseURL(ServletController.java:78) at org.apache.cxf.transport.servlet.ServletController.updateDestination(ServletController.java:87) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:200) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:211) at javax.servlet.http.HttpServlet.service(HttpServlet.java:618) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721) at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:639) at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:605) at org.apache.catalina.core.AsyncContextImpl$1.run(AsyncContextImpl.java:208) at org.apache.catalina.core.AsyncContextImpl.doInternalDispatch(AsyncContextImpl.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:78) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at
Re: Decoded URL set on asynchronous request
On 09/06/2014 13:46, Jimmy Royer wrote: Is there any information that I should add to this to get some help? Right now, no. There may be further questions as folks dig into this. Or should I just go straight and create a bug report for this (as this might not be a message targeting the users mailing list but Tomcat's developers)? No. That is likely to get closed as INVALID since - at the moment - there is not a clearly identified bug in Tomcat. There are lots of moving parts here and while there is obviously a bug somewhere, it isn't yet clear where that bug is. I suspect that most folks took a look at this and decided it was just too big / complicated to get into. Given the complexity of the situation, the effort you have taken to make the issue as clear as it is, is very much appreciated. To be honest, I doubt anyone could have written a better question given the problem. Give me a little time to dig into it and I'll get back to you with either an answer or - more likely - some specific questions or things to test. Mark Thanks, Jimmy On Thu, Jun 5, 2014 at 2:04 PM, Jimmy Royer jimlero...@gmail.com wrote: Hello, I am using this combo of components: * Apache Tomcat 8.0.8 * Apache CXF 2.7.11 * Servlet 3.0 * JAX-RS 2.0 * JDK 1.7.0_45 * Windows 7 * Chrome browser with the Advanced REST Client plug-in I developed some web services using REST that leverages CXF ability to do asynchronous methods, and under the hood, that uses Apache Tomcat. This is working fine overall, the setup and configuration are all good. There is one exception though. This is when I make a request to an async web service that uses a space in the URL, encoded to a %20. The encoding itself works fine, but internally, when Tomcat resumes the Servlet 3 continuation, it passes to some class the previously decoded path and sets it on the request URL. The request is then passed to the CXF layer, that expects a valid URL with no space and tries to instantiate a URL object from it, and fails. Here is the stack trace I got: 05-Jun-2014 12:33:37.426 SEVERE [http-apr-8080-exec-10] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [CXFServlet] in context with path [] threw exception [java.lang.RuntimeException: java.lang.IllegalArgumentException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents] with root cause java.net.URISyntaxException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents at java.net.URI$Parser.fail(URI.java:2829) at java.net.URI$Parser.checkChars(URI.java:3002) at java.net.URI$Parser.parseHierarchical(URI.java:3086) at java.net.URI$Parser.parse(URI.java:3034) at java.net.URI.init(URI.java:595) at java.net.URI.create(URI.java:857) at org.apache.cxf.transport.servlet.BaseUrlHelper.getBaseURL(BaseUrlHelper.java:49) at org.apache.cxf.transport.servlet.ServletController.getBaseURL(ServletController.java:78) at org.apache.cxf.transport.servlet.ServletController.updateDestination(ServletController.java:87) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:200) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:211) at javax.servlet.http.HttpServlet.service(HttpServlet.java:618) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721) at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:639) at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:605) at org.apache.catalina.core.AsyncContextImpl$1.run(AsyncContextImpl.java:208) at org.apache.catalina.core.AsyncContextImpl.doInternalDispatch(AsyncContextImpl.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) at
Re: Decoded URL set on asynchronous request
2014-06-05 22:04 GMT+04:00 Jimmy Royer jimlero...@gmail.com: Hello, I am using this combo of components: * Apache Tomcat 8.0.8 * Apache CXF 2.7.11 * Servlet 3.0 * JAX-RS 2.0 * JDK 1.7.0_45 * Windows 7 * Chrome browser with the Advanced REST Client plug-in I developed some web services using REST that leverages CXF ability to do asynchronous methods, and under the hood, that uses Apache Tomcat. This is working fine overall, the setup and configuration are all good. There is one exception though. This is when I make a request to an async web service that uses a space in the URL, encoded to a %20. The encoding itself works fine, but internally, when Tomcat resumes the Servlet 3 continuation, it passes to some class the previously decoded path and sets it on the request URL. The request is then passed to the CXF layer, that expects a valid URL with no space and tries to instantiate a URL object from it, and fails. Here is the stack trace I got: 05-Jun-2014 12:33:37.426 SEVERE [http-apr-8080-exec-10] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [CXFServlet] in context with path [] threw exception [java.lang.RuntimeException: java.lang.IllegalArgumentException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents] with root cause java.net.URISyntaxException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents at java.net.URI$Parser.fail(URI.java:2829) at java.net.URI$Parser.checkChars(URI.java:3002) at java.net.URI$Parser.parseHierarchical(URI.java:3086) at java.net.URI$Parser.parse(URI.java:3034) at java.net.URI.init(URI.java:595) at java.net.URI.create(URI.java:857) at org.apache.cxf.transport.servlet.BaseUrlHelper.getBaseURL(BaseUrlHelper.java:49) at org.apache.cxf.transport.servlet.ServletController.getBaseURL(ServletController.java:78) at org.apache.cxf.transport.servlet.ServletController.updateDestination(ServletController.java:87) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:200) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:211) at javax.servlet.http.HttpServlet.service(HttpServlet.java:618) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721) at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:639) at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:605) at org.apache.catalina.core.AsyncContextImpl$1.run(AsyncContextImpl.java:208) at org.apache.catalina.core.AsyncContextImpl.doInternalDispatch(AsyncContextImpl.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:78) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:405) at org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1636) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:646) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:277) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2451) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2440) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at
Re: Adding user session id to access log with %S doesn't work?
Hi again, I'm confused. I thought (apparently mistakenly) that there was always a session, but I must be wrong. I just downloaded a fresh instance of 7.0.54 and added the %S to the valve config. However, I don't get any session keys in the log when I click around in the doc. But, as soon as I click on the manager or status links, I get the key. So I guess there's a key available only when code creates a session? And not all the time, even though (I think) there's a session cookie all the time? I'd appreciate any clarification on this. Thanks, Fred On 6/9/2014 4:58 AM, Mark Thomas wrote: On 09/06/2014 01:41, Fred Toth wrote: Hi Dan, Yes, the rest of the log is correct, and yes, I am certain I have an active session (I can see the cookie in my browser). Then something is messed up in your configuration. I've just checked this works and it does. You'll need to provide your full server.xml (comments removed please). Replace and passwords with *** or similar. Marl Thanks, Fred On 6/8/2014 4:30 PM, Daniel Mikusa wrote: On Jun 8, 2014 4:01 PM, Fred Toth ft...@synernet.com wrote: Hi, This feature is in the doc since at least tomcat 5. I'm using tomcat 7.0.47 and I just tried to add the user session id to the access log by adding %S to the pattern attribute. However, it's not working. All I'm getting is - in the log. Have to ask, but are you sure that the request has an active session? Usually when you see - it means the value is absent for that request. Is there some trick to this? I haven't found anything online or in bugzilla. Also posted to stack overflow: Not aware of any tricks. AccessLogValve is pretty straightforward. Is the rest of the log record correct? Dan http://stackoverflow.com/questions/24110188/cant-configure-tomcat-access-log-session-id-with-s Thanks, Fred - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to add jstl.jar to the jasper task
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeff,
On 6/9/14, 1:39 AM, Jeff Cai wrote:
Snip ...
Try setting classPath attribute on jasper element.
http://svn.apache.org/viewvc/tomcat/tc7.0.x/tags/TOMCAT_7_0_54/java/org/apache/jasper/JspC.java?view=markup#l766
Best regards, Konstantin Kolinko
Konstantin, Thanks for your information.
Now I can include the jar file through specifying the CLASSPATH
attribute in the build file. But another new issue comes out:
When building the following code, it reports error.
h3Iterating over a range/h3 c:set var=num value=20 /
c:forEach var=item begin=1 end=${num} ${item} /c:forEach
BUILD FAILED /home/jeffcai/ant_test/build.xml:13:
org.apache.jasper.JasperException: java.lang.NumberFormatException:
For input string: ${num}
This error happens on Tomcat 7.0.54 while not on 8.0.8.
What does your taglib declaration look like?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTleaqAAoJEBzwKT+lPKRYsOIP+gK0+1b4Vx/D21tBRuc39N0A
6oHNL0Bcx/huAeEInyinf6h6GtAbvc62UwZqj5JjRw7XrG7UtnbNfrD/ZoF5kbDD
TBaoqaSZb+8xy8BMsgrKRSK91LTFz5wyVwumMEnRfWBFvmpFlLOenft+SEAsxsvs
wyjGCwygzzI7Yg1JbRhuWimSmWYshK27DSYsvR5foNY55s8fio/jOoBEVBQfFWXB
sua1ET02/4+Qbvnth+u0B3jAJl+zGRa+MsnsQ/LKVwxu2vICpy4jKxKiyHW6Hltz
sQgaVAjShj+57R0l0F81Nq1kTKdzM80ac+YPNWBBry5clwoRW8UbCs4DGWzNPNsx
gP5SelMuFCfPxL7Xi4O1AwdKMZNG2EtTeGqtKj9i72AXhgupTyh1WDcLewUvj9c3
KabLxs0ZqxS4koCTBD77LNPTCEs1V8sW4p420wBrbIXkXu+8xV3+isZb7o07VghT
rlUas+CgtKBCeWMzNi/EcMCKDFBEc1sc+bYVRE5+baLXUKCfaywMpF1ISDGjGWtb
kk3HrQphkyH5E9YOfzYp2GIRXbVdycaZRlm0FgmDvJUPnPKSw4JXvEGFCLA2Jkdy
fHQ8WyNcc1MTpXCh+RgiOwEw1YXFshMPdngEWws9XQHSr31YWhix7rjBXg6gd/fz
gzNqXeOSddXkUp4w69GI
=elu3
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding user session id to access log with %S doesn't work?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Fred, On 6/9/14, 10:59 AM, Fred Toth wrote: I'm confused. I thought (apparently mistakenly) that there was always a session, but I must be wrong. There is not always a session. For container-manager FORM-based authentication, there will always be a session after authentication. (Actually, there will be a session once Tomcat decides it will demand authentication, which is technically before the authentication itself takes place). For BASIC- and DIGEST-based authentication, a session is not necessary at all, though common. Sessions can also exist completely independently of authentication. I just downloaded a fresh instance of 7.0.54 and added the %S to the valve config. However, I don't get any session keys in the log when I click around in the doc. But, as soon as I click on the manager or status links, I get the key. Before authentication, there is no need for a session, so you don't get the session id in the log. Once authenticated, the manager webapp uses a session and therefore you'll get the session id. So I guess there's a key available only when code creates a session? And not all the time, even though (I think) there's a session cookie all the time? There is only a session cookie when there is a session. Cookies are used for other things, too. You said there is a cookie in my browser when you still can't see the session id in your logs. What cookie is it? I'd appreciate any clarification on this. If you are using request.getSession() and its returning non-null, then you should be able to get %S to spit-out the session id. It has worked for me for years. Do you have any strange authentication in place? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTlejNAAoJEBzwKT+lPKRYZCkP/jWSd1EkNvYvzD5YO5SMT7Qa wpYKJThHsifuAmuEejWHo/i4x0zozW4i4J/gpLJ8+Nv9K4wFAN6rMdbelAeYSQY4 RXUv44BZRPU/MLqZmt4SJcc7gw8PKbkklgPd8n6q4QXOKWuPPpnwYk+cvAbfCaqu XZ5Be7Rt/XG08GvN8LCgCyDTqIq/Yp382Y+iZopPKb37U5IvE9uMhgE6hzo48Lg/ ykybJTUoEfMD5cSIqugoRSSZJbHXFiUcKlEVNQCrX4YiSxXCzwt8Q09rq0d013d7 svzRdTEr68LjsnSeKgDuIFdQYNs35PECxvPatwAvDCLn3VLaZrEN8SsV/KTKpNGQ VZGQk7+9TL2QctskgnPhQ8atwzmCThutOusIVnPlUyBKdQx5RmT3yagSle0LL8gM Hj1rymI1aUtX0LfDc+4VrYplCDQl1MjjYREkko58UlATXLSUL973MLrDzyxxcMKz YLbi5l6WC5FcX1T63dsCPNdHReYt1HtN8wv0Gv9C/Hh2fEv1QjbjubHA86VGjBBF tQk1j50G41KzJOQSyY88gRLXgDUJabcfdB/6f/wcYaAU8QI4iOU32O0NqlKehfi3 i2WQypRBtjCft3B41grRwiFG/rINRXHf37B7Zj4kfDOq/NhEjiDrJfUorzklr6v4 wSCXC/w9z9fTs1RHdc/N =dpQS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding user session id to access log with %S doesn't work?
Hi Chris, Thanks very much, this helps. I was also mistaken about the cookie. Sure enough, on further testing, the JSESSIONID cookie appears at the same time the session key shows up in the log, but not before. And no, authentication is not currently in place, but will be soon, which is why I've been going down this trail. Thanks again, Fred On 6/9/2014 1:03 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Fred, On 6/9/14, 10:59 AM, Fred Toth wrote: I'm confused. I thought (apparently mistakenly) that there was always a session, but I must be wrong. There is not always a session. For container-manager FORM-based authentication, there will always be a session after authentication. (Actually, there will be a session once Tomcat decides it will demand authentication, which is technically before the authentication itself takes place). For BASIC- and DIGEST-based authentication, a session is not necessary at all, though common. Sessions can also exist completely independently of authentication. I just downloaded a fresh instance of 7.0.54 and added the %S to the valve config. However, I don't get any session keys in the log when I click around in the doc. But, as soon as I click on the manager or status links, I get the key. Before authentication, there is no need for a session, so you don't get the session id in the log. Once authenticated, the manager webapp uses a session and therefore you'll get the session id. So I guess there's a key available only when code creates a session? And not all the time, even though (I think) there's a session cookie all the time? There is only a session cookie when there is a session. Cookies are used for other things, too. You said there is a cookie in my browser when you still can't see the session id in your logs. What cookie is it? I'd appreciate any clarification on this. If you are using request.getSession() and its returning non-null, then you should be able to get %S to spit-out the session id. It has worked for me for years. Do you have any strange authentication in place? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTlejNAAoJEBzwKT+lPKRYZCkP/jWSd1EkNvYvzD5YO5SMT7Qa wpYKJThHsifuAmuEejWHo/i4x0zozW4i4J/gpLJ8+Nv9K4wFAN6rMdbelAeYSQY4 RXUv44BZRPU/MLqZmt4SJcc7gw8PKbkklgPd8n6q4QXOKWuPPpnwYk+cvAbfCaqu XZ5Be7Rt/XG08GvN8LCgCyDTqIq/Yp382Y+iZopPKb37U5IvE9uMhgE6hzo48Lg/ ykybJTUoEfMD5cSIqugoRSSZJbHXFiUcKlEVNQCrX4YiSxXCzwt8Q09rq0d013d7 svzRdTEr68LjsnSeKgDuIFdQYNs35PECxvPatwAvDCLn3VLaZrEN8SsV/KTKpNGQ VZGQk7+9TL2QctskgnPhQ8atwzmCThutOusIVnPlUyBKdQx5RmT3yagSle0LL8gM Hj1rymI1aUtX0LfDc+4VrYplCDQl1MjjYREkko58UlATXLSUL973MLrDzyxxcMKz YLbi5l6WC5FcX1T63dsCPNdHReYt1HtN8wv0Gv9C/Hh2fEv1QjbjubHA86VGjBBF tQk1j50G41KzJOQSyY88gRLXgDUJabcfdB/6f/wcYaAU8QI4iOU32O0NqlKehfi3 i2WQypRBtjCft3B41grRwiFG/rINRXHf37B7Zj4kfDOq/NhEjiDrJfUorzklr6v4 wSCXC/w9z9fTs1RHdc/N =dpQS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Decoded URL set on asynchronous request
On Mon, Jun 9, 2014 at 9:00 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On Mon, Jun 9, 2014 at 8:46 AM, Jimmy Royer jimlero...@gmail.com wrote: Is there any information that I should add to this to get some help? Any chance you could put together a sample app or unit test to replicate the problem? Ideally without third party components like CXF. It would make it easier someone on the list to recreate the problem and thus easier for someone to help. I've setup a project and I can reproduce something where we see that the URL is non-encoded when I make use of the AsyncContext#dispatch method, but the overall workflow of my sample does not make sense because I don't know when this method should used or why. Or should I just go straight and create a bug report for this (as this might not be a message targeting the users mailing list but Tomcat's developers)? The users list is always a good first place to start. As an FYI, don't top post. Reply inline like this, or just at the bottom. It's the convention followed on the list. Okay got it, I'll follow the standard, thanks for the reply! Dan On Thu, Jun 5, 2014 at 2:04 PM, Jimmy Royer jimlero...@gmail.com wrote: Hello, I am using this combo of components: * Apache Tomcat 8.0.8 * Apache CXF 2.7.11 * Servlet 3.0 * JAX-RS 2.0 * JDK 1.7.0_45 * Windows 7 * Chrome browser with the Advanced REST Client plug-in I developed some web services using REST that leverages CXF ability to do asynchronous methods, and under the hood, that uses Apache Tomcat. This is working fine overall, the setup and configuration are all good. There is one exception though. This is when I make a request to an async web service that uses a space in the URL, encoded to a %20. The encoding itself works fine, but internally, when Tomcat resumes the Servlet 3 continuation, it passes to some class the previously decoded path and sets it on the request URL. The request is then passed to the CXF layer, that expects a valid URL with no space and tries to instantiate a URL object from it, and fails. Here is the stack trace I got: 05-Jun-2014 12:33:37.426 SEVERE [http-apr-8080-exec-10] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [CXFServlet] in context with path [] threw exception [java.lang.RuntimeException: java.lang.IllegalArgumentException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents] with root cause java.net.URISyntaxException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents at java.net.URI$Parser.fail(URI.java:2829) at java.net.URI$Parser.checkChars(URI.java:3002) at java.net.URI$Parser.parseHierarchical(URI.java:3086) at java.net.URI$Parser.parse(URI.java:3034) at java.net.URI.init(URI.java:595) at java.net.URI.create(URI.java:857) at org.apache.cxf.transport.servlet.BaseUrlHelper.getBaseURL(BaseUrlHelper.java:49) at org.apache.cxf.transport.servlet.ServletController.getBaseURL(ServletController.java:78) at org.apache.cxf.transport.servlet.ServletController.updateDestination(ServletController.java:87) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:200) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:211) at javax.servlet.http.HttpServlet.service(HttpServlet.java:618) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721) at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:639) at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:605) at org.apache.catalina.core.AsyncContextImpl$1.run(AsyncContextImpl.java:208) at org.apache.catalina.core.AsyncContextImpl.doInternalDispatch(AsyncContextImpl.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at
Re: Decoded URL set on asynchronous request
On Mon, Jun 9, 2014 at 9:07 AM, Mark Thomas ma...@apache.org wrote: On 09/06/2014 13:46, Jimmy Royer wrote: Is there any information that I should add to this to get some help? Right now, no. There may be further questions as folks dig into this. Or should I just go straight and create a bug report for this (as this might not be a message targeting the users mailing list but Tomcat's developers)? No. That is likely to get closed as INVALID since - at the moment - there is not a clearly identified bug in Tomcat. There are lots of moving parts here and while there is obviously a bug somewhere, it isn't yet clear where that bug is. I suspect that most folks took a look at this and decided it was just too big / complicated to get into. Given the complexity of the situation, the effort you have taken to make the issue as clear as it is, is very much appreciated. To be honest, I doubt anyone could have written a better question given the problem. Give me a little time to dig into it and I'll get back to you with either an answer or - more likely - some specific questions or things to test. Mark I understand. I can submit what I started as a sample project to target this bug which includes a minimum of dependencies along with a Maven configuration. I can push it to github and that would be very easy for you to get it. What do you prefer? My sample project does not exactly shows the problem, as a call to AsyncContext#dispatch is necessary and I'm not sure how and why it's used. But that could save you the project setup time at least. Jimmy Thanks, Jimmy On Thu, Jun 5, 2014 at 2:04 PM, Jimmy Royer jimlero...@gmail.com wrote: Hello, I am using this combo of components: * Apache Tomcat 8.0.8 * Apache CXF 2.7.11 * Servlet 3.0 * JAX-RS 2.0 * JDK 1.7.0_45 * Windows 7 * Chrome browser with the Advanced REST Client plug-in I developed some web services using REST that leverages CXF ability to do asynchronous methods, and under the hood, that uses Apache Tomcat. This is working fine overall, the setup and configuration are all good. There is one exception though. This is when I make a request to an async web service that uses a space in the URL, encoded to a %20. The encoding itself works fine, but internally, when Tomcat resumes the Servlet 3 continuation, it passes to some class the previously decoded path and sets it on the request URL. The request is then passed to the CXF layer, that expects a valid URL with no space and tries to instantiate a URL object from it, and fails. Here is the stack trace I got: 05-Jun-2014 12:33:37.426 SEVERE [http-apr-8080-exec-10] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [CXFServlet] in context with path [] threw exception [java.lang.RuntimeException: java.lang.IllegalArgumentException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents] with root cause java.net.URISyntaxException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents at java.net.URI$Parser.fail(URI.java:2829) at java.net.URI$Parser.checkChars(URI.java:3002) at java.net.URI$Parser.parseHierarchical(URI.java:3086) at java.net.URI$Parser.parse(URI.java:3034) at java.net.URI.init(URI.java:595) at java.net.URI.create(URI.java:857) at org.apache.cxf.transport.servlet.BaseUrlHelper.getBaseURL(BaseUrlHelper.java:49) at org.apache.cxf.transport.servlet.ServletController.getBaseURL(ServletController.java:78) at org.apache.cxf.transport.servlet.ServletController.updateDestination(ServletController.java:87) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:200) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:211) at javax.servlet.http.HttpServlet.service(HttpServlet.java:618) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721) at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:639) at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:605) at
Re: Decoded URL set on asynchronous request
On Mon, Jun 9, 2014 at 9:38 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-06-05 22:04 GMT+04:00 Jimmy Royer jimlero...@gmail.com: Hello, I am using this combo of components: * Apache Tomcat 8.0.8 * Apache CXF 2.7.11 * Servlet 3.0 * JAX-RS 2.0 * JDK 1.7.0_45 * Windows 7 * Chrome browser with the Advanced REST Client plug-in I developed some web services using REST that leverages CXF ability to do asynchronous methods, and under the hood, that uses Apache Tomcat. This is working fine overall, the setup and configuration are all good. There is one exception though. This is when I make a request to an async web service that uses a space in the URL, encoded to a %20. The encoding itself works fine, but internally, when Tomcat resumes the Servlet 3 continuation, it passes to some class the previously decoded path and sets it on the request URL. The request is then passed to the CXF layer, that expects a valid URL with no space and tries to instantiate a URL object from it, and fails. Here is the stack trace I got: 05-Jun-2014 12:33:37.426 SEVERE [http-apr-8080-exec-10] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [CXFServlet] in context with path [] threw exception [java.lang.RuntimeException: java.lang.IllegalArgumentException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents] with root cause java.net.URISyntaxException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents at java.net.URI$Parser.fail(URI.java:2829) at java.net.URI$Parser.checkChars(URI.java:3002) at java.net.URI$Parser.parseHierarchical(URI.java:3086) at java.net.URI$Parser.parse(URI.java:3034) at java.net.URI.init(URI.java:595) at java.net.URI.create(URI.java:857) at org.apache.cxf.transport.servlet.BaseUrlHelper.getBaseURL(BaseUrlHelper.java:49) at org.apache.cxf.transport.servlet.ServletController.getBaseURL(ServletController.java:78) at org.apache.cxf.transport.servlet.ServletController.updateDestination(ServletController.java:87) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:200) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:211) at javax.servlet.http.HttpServlet.service(HttpServlet.java:618) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721) at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:639) at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:605) at org.apache.catalina.core.AsyncContextImpl$1.run(AsyncContextImpl.java:208) at org.apache.catalina.core.AsyncContextImpl.doInternalDispatch(AsyncContextImpl.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:78) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:405) at org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1636) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:646) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:277) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2451) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2440) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at
