Re: Send Request from One Server to Another Server
make sure you are handing the session id at the very beginning the session id is sent back in a cookie , you need to either send it back at any request (as cookie) or use URL rewriting to embed it in the request URL. On Fri, Sep 12, 2008 at 7:48 AM, ANITA.2310 [EMAIL PROTECTED] wrote: I have 2 Servers,one is Tomcat and another is Sun Application Server. I want to send request from Sun Application Server to Tomcat and again come back to Sun Application server. For Eg. I started from page http://anitad:1780/login/login.jsp, After login, i got another page, from here i m calling http://anitad:8080/login/process.jsp, and in OnLoad of this page i called http://anitad:1780/login/Success.jsp. But,when i m calling http://anitad:1780/login/Success.jsp,it is giving Session Expired. Please reply ASAP. Thanx in advance. -- View this message in context: http://www.nabble.com/Send-Request-from-One-Server-to-Another-Server-tp19449857p19449857.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Youssef
about Connector's attribute redirectPort
at tomcat official site, http://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html redirectPort is described as below If this Connector is supporting non-SSL requests, and a request is received for which a matching security-constraint requires SSL transport, Catalina will automatically redirect the request to the port number specified here. The default value is 443. but i still don't understand what redirectPort is used for. and actually, tomcat doesn't listen on the port specified by redirectPort, so how does the redirect work? ___ 雅虎邮箱，您的终生邮箱！ http://cn.mail.yahoo.com/
Re: Send Request from One Server to Another Server
How can i achieve this? Youssef Mohammed wrote: make sure you are handing the session id at the very beginning the session id is sent back in a cookie , you need to either send it back at any request (as cookie) or use URL rewriting to embed it in the request URL. On Fri, Sep 12, 2008 at 7:48 AM, ANITA.2310 [EMAIL PROTECTED] wrote: I have 2 Servers,one is Tomcat and another is Sun Application Server. I want to send request from Sun Application Server to Tomcat and again come back to Sun Application server. For Eg. I started from page http://anitad:1780/login/login.jsp, After login, i got another page, from here i m calling http://anitad:8080/login/process.jsp, and in OnLoad of this page i called http://anitad:1780/login/Success.jsp. But,when i m calling http://anitad:1780/login/Success.jsp,it is giving Session Expired. Please reply ASAP. Thanx in advance. -- View this message in context: http://www.nabble.com/Send-Request-from-One-Server-to-Another-Server-tp19449857p19449857.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Youssef -- View this message in context: http://www.nabble.com/Send-Request-from-One-Server-to-Another-Server-tp19449857p19450328.html Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: Send Request from One Server to Another Server
basically you'd better use a Http client library (like HttpClient ) that will make it easier. check this as starting point ... http://www.mail-archive.com/[EMAIL PROTECTED]/msg06270.html note that here they have the jsessionid known .. but in your case you will need to know that. I think the library is providing an easy way to do that (that's to read the cookies that is sent at the very beginning request) On Fri, Sep 12, 2008 at 8:36 AM, ANITA.2310 [EMAIL PROTECTED] wrote: How can i achieve this? Youssef Mohammed wrote: make sure you are handing the session id at the very beginning the session id is sent back in a cookie , you need to either send it back at any request (as cookie) or use URL rewriting to embed it in the request URL. On Fri, Sep 12, 2008 at 7:48 AM, ANITA.2310 [EMAIL PROTECTED] wrote: I have 2 Servers,one is Tomcat and another is Sun Application Server. I want to send request from Sun Application Server to Tomcat and again come back to Sun Application server. For Eg. I started from page http://anitad:1780/login/login.jsp, After login, i got another page, from here i m calling http://anitad:8080/login/process.jsp, and in OnLoad of this page i called http://anitad:1780/login/Success.jsp. But,when i m calling http://anitad:1780/login/Success.jsp,it is giving Session Expired. Please reply ASAP. Thanx in advance. -- View this message in context: http://www.nabble.com/Send-Request-from-One-Server-to-Another-Server-tp19449857p19449857.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Youssef -- View this message in context: http://www.nabble.com/Send-Request-from-One-Server-to-Another-Server-tp19449857p19450328.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Youssef
Re: about Connector's attribute redirectPort
李征 wrote: at tomcat official site, http://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html redirectPort is described as below If this Connector is supporting non-SSL requests, and a request is received for which a matching security-constraint requires SSL transport, Catalina will automatically redirect the request to the port number specified here. The default value is 443. but i still don't understand what redirectPort is used for. Which part of the description don't you understand? and actually, tomcat doesn't listen on the port specified by redirectPort, so how does the redirect work? If Tomcat isn't listening on that port with a secure connector it won't work. 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]
Beginner
Hi Everyone, I have joined the tomcat project. Could you point to me to some study material where I can understand the architecture of tomcat and how things work? I have some knowledge on Java, JSP and Servlets. P.S: As this is the first time I am posting, please correct me If I have posted something wrong Thanks and Regards, Sathish Kumar
Re: Beginner
sathish kumar wrote: Hi Everyone, I have joined the tomcat project. Could you point to me to some study material where I can understand the architecture of tomcat and how things work? http://tomcat.apache.org/tomcat-6.0-doc/architecture/index.html then look at the code http://svn.apache.org/repos/asf/tomcat/tc6.0.x/ 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]
Re: Regarding Error 404-please help!
It is really hard to pinpoint your problem whit such a huge web.xml. But, let's try. First, for servlet HelloWorld you stated the class name /servlet/HelloWorld. That is wrong. Class name should be fully qualified Java class name like: com.something.servlet.HelloWorld. Second, in your servlet mapping, your url pattern for servlet mapping is HelloWorld. First mistake is the leading space, remove it. Second, in your first message, I see that you try to invoke your servlet at url /servlet/HelloWorld. If you want do invoke your servlet on that URL, you must put in url-mapping something like /servlet/HelloWorld. HTH, Ognjen laura fu wrote: Hi Ognjen, Thanks for your reply! Here is my web.xml from jjolt application: ?xml version=1.0 encoding=ISO-8859-1?!DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd;web-appdisplay-nameJJOLT servlets/display-name description JJOLT servlets Examples. /descriptionservlet servlet-nameHelloWorld/servlet-name servlet-class/servlet/HelloWorld/servlet-class /servlet servlet servlet-nameHello/servlet-name servlet-class/servlet/Hello/servlet-class /servlet servlet servlet-nameAttributes/servlet-name servlet-classAttributes/servlet-class /servlet servlet servlet-namePostAttributes/servlet-name servlet-classPostAttributes/servlet-class /servlet servlet servlet-nameAddToShoppingCart/servlet-name servlet-classAddToShoppingCart/servlet-class /servlet servlet servlet-nameShoppingCartURLRewrite/servlet-name servlet-classShoppingCartURLRewrite/servlet-class /servlet servlet servlet-nameReviewShoppingCart/servlet-name servlet-classReviewShoppingCart/servlet-class /servlet servlet servlet-nameShoppingCartCookies/servlet-name servlet-classShoppingCartCookies/servlet-class /servlet servlet servlet-namePageCountUsingSessionAPI/servlet-name servlet-classPageCountUsingSessionAPI/servlet-class /servlet servlet servlet-nameSaveSessionData/servlet-name servlet-classSaveSessionData/servlet-class /servlet servlet servlet-nameShoppingCartSessionTracking/servlet-name servlet-classShoppingCartSessionTracking/servlet-class /servlet servlet servlet-namegetExample/servlet-name servlet-classAttributes/servlet-class /servlet servlet servlet-namegetInitializationParameters/servlet-name servlet-classInit_param/servlet-class init-param param-nameversion /param-name param-valuebest/param-value /init-param /servletservlet-mapping servlet-nameHelloWorld/servlet-name url-pattern HelloWorld/url-pattern /servlet-mapping servlet-mapping servlet-nameHello/servlet-name url-pattern/servlet/Hello/url-pattern /servlet-mapping servlet-mapping servlet-nameAttributes/servlet-name url-pattern/servlet/Attributes/url-pattern /servlet-mapping servlet-mapping servlet-namePostAttributes/servlet-name url-pattern/servlet/PostAttributes/url-pattern /servlet-mapping servlet-mapping servlet-nameAddToShoppingCart/servlet-name url-pattern/servlet/AddToShoppingCart/url-pattern /servlet-mapping servlet-mapping servlet-nameReviewShoppingCart/servlet-name url-pattern/servlet/ReviewShoppingCart/url-pattern /servlet-mapping servlet-mapping servlet-nameShoppingCartURLRewrite/servlet-name url-pattern/servlet/ShoppingCartURLRewrite/*/url-pattern /servlet-mapping servlet-mapping servlet-nameShoppingCartCookies/servlet-name url-pattern/servlet/ShoppingCartCookies/url-pattern /servlet-mapping servlet-mapping servlet-namePageCountUsingSessionAPI/servlet-name url-pattern/servlet/PageCountUsingSessionAPI/url-pattern /servlet-mapping servlet-mapping servlet-nameSaveSessionData/servlet-name url-pattern/servlet/SaveSessionData/url-pattern /servlet-mapping servlet-mapping servlet-nameShoppingCartSessionTracking/servlet-name url-pattern/servlet/ShoppingCartSessionTracking/url-pattern /servlet-mapping servlet-mapping servlet-namegetExample/servlet-name url-pattern/send/url-pattern /servlet-mapping servlet-mapping servlet-namegetInitializationParameters/servlet-name url-pattern/init/url-pattern /servlet-mapping/web-app Let me know if the email screwed up the formatting, then i will send in another format. I have also uncommented the invoker servlet in the main web.xml file. Thanks so much! Regards, Laura Date: Wed, 10 Sep 2008 09:51:13 +0200 From: [EMAIL PROTECTED] To:
Re: Migrating to tomcat 6 gives formatted currency amounts problem
Caldarale, Charles R wrote: I'm not sure these days what the normal web character set really is. If you're referring to ASCII (aka Basic Latin), then no, the Pound Sterling symbol is not present. However, for any of the ISO-8859-x variants, it is present, using the 163 (0xA3) value you noted (same as the Unicode code point). It's also in UTF-8 of course, but requires two bytes (0xC2 0xA3) to represent the code point. I love these discussions about character sets. They seem to confuse so many people; even I, who have been involved in them for 30 years... Anyway, I have a related question, which I don't think constitutes a hijack of this thread, because the underlying cause is probably similar. Here it goes : Tomcat (v 4.1, v 5.0, v5.5, have not tried yet in 6.x) The above Tomcat's running under the same Linux or Solaris, essentially set up the same way. The JVM may vary, but I don't think that is the problem, because of the consistency of the problem as explained below. I am running a webapp from an external supplier, always the same binary version. I don't have the code, can't see what's in it. The pages served by that webapp are the same html pages, all of them having a declaration meta http-equiv=Content-Type content=text/html; charset=iso-8859-1. The pages also *are* properly encoded as iso-8859-1 (100% positive, I know the difference). The browser receiving the pages is always the same one, same settings. Now, case a) in the Tomcat startup files, I do nothing, meaning I just take Tomcat out-of-the-box and run the webapp. Result : in any such html page that contains characters with an ISO-8859 codepoint above \xA0 (meaning the displayable characters of the high part of the table, where one finds things like uppercase A with umlaut), these characters - appear in the browser display as ? (minus the quotes) - also if I save the page from the browser to disk, and look at them with an iso-8859-1 capable editor, they are effectively ?. (So it's not the browser misunderstanding them, it is Tomcat sending them that way). case b) In one of the Tomcat startup files (e.g. tomcat_dir/bin/startup.sh or even in /etc/init.d/tomcat5.5), I add the following line LC_CTYPE=en_us.iso88591 (or whatever is valid on that host to specify an iso-8859-1 LC_CTYPE) (before the actual start of Tomcat) and restart Tomcat then the same page displays properly in the browser, and also is correct iso-8859-1 when saved to disk and examined with the editor. (In other words, what previously were ? characters, are now the correct iso-8859-1 character bytes). Now my question is : How can it matter which LC_CTYPE Tomcat is started under, that would have the result above ? The behaviour above is consistent across different hosts, across the same or different Tomcat versions, it is always the same webapp, always the same html pages, always the same browser, etc. Only that LC_CTYPE line changes the behaviour. On the face of it, the only thing I can think of that would explain this, is that the webapp in question does something wrong, but what exactly could it be doing ? Any ideas ? Thanks in advance, André - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Isn't there a PDF style document for v6？
Hi all! Can i download a PDF style document from somewhere, or other style? Please show me the url. Thanks! -- Sorry for my english!! 明 Please help me to correct my english expression and error in syntax
Re: Migrating to tomcat 6 gives formatted currency amounts problem
- Original Message - From: Caldarale, Charles R [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, September 12, 2008 6:01 AM Subject: RE: Migrating to tomcat 6 gives formatted currency amounts problem From: Johnny Kewl [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem http://www.kewlstuff.co.za/test/test.htm What do you see in this test page? Depends on which character encoding I choose to view the page in. For the declared UTF-8, FF3 shows the invalid hex value at that spot in your page. If I override that with say ISO-8859-15, the R in a circle appears. Note that no font is involved here, just the encoding declaration. You need to get over this fixation with fonts - they have absolutely nothing to do with this issue. A font is just a graphical description of how to draw one or more code points on an output device, based on the font designer's take on what each code point should look like. It's the character encoding that tells the message recipient what code point to generate for a given bit pattern; only after the code point is determined does any font get involved to create the visible symbol. This is a great site to get lost in for a few days: http://www.unicode.org/ - Chuck Yes, I do that, mix terminology But can I just get your opinion on this... If this locale stuff is in fact defaulting to an ISO char set that can do these symbols... and say you where making a non english page, say Japanese... do you think that its possible to use it? I've actually now seen examples on the web that are doing it Wil's way, they using the getCurrencyInstance to make the currency symbols. And it is the most natural thing in the world for a coder to want to do... the functions are synonymous with internationalization. Its probably in the Java manaul... But I'm thinking its a US/Eng only methodology... when applied to a web page. Do you think using getCurrencyInstance is generalizable in other languages? When you say If I override that with say ISO-8859-15, is that the whole page you talking about, or it possible to have different character encoding sections in a web page thats another area thats confusing me now, because if I do look at that test page in a MS tool... it displays correctly with mixed encodings? You see... people are saying in a well designed web page... its a suggestion, I get that. But when you choose a font in a text editor like Swing or Word, you are also picking some character set... and thats whats been injected into the page as its been formed... Or in a MS localization panel, if you choose you want Verdana as a default font... these systems dont throw character sets at users, it just picks one in the background... thus my analogy... and its the cross over between these systems thats got me confused ;) I screw up terminology... ok we all know that but Does Wil need to worry about the way he is doing it?... thats all I'm asking... I think so... Thanks... --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - 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: Migrating to tomcat 6 gives formatted currency amounts problem
2008/9/12 André Warnier [EMAIL PROTECTED]: Caldarale, Charles R wrote: I'm not sure these days what the normal web character set really is. If you're referring to ASCII (aka Basic Latin), then no, the Pound Sterling symbol is not present. However, for any of the ISO-8859-x variants, it is present, using the 163 (0xA3) value you noted (same as the Unicode code point). It's also in UTF-8 of course, but requires two bytes (0xC2 0xA3) to represent the code point. I love these discussions about character sets. They seem to confuse so many people; even I, who have been involved in them for 30 years... Anyway, I have a related question, which I don't think constitutes a hijack of this thread, because the underlying cause is probably similar. Here it goes : Tomcat (v 4.1, v 5.0, v5.5, have not tried yet in 6.x) The above Tomcat's running under the same Linux or Solaris, essentially set up the same way. The JVM may vary, but I don't think that is the problem, because of the consistency of the problem as explained below. I am running a webapp from an external supplier, always the same binary version. I don't have the code, can't see what's in it. The pages served by that webapp are the same html pages, all of them having a declaration meta http-equiv=Content-Type content=text/html; charset=iso-8859-1. The pages also *are* properly encoded as iso-8859-1 (100% positive, I know the difference). The browser receiving the pages is always the same one, same settings. Now, case a) in the Tomcat startup files, I do nothing, meaning I just take Tomcat out-of-the-box and run the webapp. Result : in any such html page that contains characters with an ISO-8859 codepoint above \xA0 (meaning the displayable characters of the high part of the table, where one finds things like uppercase A with umlaut), these characters - appear in the browser display as ? (minus the quotes) - also if I save the page from the browser to disk, and look at them with an iso-8859-1 capable editor, they are effectively ?. (So it's not the browser misunderstanding them, it is Tomcat sending them that way). case b) In one of the Tomcat startup files (e.g. tomcat_dir/bin/startup.sh or even in /etc/init.d/tomcat5.5), I add the following line LC_CTYPE=en_us.iso88591 (or whatever is valid on that host to specify an iso-8859-1 LC_CTYPE) (before the actual start of Tomcat) and restart Tomcat then the same page displays properly in the browser, and also is correct iso-8859-1 when saved to disk and examined with the editor. (In other words, what previously were ? characters, are now the correct iso-8859-1 character bytes). Now my question is : How can it matter which LC_CTYPE Tomcat is started under, that would have the result above ? The behaviour above is consistent across different hosts, across the same or different Tomcat versions, it is always the same webapp, always the same html pages, always the same browser, etc. Only that LC_CTYPE line changes the behaviour. On the face of it, the only thing I can think of that would explain this, is that the webapp in question does something wrong, but what exactly could it be doing ? Any ideas ? It is [EMAIL PROTECTED] pageEncoding=... % that is missing from those pages. Thus JSP compiler does not know what encoding they are using for their source and messes them at compilation time. AFAIK (but never tried) it can be configured without modifying the sources using the jsp-config element in web.xml. It can be done in the default one in conf/web.xml. The configuration element is described in JSP.3.3.4 of JSP2.0 spec. By the way: in my pages I usually declare [EMAIL PROTECTED] contentType=text/html; charset=... pageEncoding=... % and add META http-equiv=Content-type content=%=response.getContentType() % Thus both HTTP Content-Type: header and the META tag are present in my response and are always in sync. Best regards, Konstantin Kolinko - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
回复： about Connector's attribute redirectPo rt
Mark thanks a lot for ur reply, this is my setting for connector Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=150 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ and i can't get anything from netstat -apn | grep 8443 - 原始邮件 发件人： Mark Thomas [EMAIL PROTECTED] 收件人： Tomcat Users List users@tomcat.apache.org 已发送： 2008/9/12(周五), 下午4:21:38 主题： Re: about Connector's attribute redirectPort 李征 wrote: at tomcat official site, http://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html redirectPort is described as below If this Connector is supporting non-SSL requests, and a request is received for which a matching security-constraint requires SSL transport, Catalina will automatically redirect the request to the port number specified here. The default value is 443. but i still don't understand what redirectPort is used for. Which part of the description don't you understand? and actually, tomcat doesn't listen on the port specified by redirectPort, so how does the redirect work? If Tomcat isn't listening on that port with a secure connector it won't work. 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] ___ 雅虎邮箱，您的终生邮箱！ http://cn.mail.yahoo.com/
Re: Migrating to tomcat 6 gives formatted currency amounts problem
OK, Wil you made me do some homework... got it sorted for you You must not guess the Charset... as we been doing. Use this function System.out.print(CharSet : + Charset.defaultCharset().toString()); and thats what you HAVE TO set your page at On my system it tells me its. windows-1252 On Solaris if you running in a C Locale... it will be US-ASCII If you running in a US locale it will be ISO-8859-1 Now you doing Ajax, so I imagine you may want to inject this stuff in DIV statements... I'll let someone else try answer that... mission impossible... I think. So... you have to convert character sets from what the locale is using... from the looks of things different on every single machine and OS... to what you using in the web page proper... probably UTF8 if you are internationalizing ... it a headache... rather refactor your code so the pages are all the same charset of your choosing and work with pound, yen dollar anyway use that function to get the decoding that is actually been used... they all changed from outside Java... in linux itself by the user... so you cannot guess... and then how you going to try get that Ajax into DIV's and tables using Javascript and DHtml or whatever only you know ;) . Dont do it.. --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - 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: Tomcat 6 + Native Library + HTTPS
StrongSteve wrote: Can anyone tell me - or give me a resource - on how to configure SSL in Tomcat 6 with an installed Native Library? I did it as usual in the following way: Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=true sslProtocol=TLS keystoreFile=.keystore keyAlias=tomcat keystorePass=changeit truststoreFile=.truststore truststorePass=changeit/ But Tomcat refuses to start up. As soon as I remove the Native Library, these settings work perfect. The configuration for SSL enabled Connectors is different when using APR: http://tomcat.apache.org/tomcat-6.0-doc/apr.html#HTTPS Regards mks - 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: Migrating to tomcat 6 gives formatted currency amounts problem
Then one last thing before I put this in my little black book of things I'm never going to do... and forget about it forever ;) This is what windows does If the machine is on US English... Regardless of the local I set... German, English, Japanese I set in Java the charset is always windows-1252... which is basically ISO with differences... But if I switch the machine back to Japanese... then its windows-32j So thats what you injecting into your web pages... when using Java locale functions... in a web page... Maybe thats what a person wants and in a company, using these local functions and every user is on Windows... it may just work ... thats actually scary... Nice question --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 6 + Native Library + HTTPS
Hi Everybody! Can anyone tell me - or give me a resource - on how to configure SSL in Tomcat 6 with an installed Native Library? I did it as usual in the following way: Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=true sslProtocol=TLS keystoreFile=.keystore keyAlias=tomcat keystorePass=changeit truststoreFile=.truststore truststorePass=changeit/ But Tomcat refuses to start up. As soon as I remove the Native Library, these settings work perfect. Where and How am I getting wrong? Thanks in Advance for both your time and your knowledge! Greetings Stefan -- View this message in context: http://www.nabble.com/Tomcat-6-%2B-Native-Library-%2B-HTTPS-tp19452525p19452525.html Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
Konstantin Kolinko wrote: 2008/9/12 André Warnier [EMAIL PROTECTED]: Caldarale, Charles R wrote: I'm not sure these days what the normal web character set really is. If you're referring to ASCII (aka Basic Latin), then no, the Pound Sterling symbol is not present. However, for any of the ISO-8859-x variants, it is present, using the 163 (0xA3) value you noted (same as the Unicode code point). It's also in UTF-8 of course, but requires two bytes (0xC2 0xA3) to represent the code point. I love these discussions about character sets. They seem to confuse so many people; even I, who have been involved in them for 30 years... Anyway, I have a related question, which I don't think constitutes a hijack of this thread, because the underlying cause is probably similar. Here it goes : Tomcat (v 4.1, v 5.0, v5.5, have not tried yet in 6.x) The above Tomcat's running under the same Linux or Solaris, essentially set up the same way. The JVM may vary, but I don't think that is the problem, because of the consistency of the problem as explained below. I am running a webapp from an external supplier, always the same binary version. I don't have the code, can't see what's in it. The pages served by that webapp are the same html pages, all of them having a declaration meta http-equiv=Content-Type content=text/html; charset=iso-8859-1. The pages also *are* properly encoded as iso-8859-1 (100% positive, I know the difference). The browser receiving the pages is always the same one, same settings. Now, case a) in the Tomcat startup files, I do nothing, meaning I just take Tomcat out-of-the-box and run the webapp. Result : in any such html page that contains characters with an ISO-8859 codepoint above \xA0 (meaning the displayable characters of the high part of the table, where one finds things like uppercase A with umlaut), these characters - appear in the browser display as ? (minus the quotes) - also if I save the page from the browser to disk, and look at them with an iso-8859-1 capable editor, they are effectively ?. (So it's not the browser misunderstanding them, it is Tomcat sending them that way). case b) In one of the Tomcat startup files (e.g. tomcat_dir/bin/startup.sh or even in /etc/init.d/tomcat5.5), I add the following line LC_CTYPE=en_us.iso88591 (or whatever is valid on that host to specify an iso-8859-1 LC_CTYPE) (before the actual start of Tomcat) and restart Tomcat then the same page displays properly in the browser, and also is correct iso-8859-1 when saved to disk and examined with the editor. (In other words, what previously were ? characters, are now the correct iso-8859-1 character bytes). Now my question is : How can it matter which LC_CTYPE Tomcat is started under, that would have the result above ? The behaviour above is consistent across different hosts, across the same or different Tomcat versions, it is always the same webapp, always the same html pages, always the same browser, etc. Only that LC_CTYPE line changes the behaviour. On the face of it, the only thing I can think of that would explain this, is that the webapp in question does something wrong, but what exactly could it be doing ? Any ideas ? It is [EMAIL PROTECTED] pageEncoding=... % that is missing from those pages. Thus JSP compiler does not know what encoding they are using for their source and messes them at compilation time. [...] But these pages, as far as Tomcat and the webapp are concerned, are not dynamic in any way. They are sraight static html pages. So is the JSP stuff relevant ? (I'm genuinely asking, since I know nothing about JSP pages) - 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: Migrating to tomcat 6 gives formatted currency amounts problem
2008/9/12 André Warnier [EMAIL PROTECTED] Konstantin Kolinko wrote: 2008/9/12 André Warnier [EMAIL PROTECTED]: Caldarale, Charles R wrote: I'm not sure these days what the normal web character set really is. If you're referring to ASCII (aka Basic Latin), then no, the Pound Sterling symbol is not present. However, for any of the ISO-8859-x variants, it is present, using the 163 (0xA3) value you noted (same as the Unicode code point). It's also in UTF-8 of course, but requires two bytes (0xC2 0xA3) to represent the code point. I love these discussions about character sets. They seem to confuse so many people; even I, who have been involved in them for 30 years... Anyway, I have a related question, which I don't think constitutes a hijack of this thread, because the underlying cause is probably similar. Here it goes : Tomcat (v 4.1, v 5.0, v5.5, have not tried yet in 6.x) The above Tomcat's running under the same Linux or Solaris, essentially set up the same way. The JVM may vary, but I don't think that is the problem, because of the consistency of the problem as explained below. I am running a webapp from an external supplier, always the same binary version. I don't have the code, can't see what's in it. The pages served by that webapp are the same html pages, all of them having a declaration meta http-equiv=Content-Type content=text/html; charset=iso-8859-1. The pages also *are* properly encoded as iso-8859-1 (100% positive, I know the difference). The browser receiving the pages is always the same one, same settings. Now, case a) in the Tomcat startup files, I do nothing, meaning I just take Tomcat out-of-the-box and run the webapp. Result : in any such html page that contains characters with an ISO-8859 codepoint above \xA0 (meaning the displayable characters of the high part of the table, where one finds things like uppercase A with umlaut), these characters - appear in the browser display as ? (minus the quotes) - also if I save the page from the browser to disk, and look at them with an iso-8859-1 capable editor, they are effectively ?. (So it's not the browser misunderstanding them, it is Tomcat sending them that way). case b) In one of the Tomcat startup files (e.g. tomcat_dir/bin/startup.sh or even in /etc/init.d/tomcat5.5), I add the following line LC_CTYPE=en_us.iso88591 (or whatever is valid on that host to specify an iso-8859-1 LC_CTYPE) (before the actual start of Tomcat) and restart Tomcat then the same page displays properly in the browser, and also is correct iso-8859-1 when saved to disk and examined with the editor. (In other words, what previously were ? characters, are now the correct iso-8859-1 character bytes). Now my question is : How can it matter which LC_CTYPE Tomcat is started under, that would have the result above ? The behaviour above is consistent across different hosts, across the same or different Tomcat versions, it is always the same webapp, always the same html pages, always the same browser, etc. Only that LC_CTYPE line changes the behaviour. On the face of it, the only thing I can think of that would explain this, is that the webapp in question does something wrong, but what exactly could it be doing ? Any ideas ? It is [EMAIL PROTECTED] pageEncoding=... % that is missing from those pages. Thus JSP compiler does not know what encoding they are using for their source and messes them at compilation time. [...] But these pages, as far as Tomcat and the webapp are concerned, are not dynamic in any way. They are straight static html pages. So is the JSP stuff relevant ? (I'm genuinely asking, since I know nothing about JSP pages) The static HTML pages, as well as all the other static files, are served by the DefaultServlet. You should dig there. I think that fileEncoding initialization parameter of the servlet, as well as mime-mapping settings in web.xml come into play. JSP settings are irrelevant for them, of course. Best regards, Konstantin Kolinko
Re: Migrating to tomcat 6 gives formatted currency amounts problem
- Original Message - From: André Warnier [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, September 12, 2008 10:08 AM Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem Caldarale, Charles R wrote: I'm not sure these days what the normal web character set really is. If you're referring to ASCII (aka Basic Latin), then no, the Pound Sterling symbol is not present. However, for any of the ISO-8859-x variants, it is present, using the 163 (0xA3) value you noted (same as the Unicode code point). It's also in UTF-8 of course, but requires two bytes (0xC2 0xA3) to represent the code point. I love these discussions about character sets. They seem to confuse so many people; even I, who have been involved in them for 30 years... Anyway, I have a related question, which I don't think constitutes a hijack of this thread, because the underlying cause is probably similar. Here it goes : Tomcat (v 4.1, v 5.0, v5.5, have not tried yet in 6.x) The above Tomcat's running under the same Linux or Solaris, essentially set up the same way. The JVM may vary, but I don't think that is the problem, because of the consistency of the problem as explained below. I am running a webapp from an external supplier, always the same binary version. I don't have the code, can't see what's in it. The pages served by that webapp are the same html pages, all of them having a declaration meta http-equiv=Content-Type content=text/html; charset=iso-8859-1. The pages also *are* properly encoded as iso-8859-1 (100% positive, I know the difference). The browser receiving the pages is always the same one, same settings. Now, case a) in the Tomcat startup files, I do nothing, meaning I just take Tomcat out-of-the-box and run the webapp. Result : in any such html page that contains characters with an ISO-8859 codepoint above \xA0 (meaning the displayable characters of the high part of the table, where one finds things like uppercase A with umlaut), these characters - appear in the browser display as ? (minus the quotes) - also if I save the page from the browser to disk, and look at them with an iso-8859-1 capable editor, they are effectively ?. (So it's not the browser misunderstanding them, it is Tomcat sending them that way). case b) In one of the Tomcat startup files (e.g. tomcat_dir/bin/startup.sh or even in /etc/init.d/tomcat5.5), I add the following line LC_CTYPE=en_us.iso88591 (or whatever is valid on that host to specify an iso-8859-1 LC_CTYPE) (before the actual start of Tomcat) and restart Tomcat then the same page displays properly in the browser, and also is correct iso-8859-1 when saved to disk and examined with the editor. (In other words, what previously were ? characters, are now the correct iso-8859-1 character bytes). Now my question is : How can it matter which LC_CTYPE Tomcat is started under, that would have the result above ? The behaviour above is consistent across different hosts, across the same or different Tomcat versions, it is always the same webapp, always the same html pages, always the same browser, etc. Only that LC_CTYPE line changes the behaviour. On the face of it, the only thing I can think of that would explain this, is that the webapp in question does something wrong, but what exactly could it be doing ? Any ideas ? Thanks in advance, André Andre see this link, about halfway down... http://java.sun.com/javase/technologies/core/basic/intl/faq.jsp#core-locale They talking Solaris, which on the default C locale is Ascii... When they do what you doing... more or less... it becomes ISO... So if there is a Java locale function in that web app... one minute its working with ascii, the next with ISO... The page encoding has been hardcoded by the coder to always ISO... Its the Java locale in a web app... I think... Look at the classes in an IDE, or search it... java.util.Locale is hiding in your web-app ;)... I think Thanks... theres the gotcha I was worried about... and you still talking english ;) Does it mean you cant run linux headless?... I wonder... For fun... make your linux box Japanese... I think the web app will really start having fun ... no foreign administrators for you ;) I dont believe at all its Tomcat... its client side Java sitting in servers... gotcha.. The coders broke their own application... all by themselves... admin guys have now got the headache... --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL
RE: [NEWBIE] Apache Tomcat 5.5.17
Its hard to see but arent the extra processes your greps? -Original Message- From: Jon [mailto:[EMAIL PROTECTED] Sent: 11 September 2008 15:11 To: Tomcat Subject: [NEWBIE] Apache Tomcat 5.5.17 I'm using grep to monitor apache process (tomcat apache 5.5.17). It seems to create a new PID every time for each time I query the apache process. *OS: Solaris 5.10* NAME=jcami SSH_CONNECTION=10.159.20.18 4805 10.158.48.20 22 _=/usr/ucb/ps jcami*28775* 0.1 0.1 1280 904 pts/12 S 15:39:46 0:00 tail -f /projects/autotopup/logs/autopay.log SHELL=/bin/bash TERM=vt100 SSH_CLIENT= 10.159.20.18 1167 22 OLDPWD=/projects/tomcat/apache-tomcat-5.5.17-externalwebservices SSH_TTY=/dev/pts/12 USER=jcami SSH_AUTH_SOCK=/tmp/ssh-utE26750/agent.26750 PATH=/usr/bin:/usr/local/bin MAIL=/var/mail//jcami PWD=/export/home/jcami LANG=C TZ=Europe/Malta HOME=/export/home/jcami/ SHLVL=2 LOGNAME=jcami SSH_CONNECTION=10.159.20.18 1167 10.158.48.20 22 _=/usr/bin/tail bash-3.00$ ps -eauxgww | grep 5.5.17 | grep -v grep jcami*28830* 0.1 0.2 3432 3048 pts/7O 15:45:56 0:00 /usr/ucb/ps -eauxgww SHELL=/bin/bash TERM=vt100 SSH_CLIENT=10.159.20.18 4805 22 OLDPWD=/ SSH_TTY=/dev/pts/7 USER=jcami SSH_AUTH_SOCK=/tmp/ssh-Mrh28782/agent.28782 PATH=/usr/bin:/usr/local/bin MAIL=/var/mail//jcami PWD=/projects/tomcat/apache-tomcat-5.5.17-externalwebservices LANG=C TZ=Europe/Malta HOME=/export/home/jcami/ SHLVL=2 LOGNAME=jcami SSH_CONNECTION=10.159.20.18 4805 10.158.48.20 22 _=/usr/ucb/ps jcami*28775 * 0.1 0.1 1280 904 pts/12 S 15:39:46 0:00 tail -f /projects/autotopup/logs/autopay.log SHELL=/bin/bash TERM=vt100 SSH_CLIENT= 10.159.20.18 1167 22 OLDPWD=/projects/tomcat/apache-tomcat-5.5.17-externalwebservices SSH_TTY=/dev/pts/12 USER=jcami SSH_AUTH_SOCK=/tmp/ssh-utE26750/agent.26750 PATH=/usr/bin:/usr/local/bin MAIL=/var/mail//jcami PWD=/export/home/jcami LANG=C TZ=Europe/Malta HOME=/export/home/jcami/ SHLVL=2 LOGNAME=jcami SSH_CONNECTION=10.159.20.18 1167 10.158.48.20 22 _=/usr/bin/tail bash-3.00$ ps -eauxgww | grep 5.5.17 | grep -v grep jcami*28833* 0.1 0.2 3432 3048 pts/7O 15:45:57 0:00 /usr/ucb/ps -eauxgww SHELL=/bin/bash TERM=vt100 SSH_CLIENT=10.159.20.18 4805 22 OLDPWD=/ SSH_TTY=/dev/pts/7 USER=jcami SSH_AUTH_SOCK=/tmp/ssh-Mrh28782/agent.28782 PATH=/usr/bin:/usr/local/bin MAIL=/var/mail//jcami PWD=/projects/tomcat/apache-tomcat-5.5.17-externalwebservices LANG=C TZ=Europe/Malta HOME=/export/home/jcami/ SHLVL=2 LOGNAME=jcami SSH_CONNECTION=10.159.20.18 4805 10.158.48.20 22 _=/usr/ucb/ps jcami*28775* 0.1 0.1 1280 904 pts/12 S 15:39:46 0:00 tail -f /projects/autotopup/logs/autopay.log SHELL=/bin/bash TERM=vt100 SSH_CLIENT= 10.159.20.18 1167 22 OLDPWD=/projects/tomcat/apache-tomcat-5.5.17-externalwebservices SSH_TTY=/dev/pts/12 USER=jcami SSH_AUTH_SOCK=/tmp/ssh-utE26750/agent.26750 PATH=/usr/bin:/usr/local/bin MAIL=/var/mail//jcami PWD=/export/home/jcami LANG=C TZ=Europe/Malta HOME=/export/home/jcami/ SHLVL=2 LOGNAME=jcami SSH_CONNECTION=10.159.20.18 1167 10.158.48.20 22 _=/usr/bin/tail Any idea why, please? Rgds, -- Jon Camilleri Mobile (MT): 00356 7982 7113 E-mail: [EMAIL PROTECTED] Please consider your environmental responsibility before printing this e-mail. I usually reply to e-mails within 2 business days. If it's urgent, give me a call. *** This message may contain confidential and privileged information. If you are not the intended recipient you should not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents. To do so is strictly prohibited and may be unlawful. Please inform the sender that this message has gone astray before deleting it. Thank you. 2008 marks the 60th anniversary of the NHS. It's an opportunity to pay tribute to the NHS staff and volunteers who help shape the service, and celebrate their achievements. If you work for the NHS and would like an NHSmail email account, go to: www.connectingforhealth.nhs.uk/nhsmail *** - 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: SNMP tomcat 5.5!
On Thu, Sep 11, 2008 at 09:29:14PM +0100, Mark Thomas wrote: Shahar Cohen wrote: Hi, Can anybody please tell me how I can monitor by SNMP tomcat sites without querying the admin module which I disabled for security reasons? Is there any MIBS that I can use? In short, you can't. Tomcat does not provide SNMP, even with the Admin app. Hep probably means something like this: http://java.sun.com/j2se/1.5.0/docs/guide/management/SNMP.html -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is intuitive he means the exact opposite. pgpiyHtWzogOb.pgp Description: PGP signature
Re: Migrating to tomcat 6 gives formatted currency amounts problem
Konstantin Kolinko wrote: 2008/9/12 André Warnier [EMAIL PROTECTED] Konstantin Kolinko wrote: 2008/9/12 André Warnier [EMAIL PROTECTED]: Caldarale, Charles R wrote: I'm not sure these days what the normal web character set really is. If you're referring to ASCII (aka Basic Latin), then no, the Pound Sterling symbol is not present. However, for any of the ISO-8859-x variants, it is present, using the 163 (0xA3) value you noted (same as the Unicode code point). It's also in UTF-8 of course, but requires two bytes (0xC2 0xA3) to represent the code point. I love these discussions about character sets. They seem to confuse so many people; even I, who have been involved in them for 30 years... Anyway, I have a related question, which I don't think constitutes a hijack of this thread, because the underlying cause is probably similar. Here it goes : Tomcat (v 4.1, v 5.0, v5.5, have not tried yet in 6.x) The above Tomcat's running under the same Linux or Solaris, essentially set up the same way. The JVM may vary, but I don't think that is the problem, because of the consistency of the problem as explained below. I am running a webapp from an external supplier, always the same binary version. I don't have the code, can't see what's in it. The pages served by that webapp are the same html pages, all of them having a declaration meta http-equiv=Content-Type content=text/html; charset=iso-8859-1. The pages also *are* properly encoded as iso-8859-1 (100% positive, I know the difference). The browser receiving the pages is always the same one, same settings. Now, case a) in the Tomcat startup files, I do nothing, meaning I just take Tomcat out-of-the-box and run the webapp. Result : in any such html page that contains characters with an ISO-8859 codepoint above \xA0 (meaning the displayable characters of the high part of the table, where one finds things like uppercase A with umlaut), these characters - appear in the browser display as ? (minus the quotes) - also if I save the page from the browser to disk, and look at them with an iso-8859-1 capable editor, they are effectively ?. (So it's not the browser misunderstanding them, it is Tomcat sending them that way). case b) In one of the Tomcat startup files (e.g. tomcat_dir/bin/startup.sh or even in /etc/init.d/tomcat5.5), I add the following line LC_CTYPE=en_us.iso88591 (or whatever is valid on that host to specify an iso-8859-1 LC_CTYPE) (before the actual start of Tomcat) and restart Tomcat then the same page displays properly in the browser, and also is correct iso-8859-1 when saved to disk and examined with the editor. (In other words, what previously were ? characters, are now the correct iso-8859-1 character bytes). Now my question is : How can it matter which LC_CTYPE Tomcat is started under, that would have the result above ? The behaviour above is consistent across different hosts, across the same or different Tomcat versions, it is always the same webapp, always the same html pages, always the same browser, etc. Only that LC_CTYPE line changes the behaviour. On the face of it, the only thing I can think of that would explain this, is that the webapp in question does something wrong, but what exactly could it be doing ? Any ideas ? It is [EMAIL PROTECTED] pageEncoding=... % that is missing from those pages. Thus JSP compiler does not know what encoding they are using for their source and messes them at compilation time. [...] But these pages, as far as Tomcat and the webapp are concerned, are not dynamic in any way. They are straight static html pages. So is the JSP stuff relevant ? (I'm genuinely asking, since I know nothing about JSP pages) The static HTML pages, as well as all the other static files, are served by the DefaultServlet. You should dig there. I think that fileEncoding initialization parameter of the servlet, as well as mime-mapping settings in web.xml come into play. JSP settings are irrelevant for them, of course. Hi. Thanks for the intent and answer above. But I insist : these html pages are served by that webapp of which I am talking, not by the DefaultServlet. Those pages are being accessed via URLs like http://myhost.mycompany.com/myservlet?..(additional parameters indicating which static file to serve).. It is on the way through that servlet that they get corrupted, unless I start Tomcat with LC_CTYPE=iso-8859-1. That servlet, in its own web.xml config file in tomcat_dir/webapps/myservlet/WEB-INF/web.xml, has no fileEncoding nor mime-mapping section nor parameter. So my question remains, I think : what could be going on in that servlet so that : - if LC_CTYPE is not set in the environment *of Tomcat* when it starts, the upper iso-8859-1 characters in the pages are replaced by ? - if LC_CTYPE is set to iso-8859-1 in the Tomcat environment when it starts, then the pages delivered by the servlet are correct ? I am not very qualified in Java, but could it be something like : - the
NoClassDefFoundError: org.apache.catalina.realm.RealmBase
Hi, I've written a custom Realm, set up according the Realm-howto from Tomcat Documentation. I use RealmBase.Digest to digest passwords. The Realm works, in that users are authenticated properly. But I've also written a code to allow the user to change their password, using RealmBase.Digest to digest the password. But I'm getting NoClassDefFoundError: org.apache.catalina.realm.RealmBase I have catalina.jar in WEB-INF/lib Can anyone shed some light on what I'm doing wrong? Thanks, C. -- View this message in context: http://www.nabble.com/NoClassDefFoundError%3A-org.apache.catalina.realm.RealmBase-tp19458032p19458032.html Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
Hi, Have you checked the configuration for this catalina opts?: -Duser.language=es -Duser.country=ES Check that they are the same in both tomcats. (In this case, for instance, is configured for Spanish-Spain) Good Luck Best, Toni -Original Message- From: André Warnier [mailto:[EMAIL PROTECTED] Sent: viernes, 12 de septiembre de 2008 16:58 To: Tomcat Users List Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem Konstantin Kolinko wrote: 2008/9/12 André Warnier [EMAIL PROTECTED] Konstantin Kolinko wrote: 2008/9/12 André Warnier [EMAIL PROTECTED]: Caldarale, Charles R wrote: I'm not sure these days what the normal web character set really is. If you're referring to ASCII (aka Basic Latin), then no, the Pound Sterling symbol is not present. However, for any of the ISO-8859-x variants, it is present, using the 163 (0xA3) value you noted (same as the Unicode code point). It's also in UTF-8 of course, but requires two bytes (0xC2 0xA3) to represent the code point. I love these discussions about character sets. They seem to confuse so many people; even I, who have been involved in them for 30 years... Anyway, I have a related question, which I don't think constitutes a hijack of this thread, because the underlying cause is probably similar. Here it goes : Tomcat (v 4.1, v 5.0, v5.5, have not tried yet in 6.x) The above Tomcat's running under the same Linux or Solaris, essentially set up the same way. The JVM may vary, but I don't think that is the problem, because of the consistency of the problem as explained below. I am running a webapp from an external supplier, always the same binary version. I don't have the code, can't see what's in it. The pages served by that webapp are the same html pages, all of them having a declaration meta http-equiv=Content-Type content=text/html; charset=iso-8859-1. The pages also *are* properly encoded as iso-8859-1 (100% positive, I know the difference). The browser receiving the pages is always the same one, same settings. Now, case a) in the Tomcat startup files, I do nothing, meaning I just take Tomcat out-of-the-box and run the webapp. Result : in any such html page that contains characters with an ISO-8859 codepoint above \xA0 (meaning the displayable characters of the high part of the table, where one finds things like uppercase A with umlaut), these characters - appear in the browser display as ? (minus the quotes) - also if I save the page from the browser to disk, and look at them with an iso-8859-1 capable editor, they are effectively ?. (So it's not the browser misunderstanding them, it is Tomcat sending them that way). case b) In one of the Tomcat startup files (e.g. tomcat_dir/bin/startup.sh or even in /etc/init.d/tomcat5.5), I add the following line LC_CTYPE=en_us.iso88591 (or whatever is valid on that host to specify an iso-8859-1 LC_CTYPE) (before the actual start of Tomcat) and restart Tomcat then the same page displays properly in the browser, and also is correct iso-8859-1 when saved to disk and examined with the editor. (In other words, what previously were ? characters, are now the correct iso-8859-1 character bytes). Now my question is : How can it matter which LC_CTYPE Tomcat is started under, that would have the result above ? The behaviour above is consistent across different hosts, across the same or different Tomcat versions, it is always the same webapp, always the same html pages, always the same browser, etc. Only that LC_CTYPE line changes the behaviour. On the face of it, the only thing I can think of that would explain this, is that the webapp in question does something wrong, but what exactly could it be doing ? Any ideas ? It is [EMAIL PROTECTED] pageEncoding=... % that is missing from those pages. Thus JSP compiler does not know what encoding they are using for their source and messes them at compilation time. [...] But these pages, as far as Tomcat and the webapp are concerned, are not dynamic in any way. They are straight static html pages. So is the JSP stuff relevant ? (I'm genuinely asking, since I know nothing about JSP pages) The static HTML pages, as well as all the other static files, are served by the DefaultServlet. You should dig there. I think that fileEncoding initialization parameter of the servlet, as well as mime-mapping settings in web.xml come into play. JSP settings are irrelevant for them, of course. Hi. Thanks for the intent and answer above. But I insist : these html pages are served by that webapp of which I am talking, not by the DefaultServlet. Those pages are being accessed via URLs like http://myhost.mycompany.com/myservlet?..(additional parameters indicating which static file to serve).. It is on the way through that servlet that they get corrupted, unless I start Tomcat with LC_CTYPE=iso-8859-1. That servlet, in its own web.xml config
RE: Migrating to tomcat 6 gives formatted currency amounts problem
From: André Warnier [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem - the servlet reads those documents with some InputStream, without specifying a character set or encoding, and by default that means to use Tomcat's idea of its default LC_CTYPE for those InputStreams ? Essentially correct, if you substitute JVM for Tomcat in the above. Input and output are done via byte streams, converted to and from Unicode based on the specified character encoding. When that's not specified (via Connector attribute or HTTP header), the JVM uses a default encoding. To determine the default, JVM initialization looks at various system properties if they exist, and then certain environment variables. (The exact ones are platform dependent.) Consequently, setting LC_CTYPE (or equivalent) prior to starting up Tomcat can have a dramatic effect on the interpretation of both input and output, as you have discovered. Look at the API doc for java.io.InputStreamReader and java.io.OutputStreamWriter for examples of character set encoding usage. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
From: Caldarale, Charles R Subject: RE: Migrating to tomcat 6 gives formatted currency amounts problem Consequently, setting LC_CTYPE (or equivalent) prior to starting up Tomcat can have a dramatic effect on the interpretation of both input and output, as you have discovered. Also, as Johnny K stated, this should not be left up to the sys admin. It really is the app writers' job to explicitly specify the encoding for both input and output, rather than leaving them up to the whims of the platform and browser. Unfortunately, many developers design with blinders on, and never think about where the app might be deployed or accessed from. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: Beginner
On 12 Sep 2008 at 13:07, sathish kumar wrote: Send reply to: Tomcat Users List users@tomcat.apache.org Date sent: Fri, 12 Sep 2008 13:07:25 +0530 From: sathish kumar [EMAIL PROTECTED] To: users@tomcat.apache.org Subject:Beginner Hi Everyone, I have joined the tomcat project. Could you point to me to some study material where I can understand the architecture of tomcat and how things work? I'm not sure what you are exactly looking for but since Tomcat follows the Java Servlet Specifications it might help to read that. Depending on which version of tomcat you are using (since each one implements a diff. version of the spec.) http://java.sun.com/products/servlet/download.html -Steve O. I have some knowledge on Java, JSP and Servlets. P.S: As this is the first time I am posting, please correct me If I have posted something wrong Thanks and Regards, Sathish Kumar - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remote debugging via shmem, Tomcat as a service
I'm trying to get remote debugging working with Tomcat using a shared memory connection. I've been calling it remote debugging but the server and debug client (my IDE) are on the same host. Everything works well when I start Tomcat from the command line (bin/startup.bat). I have the following JAVA_OPTIONS set in my environment variables: -Xdebug -Xrunjdwp:transport=dt_shmem,address=jdbconnect,server=y,suspend=n I can connect to the debugger with my IDE (JCreator 4.50.010) and debug happily. I can also see that the debugger is listening on that shared memory address in stdout. However, when I start Tomcat as a service, the shared memory connection seems to be unavailable. I have set the following Java Options in the Configure Tomcat panel: -Xdebug -Xrunjdwp:transport=dt_shmem,address=jdbconnect,server=y,suspend=n My IDE can't connect to the shmem address, and the log (logs/stdout.log) doesn't show anything about the debugger listening. I'm running Tomcat 5.0.28, jdk 1.5.0_16, on Windows XP SP2. Thanks in advance for any ideas suggestions. Cheers, Bryan
RE: Migrating to tomcat 6 gives formatted currency amounts problem
From: Johnny Kewl [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem If this locale stuff is in fact defaulting to an ISO char set that can do these symbols... There's the basic problem - anytime you allow defaults to come into play you put yourself at risk. and say you where making a non english page, say Japanese... do you think that its possible to use it? Certainly, and you should use it - but with the desired Locale specified, not using whatever the default happens to be at that instant. they using the getCurrencyInstance to make the currency symbols. But, if you want a specific currency symbol (e.g., Yen, Pound Sterling), the Locale should be explicitly provided on the API call; only if you want to use the platform's default should the getCurrencyInstance() without an argument be used. But I'm thinking its a US/Eng only methodology... Nope, it's universal. Java supports a seemingly infinite number of locales. When you say If I override that with say ISO-8859-15, is that the whole page you talking about Yes, I was setting the browser to use a fixed encoding rather than the one in the HTTP header or the browser default. it possible to have different character encoding sections in a web page I don't know HTML well enough to completely answer that question, but I believe HTTP uses the last character set header specified, and all HTTP headers must precede the HTML. You should be able to achieve the desired effect with frames. However, if you just use UTF-8, you don't need to worry about, since that includes every code point in the known universe. if I do look at that test page in a MS tool... it displays correctly with mixed encodings? MS cheats at every opportunity, seemingly avoiding standards whenever they can. IE likes to guess at the intent of the web page, sometimes getting it right, often getting it horribly wrong. But when you choose a font in a text editor like Swing or Word, you are also picking some character set... Nope - most editors do not let you choose the character encoding, they just use the platform default. Some do let you choose a UTF-x flavor in lieu of the platform default, which is quite desirable. Some fonts (e.g., Wingdings) redefine the glyphs for given code points in order to display oddball symbols within a non-Unicode encoding; these were pretty much all developed before Unicode came into widespread use, but are still around for compatibility. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johnny, Johnny Kewl wrote: If this locale stuff is in fact defaulting to an ISO char set that can do these symbols... and say you where making a non english page, say Japanese... do you think that its possible to use it? It is up to your browser to choose a font that is appropriate for all glyphs (that is, a graphical representation of a code point) that need to be displayed. Some fonts do not support all codepoints because they don't have all the glyphs. For instance, if you have a string in English and also Sanskrit, your browser is likely to display one string in one font (maybe Arial) and the other in another font (say, Sanskrit). Let's say that the browser comes across the pound; entity. pound; maps directly to 8-bit hex character code 0xa3 (http://htmlhelp.com/reference/html40/entities/latin1.html). Whether you put pound; or £ in your HTML, the browser should render it properly -- possibly switching fonts to one that supports that code point for that character only. The problem with your page is not that the £ symbol is not available in the font the browser chose. Your problem is that you illegally encoded it into the page in the first place (or, equivalently, you advertise the wrong encoding for the page, which is really the same thing). If you re-write your page to declare some font around that symbol, you will never be able to get it to work, unless you use the browser to override the server-declared encoding (as Chuck did, when things render properly when using ISO-8859-1). I've actually now seen examples on the web that are doing it Wil's way, they using the getCurrencyInstance to make the currency symbols. Use of Java's built-in currency-symbol-generating methods are likely to produce a proper £ symbol. If you have your encoding chain set up properly, it should go from NumberFormat.format() straight to your web page without a hint of difficulty. But I'm thinking its a US/Eng only methodology... when applied to a web page. Do you think using getCurrencyInstance is generalizable in other languages? Absolutely. The only reason $ is a magic symbol is because it's part of US-ASCII and low enough in the symbol table so that it never gets screwed up by incorrect encodings. Symbols like £ or € do not share that luxury and are therefore error-prone when administrators poorly configure their servers. It's further compounded by the fact that many English-specking coders forget that there are other people in the world. :( When you say If I override that with say ISO-8859-15, is that the whole page you talking about, or it possible to have different character encoding sections in a web page thats another area thats confusing me now, because if I do look at that test page in a MS tool... it displays correctly with mixed encodings? The encoding is for the entire document, not just a single character. basically, you sent an illegal character code. It would be like sending 6 bits of an 8-bit byte. In fact, that's /exactly/ what you did because, to a UTF-8 renderer, your set of 8 bits looks like there should be something else /before/ it in order to make it legal. Your server said hey, client... I'm gonna send you a bunch of oranges and then went right ahead and sent apples mixed-in with those oranges. But when you choose a font in a text editor like Swing or Word, you are also picking some character set... and thats whats been injected into the page as its been formed... Yes and no. Many encodings are limited by a particular character set (for instance, US-ASCII is never going to have Sanskrit letters in it). But that'd why Unicode was invented: to make sure that anything we'd ever possibly want to show on the screen is possible because we have enough bits to display it. (My understanding is that Unicode (16-bit) is actually not big enough for everything, but hey, they tried). The beauty of UTF-8 is that every character you'd want to display has its own code that nobody can steal -- regardless of the font being used. The lesson is to always use UTF-8 and make sure you actually have everything working properly. If your server is saying utf-8 but the character encoding on your servlet Writer is actually ISO-8859-1 then you haven't done your job and your web pages are going to look broken when non-latin characters are thrown in there. The same is true if you are serving static content (as I suspect you are in your example) and advertising that it is utf-8 but the file was written with ISO-8859-1 (or something else). (In your case, the problem is that text files contain no explicit encoding information in them, so the server has to guess -- or, more likely, there's no guessing going on, and the server just blindly uses whatever its default has been configured to be.) I screw up terminology... ok we all know that but Does Wil need to worry about the way he is doing it?... thats all I'm asking... I think so... The short
Re: Isn't there a PDF style document for v6？
Here is the official link. http://tomcat.apache.org/tomcat-6.0-doc/index.html. http://tomcat.apache.org/tomcat-6.0-doc/index.html But if you know nothing about tomcat before, a book might be a better place to start. Such as this one http://www.amazon.com/Tomcat-Definitive-Guide-Jason-Brittain/dp/0596101066/ref=pd_bbs_sr_1?ie=UTF8s=booksqid=1221237237sr=1-1 Guojun On Fri, Sep 12, 2008 at 3:21 AM, 叶双明 [EMAIL PROTECTED] wrote: Hi all! Can i download a PDF style document from somewhere, or other style? Please show me the url. Thanks! -- Sorry for my english!! 明 Please help me to correct my english expression and error in syntax
RE: 回复： about Connector's attribute red irectPort
From: 李征 [mailto:[EMAIL PROTECTED] Subject: 回复： about Connector's attribute redirectPort this is my setting for connector Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=150 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ That's the Connector for port 8009; if you want Tomcat to listen for HTTPS on 8443, you need another Connector for that port. The one for 8443 is commented out in server.xml by default. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Migrating to tomcat 6 gives formatted currency amounts problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, Caldarale, Charles R wrote: From: Johnny Kewl [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem if I do look at that test page in a MS tool... it displays correctly with mixed encodings? MS cheats at every opportunity, seemingly avoiding standards whenever they can. IE likes to guess at the intent of the web page, sometimes getting it right, often getting it horribly wrong. Yes, they do. MS, contrary to W3 specifications, sniffs the content of a page and chooses the encoding and ignores any server-specified encoding. It also does this with MIME types. (Sorry, can't find the reference right now). Real web browsers do not behave in this way, so you shouldn't base your conclusions on the behavior of MSIE. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKmzYACgkQ9CaO5/Lv0PBgEACfbFlp6HuBiTd93kGzrtOOVRhV G4AAn2zaU1HGZA9isoewMQ3J5TZMsPjF =E83R -END PGP SIGNATURE- - 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: Migrating to tomcat 6 gives formatted currency amounts problem
From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem (My understanding is that Unicode (16-bit) is actually not big enough for everything, but hey, they tried). Point of clarification: Unicode is NOT limited to 16 bits (not even in Java, these days). There are defined code points that use 32 bits, and I don't think there's a limit, if you use the defined extension mechanisms. Again, browsing the Unicode web site is extremely enlightening. Unless the browser sucks. ;) Let me guess which browser that is; does it start with an I? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, André Warnier wrote: The pages served by that webapp are the same html pages, all of them having a declaration meta http-equiv=Content-Type content=text/html; charset=iso-8859-1. Note that using META tags to set character sets is a bit dangerous. You're telling the client to ignore the character set indicated by the server which was (probably) responsible for encoding the document in the first place. For static documents, where the server doesn't know any better, and is probably sending binary data and doing no interpretation or encoding of any kind, it's probably okay. The pages also *are* properly encoded as iso-8859-1 (100% positive, I know the difference). So, for instance, the British pound symbol in your source documents (read using an ISO-8859-1-configured viewer) looks correct? The browser receiving the pages is always the same one, same settings. Did you check the md5sum of that page on both the client and the server? I suspect they are actually different. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKnOAACgkQ9CaO5/Lv0PBbBQCguAzYccOcY1sCgTbsxlXi5Lq5 SfQAn0HMhCIjmL5VENVqvOkwi1G73pI8 =FCfS -END PGP SIGNATURE- - 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: Migrating to tomcat 6 gives formatted currency amounts problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, André Warnier wrote: It is on the way through that servlet that they get corrupted, unless I start Tomcat with LC_CTYPE=iso-8859-1. What do the HTTP headers say when the file is served correctly versus when it is not? I suspect that the encoding is either set incorrectly or not set at all unless you specify LC_CTYPE. So my question remains, I think : what could be going on in that servlet so that : - if LC_CTYPE is not set in the environment *of Tomcat* when it starts, the upper iso-8859-1 characters in the pages are replaced by ? - if LC_CTYPE is set to iso-8859-1 in the Tomcat environment when it starts, then the pages delivered by the servlet are correct ? My guess is that the magic servlet here is using the platform's default encoding in the HTTP headers, which may be incorrect for the static file in question. I am not very qualified in Java, but could it be something like : - the servlet reads those documents with some InputStream, without specifying a character set or encoding Note that InputStreams are encoding-less. Sounds like semantics, but encodings only come into play with you are dealing with character-oriented streams which, in Java, are called Readers and Writers. Note that neither InputStream nor OutputStream have any methods that deal with the char data type. and by default that means to use Tomcat's idea of its default LC_CTYPE for those InputStreams ? - or the servlet outputs the document via an OutputStream without specifying an encoding etc.. I'll bet a binary stream of data is being sent (that is, with no interpretation or encoding) and that the JVM's default encoding is being advertised by the server in the HTTP headers. That would certainly cause the problem. I've found that the default encoding on my Linux box is something I've never heard of before: file.encoding=ANSI_X3.4-1968. Since I have my server configured properly (and don't really serve much in the way of static content), the platform's default encoding doesn't matter: my preferred encoding (UTF-8) is always used. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKntcACgkQ9CaO5/Lv0PAjWACgquvyCh3SDJdqBxPPx3+zOwQ4 z3QAoKL8C5k0ZI3B6Hl4GyuDcZrcnrRf =HPFJ -END PGP SIGNATURE- - 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: NoClassDefFoundError: org.apache.catalina.realm.RealmBase
From: Carol Cheung [mailto:[EMAIL PROTECTED] Subject: NoClassDefFoundError: org.apache.catalina.realm.RealmBase I have catalina.jar in WEB-INF/lib Can anyone shed some light on what I'm doing wrong? Putting catalina.jar in WEB-INF/lib is certainly one major error. Remove it. You must never, never put the same classes in more than one spot in a given branch of the classloader tree. Not telling us the version of Tomcat you're using is another error. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
From: Johnny Kewl [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem Does it mean you cant run linux headless?... Of course you can (think about blade servers). Now you're confusing graphical display with encoding. The term headless is concerned with the ability to display graphical information, not render it. JVMs running in headless mode can render glyphs, graphs, or what have you, but must send the resulting bit maps to some graphics server to have it displayed (it can also be saved in files if needed). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem (My understanding is that Unicode (16-bit) is actually not big enough for everything, but hey, they tried). Point of clarification: Unicode is NOT limited to 16 bits (not even in Java, these days). Sorry, I was trying to say 16-bit Unicode without saying UTF-16 (which is not the same). And regarding Java... the 'char' data type is /defined/ to be 16-bits wide (http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.1). Has this changed? When? (And how!?) I always thought it was weird for Java to use 16-bit Unicode internally, but then use UTF-8 for all serialized strings. I guess that's what you get when you try to minimize file sizes and download times. There are defined code points that use 32 bits, and I don't think there's a limit, if you use the defined extension mechanisms. Again, browsing the Unicode web site is extremely enlightening. Unless the browser sucks. ;) Let me guess which browser that is; does it start with an I? I usually spell it with an 'M'. ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKomMACgkQ9CaO5/Lv0PC1OQCeP8FkNni/J320StYPF4lNeQWi o84AnReYYyjaF+ljUub4wJ2HSkcOA3Jk =JJir -END PGP SIGNATURE- - 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: NoClassDefFoundError: org.apache.catalina.realm.RealmBase
From: Carol Cheung [mailto:[EMAIL PROTECTED] Subject: NoClassDefFoundError: org.apache.catalina.realm.RealmBase I have catalina.jar in WEB-INF/lib Can anyone shed some light on what I'm doing wrong? Putting catalina.jar in WEB-INF/lib is certainly one major error. Remove it. You must never, never put the same classes in more than one spot in a given branch of the classloader tree. Not telling us the version of Tomcat you're using is another error. - Chuck Sorry, I'm using Tomcat 5.5. I removed catalina.jar from WEB-INF/lib and I am still getting the same error. -- View this message in context: http://www.nabble.com/NoClassDefFoundError%3A-org.apache.catalina.realm.RealmBase-tp19458032p19460362.html Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johnny, Johnny Kewl wrote: Use this function System.out.print(CharSet : + Charset.defaultCharset().toString()); and thats what you HAVE TO set your page at On my system it tells me its. windows-1252 I think you're still missing something: the file on the disk has an implicit file encoding that is not advertised in any way. This is the core of the problem. If all text files said hey, I'm encoded in UTF-8 or I'm in ISO-8859-1 or This file is WINDOWS-1252, then there would be no problem: all code would use the native encoding of the file as the encoding of the HTTP response, and the file would be streamed as binary without changing a single bit in the stream. Unfortunately, this is better known as explicit encoding and basically doesn't exist (except in some UTF-encoded files). Since the server doesn't know the file's original encoding, it /can never make a sensible decision about the output encoding/. It's simply not possible. It has nothing to do with your OS, of your filesystem, or your per-user locale preferences, installed fonts, etc. It has to do with the fact that the file has no explicit encoding and the server can use. (This is what gives rise to the MSIE practice of sniffing the document content regardless of the server's assertion as to the character encoding). ... it a headache... rather refactor your code so the pages are all the same charset of your choosing and work with pound, yen dollar This is always a sensible way to go. If you stick to pages that always use US-ASCII or anything compatible with it (generally ISO-8859-*, I think), you'll be good to go. A much better way to go is to always use properties files for text that will be displayed on web pages. It's the right thing to do from a localization perspective (yes, you can have separate pages for each language, but that's no fun), AND the encoding for Java properties files is DEFINED TO BE ISO-8859-1, no matter what you want to put in there. In this case, there /is/ an explicit character encoding, and it's predictable. Of course, Java coders can always bone the creation of these files... - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKpQoACgkQ9CaO5/Lv0PDW4ACdEHqsgCK2IrHF1Bl6cz40Wben liYAn00FVbmPpVAl35Zh6nDd1Q5Cxh/d =4lJ4 -END PGP SIGNATURE- - 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: Fw: Tomcat Patch Management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anand, Anand Gundanna wrote: So, do you think Automatic windows patch management and manual tomcat patch management would ideal as patch releases from Tomcat is very rare? Yes. Given that you have to test the hell out of your application whenever you switch application servers, you wouldn't want to do it in an automated way, anyway. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKpXYACgkQ9CaO5/Lv0PCYhwCfdnDxtkXAdlOOX9+ZYr1R2HM5 JRYAoK7FrtWc3a44q9JcKvmTZwCw8/iA =3oJH -END PGP SIGNATURE- - 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: about Connector's attribute redirectPort
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 李征, 李征 wrote: If this Connector is supporting non-SSL requests, and a request is received for which a matching security-constraint requires SSL transport, Catalina will automatically redirect the request to the port number specified here. The default value is 443. but i still don't understand what redirectPort is used for. When you are using HTTP (non-secure) and your security settings for a resource (set using transport-guarantee in the security-constraint sections of web.xml) call for a CONFIDENTIAL or INTEGRAL transport, HTTP is not considered acceptable. In this case, Tomcat will issue a redirect to the client (web browser) indicating that HTTPS should be used. Sometimes, the port number you want to use is not 443 (the default). If you want to override this default, you can use the redirectPort attribute to set that port. For instance, if you are running a standard web server configuration, you'll want to set redirectPort=443 (or leave it out entirely, as this is the default). If, instead, your HTTPS server is listening on port 12345, then you'll want redireftPort=12345. If you don't use HTTPS, then you can safely ignore this setting. Honestly, this attribute could have a better name (perhaps, secureRedirectPort or something like that). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKptAACgkQ9CaO5/Lv0PCdlACfQknLbNm8YRmaj5+fgNKvYjKd 074An28V+Iv8JnBIBpgLFR/uatDGcbC0 =ygE4 -END PGP SIGNATURE- - 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: Migrating to tomcat 6 gives formatted currency amounts problem
From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem the 'char' data type is /defined/ to be 16-bits wide (http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.1). Has this changed? When? (And how!?) A char is still 16 bits, but you can now have 21-bit code points: http://java.sun.com/javase/6/docs/api/java/lang/Character.html#unicode These are manipulated via the int type, rather than char. I always thought it was weird for Java to use 16-bit Unicode internally Back when Java was being defined, Unicode still was 16-bit, but not in widespread use. but then use UTF-8 for all serialized strings Mostly for easy interoperation with existing editors, comm handlers, browsers, etc., which were all byte oriented and, at the time, still largely ASCII. The day-one existence of character encoders in Java permitted use in non-ASCII environments. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: NoClassDefFoundError: org.apache.catalina.realm.RealmBase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carol, Carol Cheung wrote: Sorry, I'm using Tomcat 5.5. I removed catalina.jar from WEB-INF/lib and I am still getting the same error. You should put your Realm implementation into $TOMCAT_HOME/shared/lib or $TOMCAT_HOME/common/lib. I suspect you have deployed it with your application. This is an error, as Tomcat prevents applications from interacting with Tomcat's internals (including its own classes) except in very well-defined ways. If you want Tomcat to use your realm, you will have to make it available to Tomcat -- not just your own application. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKp8sACgkQ9CaO5/Lv0PAFrACfQ2GX6/0N9pX0BsP7ZkGowFsI Cb8An3DFduFqG23yRT2NnsJQGNppWlR7 =fstM -END PGP SIGNATURE- - 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: NoClassDefFoundError: org.apache.catalina.realm.RealmBase
From: Carol Cheung [mailto:[EMAIL PROTECTED] Subject: RE: NoClassDefFoundError: org.apache.catalina.realm.RealmBase Sorry, I'm using Tomcat 5.5. I removed catalina.jar from WEB-INF/lib and I am still getting the same error. Look at the Tomcat 5.5 classloader structure: Bootstrap | System | Common / \ Catalina Shared / \ Webapp1 Webapp2 ... The 5.5 Realm doc says: * Place your compiled realm in $CATALINA_HOME/server/lib (which is Catalina in the above diagram). However, if you do that, your Realm class(es) will not be visible to code in your webapp. You'll need to put your Realm in common/lib (or common/classes, if not jar'd) to let both Tomcat and your webapp have access to your code. BTW, it's easier in 6.0 due to the simplified classloader structure. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
Christopher Schultz wrote: [...] Yes, they do. MS, contrary to W3 specifications, sniffs the content of a page and chooses the encoding and ignores any server-specified encoding. It also does this with MIME types. (Sorry, can't find the reference right now). [...] Here is a start, sympathetic to Microsoft : http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx And here is another relevant MS technical document (not for the faint of heart) : http://msdn.microsoft.com/en-us/library/ms775147.aspx On the other hand, the HTTP 1.1 RFC section 7.2.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1 says : quote Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type application/octet-stream. unquote (notice the *if and only if* the media type is not given..) In other words, IE's content sniffing is in clear violation of the HTTP 1.1 RFC, 99% of the time. On the other hand, I once read a justification by one of the Microsoft developers (as I recall that one was related to their implementation of DAV, or Web Folders), which essentiually said this : there are hundreds of millions of Windows (and IE) users, and most of them are *not* developers. So, although we are ourselves developers and we would very much like to adhere to the standards, our marketing people just won't let us, if it risks inconveniencing several hundred million average Windows users (and Microsoft customers), just to please the tiny minority of several hundred thousand developers. I think it's an argument, even a relatively democratic one ... I also personally believe that if the Microsoft developers had not started down the path a long time ago to believe that they could be smarter than everyone else and could outguess webservers, and instead had respected the HTTP RFC and just been more careful about which documents IE opens (or worse, runs), they would have saved Microsoft and the world countless bugs, countless viri and countless unproductive hours of web-developer's forced work-arounds. What I do not however understand is, considering the flak that each IE bug or security advisory generates, why MS have never decided to create and market another parallel browser (or maybe just one checkbox in the regular IE), that would make it RFC-compliant. This way users could just choose to either use a browser that is RFC-compliant and boring and safe(r), or else enjoy all the gimmicks but risk the consequences. But hey, I also do not know in how many viri-scanning companies MS owns shares.. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
Nope - most editors do not let you choose the character encoding, they just use the platform default. Some do let you choose a UTF-x flavor in lieu of the platform default, which is quite desirable. Some fonts (e.g., Wingdings) redefine the glyphs for given code points in order to display oddball symbols within a non-Unicode encoding; these were pretty much all developed before Unicode came into widespread use, but are still around for compatibility. You know your stuff Chuck ;) Wonder if Wil knew he asked such a damn big question... ha ha Ok... some more homework on this thing... Servlet Response does in fact have a setLocale(Locale loc) function... Which seems to indicate that if headers or something like response.setContentType(text/html;charset=UTF-8); is *not* used... TC will take on the encoding(ha ha did it again) charset of that locale... I find thinking outside of HTTP headers difficult... and it seems that servlet spec has recognized the conflict inherent in locale and http header. It seems that prior to Servlet spec 2.4 if a coder used locale dependent JSTL to access resource bundles... that would in fact override setContentType this apparently is no longer the case... the header takes pref... So André thats what you could well be seeing in your application because the charset would follow the locale and that would be whatever the JRE wants to give you... ie the coder didnt even have to explicitly use a locale function a JSTL call using a resource bundle will do it... Its seems they are trying to bring locale technology that one applies in Swing without too much thought and web technology a little closer... Still lots of places to get caught it seems... I think you just got to put on a different hat when doing Swing and Web internationalization... different animals, with just enough commonality to cause pain ;) --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - 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: Migrating to tomcat 6 gives formatted currency amounts problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johnny, Johnny Kewl wrote: Servlet Response does in fact have a setLocale(Locale loc) function... Which seems to indicate that if headers or something like response.setContentType(text/html;charset=UTF-8); is *not* used... TC will take on the encoding(ha ha did it again) charset of that locale... Nope! Locale != charset. Locale does not even hint of a /preferred/ charset. I find thinking outside of HTTP headers difficult... and it seems that servlet spec has recognized the conflict inherent in locale and http header. It seems that prior to Servlet spec 2.4 if a coder used locale dependent JSTL to access resource bundles... that would in fact override setContentType this apparently is no longer the case... the header takes pref... Well, the header comes from the encoding set on the response, so it should all be the same. I think you just got to put on a different hat when doing Swing and Web internationalization... You shouldn't have to. The only difference is the character encoding for the requests and responses. The use of the Java API should be identical. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKyHcACgkQ9CaO5/Lv0PDxDQCfazFHZjh/amrJBOkauDCFmwN0 rQoAoLYmA3A8Y6hbhaMN3dNeJckoy2YV =4bXQ -END PGP SIGNATURE- - 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: Migrating to tomcat 6 gives formatted currency amounts problem
On Fri, Sep 12, 2008 at 9:26 PM, Johnny Kewl [EMAIL PROTECTED] wrote: Wonder if Wil knew he asked such a damn big question... ha ha I'm really amazed at the volume of mails my question has raised. I can only see one solution to this complexity: let's all (everybody in the whole world) speak the same language, use the same currency and move into one and the same timezone (the latter because of past fun with timezones)! Willem
Re: Migrating to tomcat 6 gives formatted currency amounts problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem the 'char' data type is /defined/ to be 16-bits wide (http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.1). Has this changed? When? (And how!?) A char is still 16 bits, but you can now have 21-bit code points: http://java.sun.com/javase/6/docs/api/java/lang/Character.html#unicode These are manipulated via the int type, rather than char. Interesting... so, Java is still 16-bit Unicode in its char primitive, but you can use ints to hold UTF-16 values using 21-bits? Wo, that's confusing... especially since java.lang.Character only takes a char as a constructor parameter :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKygAACgkQ9CaO5/Lv0PB5lgCfSaUnFHFx+OaL87mPtCsGcTOd pkwAn0ob9OTMfrGCXk4udHyKg627Fd2k =XWif -END PGP SIGNATURE- - 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: Migrating to tomcat 6 gives formatted currency amounts problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Willem, Willem Moors wrote: I can only see one solution to this complexity: let's all (everybody in the whole world) speak the same language, use the same currency and move into one and the same timezone (the latter because of past fun with timezones)! You're not far off, except that you probably mean we should all speak one human language (like English or Farsi or whatever). I agree, but only if you mean we should all speak the same character language. It should be UTF-8. All hail UTF-8! Seriously, switch to UTF-8. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjKyuwACgkQ9CaO5/Lv0PCqFQCbB/9xp+ELXOONuWn7lQvo5hd8 jasAnjtoDUrn3d1kVoFjCcvLmg2R3KI2 =0DqD -END PGP SIGNATURE- - 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: Migrating to tomcat 6 gives formatted currency amounts problem
Caldarale, Charles R wrote: From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem (My understanding is that Unicode (16-bit) is actually not big enough for everything, but hey, they tried). Point of clarification: Unicode is NOT limited to 16 bits (not even in Java, these days). There are defined code points that use 32 bits, and I don't think there's a limit, if you use the defined extension mechanisms. Again, browsing the Unicode web site is extremely enlightening. Further clarification : Unicode is not limited to anything. Unicode is (aims to be) a list which attributes to any distinct character known to man, a number, from 0 to infinity. The particular position number given to a particular character in this Unicode list is known as its Unicode codepoint. The Unicode group (consortium ?) also tries to do this with some order, such as trying to keep together (with consecutive codepoints) various groups of characters that are logically related in some way. For example (but probably because they had to start somewhere), the first 128 codepoints match the original 7-bit US-ASCII alphabet; so for instance the capital letter A, which has code \x41 in US-ASCII, happens to have Unicode codepoint \x0041 (both 65 in decimal terms). For example also, the same first 128 codepoints, plus the next 128 codepoints, match the iso-8859-1 alphabet (also known as iso-latin-1); thus the character known as capital letter A with umlaut (an A with a double-dot on top) has the codepoint \x00C4 in Unicode, and the code \xC4 in iso-8859-1 (both 196 in decimal). New Unicode characters (and codepoints) are being added all the time (I think there's even Klingon in there), but there are also holes in the list (presumably left for whenever some forgotten related character shows up). A quite different issue is encoding. Because it would be quite impractical to specify a series of characters just by writing their codepoints one after the other (using whatever number of bits each codepoint needs), a series of clever schemes have been devised in order to pass Unicode strings around, while being able to separate them into characters, and keep each one with its proper codepoint. Such schemes are known as Unicode encodings with names such as UTF-2, UTF-7, UTF-8, UTF-16, UTF-32, etc.. Each one of them specifies an algorithm whereby one can take any Unicode character (or rather, its codepoint), and encode it into a series of bits, in such a way that at the receiving end, an opposite algorithm can be used to decode that series of bits and retrieve once again the same series of Unicode codepoints (or characters). UTF-16, for example, is an encoding of Unicode which uses always 16 bits for each Unicode codepoint; but it is to my knowledge incomplete, because since it uses a fixed number of 16 bit per character, it can thus only ever represent no more than the first 65,532 Unicode characters. (But we're not there yet, and there is still some leeway). UTF-8 on the other hand is a variable-length scheme, using 1, 2, 3, or more 8-bit groups to represent each Unicode codepoint. And it is in principle not limited, as there are extension mechanisms foreseen for whenever the need arises (imagine that some aliens suddenly show up, and that they happen to write in 167 different languages and alphabets). One frequent misconception is that in UTF-8, the first 256 character encoding bit sequences match the iso-8859-1 codepoints. Only the first 128 characters of iso-8859-1 (which happen to match the 128 characters of US-ASCII and the first 128 Unicode codepoints), have a single-byte representation in UTF-8 which happens to match their Unicode codepoint. The next 128 iso-8859-1 characters (which contain the capital A with umlaut) require 2 bytes each in the UTF-8 encoding. Thus for instance, the capital letter A with umlaut has the Unicode codepoint \x00C4 (196 decimal), because is is the 197th character in the Unicode list (and the first one is \x). It also happens to have the code \xC4 (196 decimal) in the iso-8859-1 table. But in UTF-8, it is encoded as the two bytes \xC3\x84, which is not the decimal number 196 in any way. All of that to say that when some people on this list say things like you should always decode your URLs as if they were Unicode (or UTF-8), because it is the same as ASCII or iso-latin-1 anyway, they are talking nonsense. The only time you can do that is when the server and all the clients have agreed in advance that this is how they were going to encode and decode URLs. (That we developers wish it were so, and that ultimately we may get there, is another matter.) It is also talking nonsense to say that you should by default consider html pages as UTF-8 encoded. The default character set (and encoding, because in that case both are the same) for html is iso-8859-1, and anything
Re: Migrating to tomcat 6 gives formatted currency amounts problem
Rectification to the clarification : what I say below about UTF-16 being always 16-bit and limited is also nonsense. UTF-16 is variable-length, it can cover the entire Unicode character set. It just uses a variable number of 16-bit words per character, as compared to UTF-8 which uses a variable number of 8-bit bytes. I should have checked my sources. Shame on me. About Java's internal char type being 16-bit wide though, I have heard that too, and I'm also curious. André Warnier wrote: Caldarale, Charles R wrote: From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem (My understanding is that Unicode (16-bit) is actually not big enough for everything, but hey, they tried). Point of clarification: Unicode is NOT limited to 16 bits (not even in Java, these days). There are defined code points that use 32 bits, and I don't think there's a limit, if you use the defined extension mechanisms. Again, browsing the Unicode web site is extremely enlightening. Further clarification : Unicode is not limited to anything. Unicode is (aims to be) a list which attributes to any distinct character known to man, a number, from 0 to infinity. The particular position number given to a particular character in this Unicode list is known as its Unicode codepoint. The Unicode group (consortium ?) also tries to do this with some order, such as trying to keep together (with consecutive codepoints) various groups of characters that are logically related in some way. For example (but probably because they had to start somewhere), the first 128 codepoints match the original 7-bit US-ASCII alphabet; so for instance the capital letter A, which has code \x41 in US-ASCII, happens to have Unicode codepoint \x0041 (both 65 in decimal terms). For example also, the same first 128 codepoints, plus the next 128 codepoints, match the iso-8859-1 alphabet (also known as iso-latin-1); thus the character known as capital letter A with umlaut (an A with a double-dot on top) has the codepoint \x00C4 in Unicode, and the code \xC4 in iso-8859-1 (both 196 in decimal). New Unicode characters (and codepoints) are being added all the time (I think there's even Klingon in there), but there are also holes in the list (presumably left for whenever some forgotten related character shows up). A quite different issue is encoding. Because it would be quite impractical to specify a series of characters just by writing their codepoints one after the other (using whatever number of bits each codepoint needs), a series of clever schemes have been devised in order to pass Unicode strings around, while being able to separate them into characters, and keep each one with its proper codepoint. Such schemes are known as Unicode encodings with names such as UTF-2, UTF-7, UTF-8, UTF-16, UTF-32, etc.. Each one of them specifies an algorithm whereby one can take any Unicode character (or rather, its codepoint), and encode it into a series of bits, in such a way that at the receiving end, an opposite algorithm can be used to decode that series of bits and retrieve once again the same series of Unicode codepoints (or characters). UTF-16, for example, is an encoding of Unicode which uses always 16 bits for each Unicode codepoint; but it is to my knowledge incomplete, because since it uses a fixed number of 16 bit per character, it can thus only ever represent no more than the first 65,532 Unicode characters. (But we're not there yet, and there is still some leeway). UTF-8 on the other hand is a variable-length scheme, using 1, 2, 3, or more 8-bit groups to represent each Unicode codepoint. And it is in principle not limited, as there are extension mechanisms foreseen for whenever the need arises (imagine that some aliens suddenly show up, and that they happen to write in 167 different languages and alphabets). One frequent misconception is that in UTF-8, the first 256 character encoding bit sequences match the iso-8859-1 codepoints. Only the first 128 characters of iso-8859-1 (which happen to match the 128 characters of US-ASCII and the first 128 Unicode codepoints), have a single-byte representation in UTF-8 which happens to match their Unicode codepoint. The next 128 iso-8859-1 characters (which contain the capital A with umlaut) require 2 bytes each in the UTF-8 encoding. Thus for instance, the capital letter A with umlaut has the Unicode codepoint \x00C4 (196 decimal), because is is the 197th character in the Unicode list (and the first one is \x). It also happens to have the code \xC4 (196 decimal) in the iso-8859-1 table. But in UTF-8, it is encoded as the two bytes \xC3\x84, which is not the decimal number 196 in any way. All of that to say that when some people on this list say things like you should always decode your URLs as if they were Unicode (or UTF-8), because it is the same as ASCII or iso-latin-1 anyway,
Re: Migrating to tomcat 6 gives formatted currency amounts problem
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Willem, Willem Moors wrote: I can only see one solution to this complexity: let's all (everybody in the whole world) speak the same language, use the same currency and move into one and the same timezone (the latter because of past fun with timezones)! You're not far off, except that you probably mean we should all speak one human language (like English or Farsi or whatever). I agree, but only if you mean we should all speak the same character language. It should be UTF-8. All hail UTF-8! Seriously, switch to UTF-8. That reminds me of the old joke, about England deciding to switch from driving on the (wrong) left side of the road instead of the (correct) right side. To minimise disruptions, they were going to do it in stages; the trucks first, the cars a week later. Anyway, there is a flaw in the above suggestions, if taken together : if we all spoke and wrote the same language, there would be no need for Unicode nor for multi-byte character encodings. Unless the language was Chinese of course. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
Just for the sake of completeness : Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, André Warnier wrote: It is on the way through that servlet that they get corrupted, unless I start Tomcat with LC_CTYPE=iso-8859-1. What do the HTTP headers say when the file is served correctly versus when it is not? I suspect that the encoding is either set incorrectly or not set at all unless you specify LC_CTYPE. So my question remains, I think : what could be going on in that servlet so that : - if LC_CTYPE is not set in the environment *of Tomcat* when it starts, the upper iso-8859-1 characters in the pages are replaced by ? - if LC_CTYPE is set to iso-8859-1 in the Tomcat environment when it starts, then the pages delivered by the servlet are correct ? My guess is that the magic servlet here is using the platform's default encoding in the HTTP headers, which may be incorrect for the static file in question. I am not very qualified in Java, but could it be something like : - the servlet reads those documents with some InputStream, without specifying a character set or encoding Note that InputStreams are encoding-less. Sounds like semantics, but encodings only come into play with you are dealing with character-oriented streams which, in Java, are called Readers and Writers. Note that neither InputStream nor OutputStream have any methods that deal with the char data type. and by default that means to use Tomcat's idea of its default LC_CTYPE for those InputStreams ? - or the servlet outputs the document via an OutputStream without specifying an encoding etc.. I'll bet a binary stream of data is being sent (that is, with no interpretation or encoding) and that the JVM's default encoding is being advertised by the server in the HTTP headers. That would certainly cause the problem. The last tine I looked, the http headers sent along with the documents were the same in both cases. It is physically (if that's the appropriate expression in this case) the high iso-8859-1 characters (bytes) in the htnl document that are being replaced by ? (single-byte low-ascii question mark), on the way from the disk file to the browser, via the servlet. And if the LC_CTYPE of java (and Tomcat) is set to iso-8859-1 in the Tomcat startup script, it is no longer the case. So I (now) believe that Chuck's earlier explanation is the correct one : the servlet reads the disk document with a Reader (thanks Chris), without specifying an encoding when it opens this Reader. The effect is thus as follows : - if the LC_CTYPE environment variable is not set for Java and Tomcat, this Reader is opened using whichever encoding happens to be then the JVM's default. Obviously, in this case it is not iso-8859-1. The servlet thus reads the iso-8859-1 data, but with the wrong decoder. I guess then that this decoder replaces anything that does not fit into that default encoding, by a ?. (Would it do that, or would it trigger an exception ?) So that is what the servlet reads, and it passes it unchanged to it's Writer and to the browser. (Alternatively, it is at the level of the Writer of the servlet that the wrong encoding is used, or both). - if the LC_CTYPE variable is set to iso-8859-1, then these reader_Writer default to that as an encoding, and everything works fine. Fortunately setting the LC_CTYPE in the Tomcat startup script does not seem to affect other applications on the server; that is probably because this particular servlet is the only sloppy one, which does not explicitly specify an encoding when reading or writing stuff. (It's also because in this case, there are not many other servlets apart from the sloppy one). Now I'm writing the above without a solid knowledge of Java or Tomcat behind, so it's mostly guessing. If someone has a good reason for shooting this down as an explanation, I'm still open. I'll post another question under another title, I think this thread is long enough by now. Thanks to all though. André - 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: Tomcat Patch Management
Mark Thomas wrote: Anand Gundanna wrote: Dear Support, I would request for your help in regards to Tomcat Patch Management. I hope you will be helpful in this regard. We have installed and configured an Tomcat web server on windows server platform for an application called Business Objects XI. Tomcat web servers will not be supported/maintained by our web services team as it is non strategic within our organisation. But still we have hosted the Tomcat servers as it is mandated by Business Objects application. Now the Tomcat Web server has been successfully installed and configured. We need to plan for Patch management for Tomcat. At the moment we do not have any external/third party tool to manage the patches automatically. So, could you please clarify the following queries.. 1) What is the best procedure/practice to keep Tomcat up-to-date with patches? There are no patches, only full releases. 2) How frequently does Tomcat releases patches/updates and how critical it is for an internal application? ~3 per year. How critical is your call. If it ain't broke... 3) Does Tomcat have any built in tool/feature to download and update patches automatically? Nope. Please let me know if you know any other easy option/solution for Tomcat Patch Management. There are commercial support provides that will provide simpler patch management options. Or safer bet, depending on how well the application is designed (and how critical it is)... install a staging server with the new Tomcat release, and copy the application over and test. I do not know of any 100% proof patch/upgrade for any software. 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] -- Regards Gabe Wong NGASI AppServer Manager JAVA AUTOMATION and SaaS Enablement for Cloud Computing http://www.ngasi.com NEW! FREE Developer account for Hosted version on Amazon EC2 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat/servlet question
Hi. In response to a request, a servlet opens and reads a file from disk, and sends the content out to the browser (ultimately), as is. The content of the file is an html document, saved as a text under some encoding, correctly encoded under that encoding, and containing an html meta http-equiv=Content-type: text/html; charset= where the specified encoding is correct and matches the document's. The in stream (the disk file) is opened raw, and the same for the out stream. Question : who is responsible for setting the HTTP response headers ? Does the servlet have to set them explicitly ? or does Tomcat do that itself if the servlet doesn't ? (*) (I am specifically interested in headers like Content-type and Content-length). (*) and if Tomcat does, how does it know what to put there ? Thanks in advance, André - 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: Tomcat/servlet question
André Warnier wrote: Hi. In response to a request, a servlet opens and reads a file from disk, and sends the content out to the browser (ultimately), as is. The content of the file is an html document, saved as a text under some encoding, correctly encoded under that encoding, and containing an html meta http-equiv=Content-type: text/html; charset= where the specified encoding is correct and matches the document's. That's nice but it means nothing to the Servlet container. The in stream (the disk file) is opened raw, and the same for the out stream. Question : who is responsible for setting the HTTP response headers ? It varies, depending on the header. Does the servlet have to set them explicitly ? Yes, kind of. You don't need to set the header directly but, for encoding etc, you do need to call one of the methods that will cause it to be set. or does Tomcat do that itself if the servlet doesn't ? (*) Tomcat will. The spec defines the defaults. The short version is ISO-8859-1. You'll need to enable STRICT_SERVLET_COMPLIANCE to get 100% spec compliant behaviour in this area. See http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html (I am specifically interested in headers like Content-type and Content-length). Content-type is the servlet's problem. Tomcat will normally look after content-length. (*) and if Tomcat does, how does it know what to put there ? The spec defines it. If we were talking about the default servlet, the fileEncoding parameter would also affect behaviour. 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]
Re: Migrating to tomcat 6 gives formatted currency amounts problem
- Original Message - From: André Warnier [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, September 12, 2008 10:56 PM Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem Just for the sake of completeness : Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, André Warnier wrote: It is on the way through that servlet that they get corrupted, unless I start Tomcat with LC_CTYPE=iso-8859-1. What do the HTTP headers say when the file is served correctly versus when it is not? I suspect that the encoding is either set incorrectly or not set at all unless you specify LC_CTYPE. So my question remains, I think : what could be going on in that servlet so that : - if LC_CTYPE is not set in the environment *of Tomcat* when it starts, the upper iso-8859-1 characters in the pages are replaced by ? - if LC_CTYPE is set to iso-8859-1 in the Tomcat environment when it starts, then the pages delivered by the servlet are correct ? My guess is that the magic servlet here is using the platform's default encoding in the HTTP headers, which may be incorrect for the static file in question. I am not very qualified in Java, but could it be something like : - the servlet reads those documents with some InputStream, without specifying a character set or encoding Note that InputStreams are encoding-less. Sounds like semantics, but encodings only come into play with you are dealing with character-oriented streams which, in Java, are called Readers and Writers. Note that neither InputStream nor OutputStream have any methods that deal with the char data type. and by default that means to use Tomcat's idea of its default LC_CTYPE for those InputStreams ? - or the servlet outputs the document via an OutputStream without specifying an encoding etc.. I'll bet a binary stream of data is being sent (that is, with no interpretation or encoding) and that the JVM's default encoding is being advertised by the server in the HTTP headers. That would certainly cause the problem. The last tine I looked, the http headers sent along with the documents were the same in both cases. It is physically (if that's the appropriate expression in this case) the high iso-8859-1 characters (bytes) in the htnl document that are being replaced by ? (single-byte low-ascii question mark), on the way from the disk file to the browser, via the servlet. And if the LC_CTYPE of java (and Tomcat) is set to iso-8859-1 in the Tomcat startup script, it is no longer the case. So I (now) believe that Chuck's earlier explanation is the correct one : the servlet reads the disk document with a Reader (thanks Chris), without specifying an encoding when it opens this Reader. The effect is thus as follows : - if the LC_CTYPE environment variable is not set for Java and Tomcat, this Reader is opened using whichever encoding happens to be then the JVM's default. Obviously, in this case it is not iso-8859-1. The servlet thus reads the iso-8859-1 data, but with the wrong decoder. I guess then that this decoder replaces anything that does not fit into that default encoding, by a ?. (Would it do that, or would it trigger an exception ?) So that is what the servlet reads, and it passes it unchanged to it's Writer and to the browser. (Alternatively, it is at the level of the Writer of the servlet that the wrong encoding is used, or both). - if the LC_CTYPE variable is set to iso-8859-1, then these reader_Writer default to that as an encoding, and everything works fine. Fortunately setting the LC_CTYPE in the Tomcat startup script does not seem to affect other applications on the server; that is probably because this particular servlet is the only sloppy one, which does not explicitly specify an encoding when reading or writing stuff. (It's also because in this case, there are not many other servlets apart from the sloppy one). Now I'm writing the above without a solid knowledge of Java or Tomcat behind, so it's mostly guessing. If someone has a good reason for shooting this down as an explanation, I'm still open. I'll post another question under another title, I think this thread is long enough by now. Thanks to all though. By goerge... I think you have it... the locale encoding is taking preference over the header. In theory... in newer servlets that will no longer happen... the header now overrules locale encoding. If you do decide to look at this link... http://java.sun.com/javase/technologies/core/basic/intl/faq.jsp#core-locale Whats happening to you is described at the very bottom ;) --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
Tomcat shutdown event
Hello, I have a servelet spawn a thread that should run until tomcat is shutdown. The problem is, when Tomcat is shut down, the thread keeps running. Does Tomcat have a shutdown event that I could use to trigger the thread destruction? If not, is there any graceful way of handling this? Thanks - 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: Migrating to tomcat 6 gives formatted currency amounts problem
From: André Warnier [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem The servlet thus reads the iso-8859-1 data, but with the wrong decoder. I guess then that this decoder replaces anything that does not fit into that default encoding, by a ?. (Would it do that, or would it trigger an exception ?) I believe (but have not verified) that the substitution occurs for any decoding errors. At least, I can't find any exceptions defined for the APIs that perform decoding. I'll post another question under another title, I think this thread is long enough by now. Nah, let's go for the record. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: Migrating to tomcat 6 gives formatted currency amounts problem
From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: Migrating to tomcat 6 gives formatted currency amounts problem so, Java is still 16-bit Unicode in its char primitive, but you can use ints to hold UTF-16 values using 21-bits? The 21-bit values are represented by pairs of Java chars, the first from the UTF-16 high-surrogate range, the second from the low-surrogate range. The 21-bit code point can be accessed as an int by some of the java.lang.Character methods introduced in 1.5. especially since java.lang.Character only takes a char as a constructor parameter :( Yes, I think all the new Character methods related to code points are static; there are corresponding instance methods in java.lang.String though. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: Remote debugging via shmem, Tomcat as a service
2008/9/12 Bryan D. Fish [EMAIL PROTECTED]: I'm trying to get remote debugging working with Tomcat using a shared memory connection. I've been calling it remote debugging but the server and debug client (my IDE) are on the same host. Everything works well when I start Tomcat from the command line (bin/startup.bat). I have the following JAVA_OPTIONS set in my environment variables: -Xdebug -Xrunjdwp:transport=dt_shmem,address=jdbconnect,server=y,suspend=n I can connect to the debugger with my IDE (JCreator 4.50.010) and debug happily. I can also see that the debugger is listening on that shared memory address in stdout. However, when I start Tomcat as a service, the shared memory connection seems to be unavailable. I have set the following Java Options in the Configure Tomcat panel: -Xdebug -Xrunjdwp:transport=dt_shmem,address=jdbconnect,server=y,suspend=n My IDE can't connect to the shmem address, and the log (logs/stdout.log) doesn't show anything about the debugger listening. I'm running Tomcat 5.0.28, jdk 1.5.0_16, on Windows XP SP2. Thanks in advance for any ideas suggestions. Cheers, Bryan Hi, Bryan! I would try running Tomcat service with your own user account, instead of the default Local System one. Maybe that will help you. BTW: The JPDA documentation says that the Shared Memory Transport is implemented using memory-mapped files. You may try to dig there, http://msdn.microsoft.com/en-us/library/aa366551(VS.85).aspx http://msdn.microsoft.com/en-us/library/aa366559(VS.85).aspx Best regards, Konstantin Kolinko - 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: Tomcat shutdown event
2008/9/13 Tom Cat [EMAIL PROTECTED]: I have a servlet spawn a thread that should run until tomcat is shutdown. The problem is, when Tomcat is shut down, the thread keeps running. Does Tomcat have a shutdown event that I could use to trigger the thread destruction? If not, is there any graceful way of handling this? You may implement a o.a.c.LifecycleListener see http://tomcat.apache.org/tomcat-6.0-doc/config/context.html Also, the Servlet spec provides the ServletContextListener interface. Also, Java has support for JVM shutdown hooks. Also, if you start your own thread you may want to call Thread.setDaemon(true), because non-demon (default) threads prevent JVM from shutdown. Best regards, Konstantin Kolinko - 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: Regarding Error 404-please help!
Hi Ognjen, Thanks so much for your help. I have tried your suggestions, but the site still wouldn't show my servlet. Althought i have noticed something else which i am not sure if is related to the issue we're talking about. I reinstall my Apache server and Tomcat. In my Tomcat training manual, it said if you were to browse to http://127.0.0.1 with Apache running you would get a web page showing. However, when i browsed to http://127.0.0.1 or http://localhost, it showed Forbidden You don't have permission to access / on this server Apache/2.0.63 (Win32) mod_jk/1.2.26 Server at 127.0.0.1 Port 80 I do have this entry in my host file. So i was just wondering if my previous issue has anything to do with the above problem at all. Your help is greatly appreciated!! Regards, Laura Date: Fri, 12 Sep 2008 10:07:19 +0200 From: [EMAIL PROTECTED] To: users@tomcat.apache.org Subject: Re: Regarding Error 404-please help! It is really hard to pinpoint your problem whit such a huge web.xml. But, let's try. First, for servlet HelloWorld you stated the class name /servlet/HelloWorld. That is wrong. Class name should be fully qualified Java class name like: com.something.servlet.HelloWorld. Second, in your servlet mapping, your url pattern for servlet mapping is HelloWorld. First mistake is the leading space, remove it. Second, in your first message, I see that you try to invoke your servlet at url /servlet/HelloWorld. If you want do invoke your servlet on that URL, you must put in url-mapping something like /servlet/HelloWorld. HTH, Ognjen laura fu wrote: Hi Ognjen,Thanks for your reply! Here is my web.xml from jjolt application: ?xml version=1.0 encoding=ISO-8859-1?!DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd;web-app display-nameJJOLT servlets/display-name description JJOLT servlets Examples. /description servlet servlet-nameHelloWorld/servlet-name servlet-class/servlet/HelloWorld/servlet-class /servlet servlet servlet-nameHello/servlet-name servlet-class/servlet/Hello/servlet-class /servlet servlet servlet-nameAttributes/servlet-name servlet-classAttributes/servlet-class /servlet servlet servlet-namePostAttributes/servlet-name servlet-classPostAttributes/servlet-class /servlet servlet servlet-nameAddToShoppingCart/servlet-name servlet-classAddToShoppingCart/servlet-class /servlet servlet servlet-nameShoppingCartURLRewrite/servlet-name servlet-classShoppingCartURLRewrite/servlet-class /servlet servlet servlet-nameReviewShoppingCart/servlet-name servlet-classReviewShoppingCart/servlet-class /servlet servlet servlet-nameShoppingCartCookies/servlet-name servlet-classShoppingCartCookies/servlet-class /servlet servlet servlet-namePageCountUsingSessionAPI/servlet-name servlet-classPageCountUsingSessionAPI/servlet-class /servlet servlet servlet-nameSaveSessionData/servlet-name servlet-classSaveSessionData/servlet-class /servlet servlet servlet-nameShoppingCartSessionTracking/servlet-name servlet-classShoppingCartSessionTracking/servlet-class /servlet servlet servlet-namegetExample/servlet-name servlet-classAttributes/servlet-class /servlet servlet servlet-namegetInitializationParameters/servlet-name servlet-classInit_param/servlet-class init-param param-nameversion /param-name param-valuebest/param-value /init-param /servlet servlet-mapping servlet-nameHelloWorld/servlet-name url-pattern HelloWorld/url-pattern /servlet-mapping servlet-mapping servlet-nameHello/servlet-name url-pattern/servlet/Hello/url-pattern /servlet-mapping servlet-mapping servlet-nameAttributes/servlet-name url-pattern/servlet/Attributes/url-pattern /servlet-mapping servlet-mapping servlet-namePostAttributes/servlet-name url-pattern/servlet/PostAttributes/url-pattern /servlet-mapping servlet-mapping servlet-nameAddToShoppingCart/servlet-name url-pattern/servlet/AddToShoppingCart/url-pattern /servlet-mapping servlet-mapping servlet-nameReviewShoppingCart/servlet-name url-pattern/servlet/ReviewShoppingCart/url-pattern /servlet-mapping servlet-mapping servlet-nameShoppingCartURLRewrite/servlet-name url-pattern/servlet/ShoppingCartURLRewrite/*/url-pattern /servlet-mapping servlet-mapping servlet-nameShoppingCartCookies/servlet-name url-pattern/servlet/ShoppingCartCookies/url-pattern /servlet-mapping servlet-mapping servlet-namePageCountUsingSessionAPI/servlet-name url-pattern/servlet/PageCountUsingSessionAPI/url-pattern /servlet-mapping servlet-mapping servlet-nameSaveSessionData/servlet-name url-pattern/servlet/SaveSessionData/url-pattern /servlet-mapping servlet-mapping servlet-nameShoppingCartSessionTracking/servlet-name url-pattern/servlet/ShoppingCartSessionTracking/url-pattern /servlet-mapping
