Ahh ...
looking at the bash scripts it's: catalina.sh debug any tips or suggestions?
Using JDB on tomcat
WHat is the best way to do this? 1) substitute jdb for java in the command shell 2) try to attach to a running instance any pointers to experience in the email archive would be useful. I'm looking at http://mail-archives.apache.org/mod_mbox/tomcat-users/ but I don't see a way to search them -- just browse them. Thanks, Roger
RE: UTF-8 encoding problems
OK, after some flailing around, I installed a fresh version of tomcat 5.5.26 and added the test page from the FAQ. I'm testing two ways One using the submit button to test the POST, and testing response to GET by encoding the "query" Romans à clef as: http://resdev1.dev.oclc.org:2/textEncoding.jsp?mydata=%20Romans%20a%CC%80%20clef. I made sure to add the URIEncoding = "UTF-8" a/v pair to the connector declaration/definition. >From this base, I began to add in various libraries to >webapps/ROOT/WEB-INF/lib. The first two showed some aberrant behavior. I >added commons-logging.jar and log4j-1.2.15.jar. When log4j is set to an INFO >level of output both POST and GET work as advertised. When it is set to >DEBUG, the POST test fails and the GET works. So there is something in log4j >that munges the parameter sstring. This may not be my particular problem. I post it to the list as informations that some library outside of tomcat can munge UTF-8 encoding. -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 4:10 PM To: Tomcat Users List Subject: Re: UTF-8 encoding problems Thompson,Roger wrote: > I saw that--All it really says is to set URIEncoding="UTF-8" the tips > say to use POST-- cannot do in a RESTful service. Have you actually tried the test? Did it work? If you read the sample code it also points to a number of other things the service needs to do in terms of setting encoding etc. If the test works and your service doesn't then either you haven't configured the service properly, there is a bug in the framework or the filters are causing problems. I fixed a whole bunch of encoding issues a while back and there haven't been any bugs since. That isn't to say there aren't any - just that the odds of this being a Tomcat problem are pretty slim. You might want to take a look at TcpMon from the Apache Axis project. I have found it very useful when debugging similar issues. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: UTF-8 encoding problems
thanks, will try the TcpMon -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 4:10 PM To: Tomcat Users List Subject: Re: UTF-8 encoding problems Thompson,Roger wrote: > I saw that--All it really says is to set URIEncoding="UTF-8" the tips > say to use POST-- cannot do in a RESTful service. Have you actually tried the test? Did it work? If you read the sample code it also points to a number of other things the service needs to do in terms of setting encoding etc. If the test works and your service doesn't then either you haven't configured the service properly, there is a bug in the framework or the filters are causing problems. I fixed a whole bunch of encoding issues a while back and there haven't been any bugs since. That isn't to say there aren't any - just that the odds of this being a Tomcat problem are pretty slim. You might want to take a look at TcpMon from the Apache Axis project. I have found it very useful when debugging similar issues. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: UTF-8 encoding problems
I saw that--All it really says is to set URIEncoding="UTF-8" the tips say to use POST-- cannot do in a RESTful service. -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 2:58 PM To: Tomcat Users List Subject: Re: UTF-8 encoding problems Thompson,Roger wrote: > WHere else besides the connector definition in the server.xml, should I look to find this. The implementor of the SRW/U code is convinced that the problem is in tomcat some where as he does not get this same error. http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q4 Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
UTF-8 encoding problems
Environment: Tomcat 5.5.20, no apache frontend. Running XSLTFIlter and urlrewrite in front of the tomcat. WE are implementing a RESTful webservice (tspilot) on top of a SRU service on the connector going into tomcat I have: Problem: Somewhere in tomcat the UTF-8 encoded chatacters are getting munged. For example, one query has a accented a as in: Romans à clef. this goes through XSLTFilter and Urlrewrite and comes out (partially) /gsafd/?query=oclcts.terms+%3D+%22Romans+a%CC%80+clef%22&version=1.1&operation ... somewhere in tomcat the cc 80 get munged into c3 8c c2 80. WHere else besides the connector definition in the server.xml, should I look to find this. The implementor of the SRW/U code is convinced that the problem is in tomcat some where as he does not get this same error.
Trailing slash problem
I know this has been discussed, but I seem unable to find much about it other than a comment by Yoav Shapira. Environment: Tomcat 5.5.20 with no apache front end. The http connector adds a trailing slash to the top level rerquest to a web app like as follows: http://tspilot.oclc.org/gsafd ==> http://tspilot.oclc.org/gsafd/ the connector issues the redirection code (320?). Is there a way to tell the connector to not do this? If not, what is a method that I can use to achieve this effect (i.e. some use of an apache front end and filtering components). I have UrlRewriteFilter installed at the applet level. Is there a discussion regarding why this behavior was implemented
Trying to respond to s symbol both as a context (webapp) and as a request
Background: Tomcat 5.5.20 I am devolping a web service to provide vocabulary in a library setting. The service will be located at: http://tspilot.oclc.org/ One of the vocabularies is named "gsafd" I need to respond differently to: http://tspilot.oclc.org/gsafd vs http://tspilot.oclc.org/gsafd/ In the first case, I need to provide an XML document that gives a description of the vocabulary. I'm trying to do this from the ROOT webapp. In the second case, I am providing an SRU explain response. I have managed to accomplish the second case via URL rewrite rules in the gsafd webapp's web.xml. It appears that TOMCAT adds the trailing slash to the URL if it is not present and so route the request through the gsafd context. How do I set up TOMCAT not to do this so the first form is processed through the ROOT webapp. There will be other vocabularies: lcsh, lcshac, mesh, and fast as well as other that have to respond the same way. Ciao, Roger Thompson
