RE: Entity in web.xml
The first message, XmlMapper: Can't find resource for entity: jspdecl -- /var/tomcat4/webapps/ROOT/WEB-INF/jspdecl.xml null is irrelevant. It only tells you Tomcat has no cached entity for the specified public identifier. You know, Tomcat actually caches entities for some well known public identifiers (-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN for example, so it doesn't have to fetch it from http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; phisically every time). I guess it chokes on absolute path. I use relative paths only, so I guess the XML parser can locate the entity file relative to the XML file. Try either using a relative path, or using absolute path prefixed with file:// If this doesn't work, I have no further ideas. Cheers, Attila. -Original Message- From: Benoit Mahe [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 11:24 AM To: Szegedi, Attila Cc: [EMAIL PROTECTED] Subject: RE: Entity in web.xml Well, it still doesn't works :( Now I got: XmlMapper: Can't find resource for entity: jspdecl -- /var/tomcat4/webapps/ROOT/WEB-INF/jspdecl.xml null PARSE error at line 0 column 0 org.xml.sax.SAXParseException: File /var/tomcat4/webapps/ROOT/WEB-INF/jspdecl.xml not found. Thank you for your help. Regards, Benoit. On Fri, 2002-03-22 at 10:57, Szegedi, Attila wrote: Try declaring your ENTITY using a public identifier: !ENTITY jspdecl PUBLIC jspdecl /var/tomcat4/webapps/ROOT/WEB-INF/jspdecl.xml This works for me altough I've only used Tomcat 3.x versions this far. Cheers, Attila. -Original Message- From: Benoit Mahe [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 10:49 AM To: Szegedi, Attila; Cc: Benoit Mahe Subject: Entity in web.xml Hello, I'm trying to use entity in web.xml for tomcat 4.0.3, but it doesn't work: Here is my web.xml: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; [ !ENTITY jspdecl SYSTEM /var/tomcat4/webapps/ROOT/WEB-INF/jspdecl.xml ] web-app !-- ... -- jspdecl; /web-app But when tomcat starts, I got an exception: 2002-03-22 09:39:42 ContextConfig[] Parse error in application web.xml java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:320) at org.apache.catalina.util.xml.XmlMapper.resolveEntity(XmlMapper .java:441) at org.apache.xerces.readers.DefaultEntityHandler.startReadingFro mExternalEntity(DefaultEntityHandler.java) at org.apache.xerces.readers.DefaultEntityHandler.startReadingFro mEntity(DefaultEntityHandler.java) ... Are you using entities in web.xml with tomcat 4.0.3? Regards, Benoit Mahe. -- -- Benoit Mahe-- -- ActiVia Networks -- -- Constellation Manager, Project Leader -- -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Running Tomcat without tools.jar (javac) after precompiling my jsp's.
You should run jspc with -webinc switch. It will generate an XML fragment that you should add to your web.xml file (either by copy/paste or by including it as an entity); It will look like this: servlet servlet-namecom.mycompany.foo.myjsppage/servlet-name servlet-classcom.mycompany.foo.myjsppage/servlet-class /servlet servlet-mapping url-pattern/com/mycompany/foo/myjsppage.jsp/url-pattern servlet-namehu.scriptum.rolemgr.addrole/servlet-name /servlet-mapping If you don't like the default URL patterns, change them to what you like. I invoke jspc through Ant, so a replace task after jspc-invoking java task does the job. One thing to watch for is that the compiled classes depend on the org.apache.jasper.runtime package, so your webapp will either be tied to Tomcat, or you should distribute org.apache.jasper.runtime package (found in jasper.jar) with your webapp. Also please note that questions regarding Tomcat usage should go to tomcat-user list instead. Attila.
RE: problem with national language in html form input
Hi Attila, Well, sound simple but I think it's a bit more... How can the server guess what will be the encoding in the first page it sends ( that will be used back to send the form, etc ) ? Even if you know the language ( say it's japanese ), there are many charsets that could be used. Even better idea that came to mind since the previous letter is to always assume the session charset is same as the charset of last response Writer. I think this would suffice for most real world scenarios. It would break only when a) sessions use multiple charsets b) sessions get multiple requests concurrently. Both cases are rare in my opinion. If we are going to rely on the fact that the browser will use the original encoding I would rather send UTF in the first page. One case I don't know how to deal with - say we have a form to type a name. And we have people from Japan, Europe, etc - who might have non-ascii letters in their names. There is no way to know what charset to use to decode - or to send the original page. We can't set 8859-2 on the first page - or jis or anything else ( because we don't know what the user is going to type ). In my eyes, UTF-8 is definitely the way to go if you think globally. Cheers, Attila.
RE: problem with national language in html form input
I have also done this once in my private copy of Tomcat, but have abandoned it. The problem is standards compliance, and standards (both the HTML standard and the Servlet spec) are somewhat internationalization-ignorant on this point. Tomcat follows the HTML standard, which explicitly declares that MIME type "application/x-www-form-urlencoded" is suitable ONLY for transferring ASCII (but will of course work for ISO 8859-1 as well). See http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1 It says: citation "The content type "application/x-www-form-urlencoded" is inefficient for sending large quantities of binary data or text containing non-ASCII characters. The content type "multipart/form-data" should be used for submitting forms that contain files, non-ASCII data, and binary data." /citation So, if you want to comply with the HTML standard, you should force sending all of your forms containing non-ASCII characters as "multipart/form-data" using the "enctype" attribute of the form. Unfortunately, Tomcat will not present "multipart/form-data" to your servlet as request parameters. The HTML standard is further flawed in that it 1. defaults the encoding type of the form to "application/x-www-form-urlencoded" 2. requires browsers to send form data in the same encoding they received the HTML page in, (except if "accept-charset" attribute is set, which is usually not). So, a complying browser will by default use "application/x-www-form-urlencoded" and send data through it in the same encoding they received the HTML page in. The trouble is, that they wont send the *ENCODING* back to the server in the Content-Type header (at least all IE (up to 5.5) and NN (up to 4.75) won't). It will always be "application/x-www-form-urlencoded" and not "application/x-www-form-urlencoded; charset=whatever"), so Tomcat's parsePostData can't determine the charset, it will always sense ISO 8859-1, as this is the default. I have some back experience working with Microsoft's ASP technology. They solved the problem partially by introducing the "session encoding" -- all HTML response used this encoding, and all request parameters were parsed according to that encoding. This could be a solution, however it should go into servlet spec. (Are we heard, servlet spec people?) My own app uses ISO 8859-2 (as it's in Hungarian), and for now I just transcode 8859-1 into 8859-2. I'm lucky I use Model2 paradigm, so I have a single servlet handling all requests and a single central place to transcode request parameters. Cheers, Attila. -Original Message- From: Aleksandras Novikovas [mailto:[EMAIL PROTECTED]] Sent: Friday, March 16, 2001 10:32 AM To: '[EMAIL PROTECTED]' Subject: problem with national language in html form input Hello All, I'm posting for the first time, so please inform me if I do something wrong ... First of all - problem description : I have application in multilanguage (where user can dynamically change charset). Problem rises when user enters information in selected language. After parsePostData in HttpUtils I get lots of "" instead of text. I can not rely on default system encoding, because application has ability to add the languages dynamically without recompilation. So I never know what next encoding system will need. I have written some code to work around this problem and think it would be nice to have it standard package. Actually I've changed parsePostData - added encoding parameter. Now programmer could choose in what encoding InputStream is supplied. I have tested it with windows-1257 (Baltic) and windows-1251 (Cyrylic) - for me it worked. If someone find any errors - please let me know. Here is code of that method : // // // Parses data from an HTML form that the client sends to // the server using the HTTP POST method and the // iapplication/x-www-form-urlencoded/i MIME type. // // pThe data sent by the POST method contains key-value // pairs. A key can appear more than once in the POST data // with different values. However, the key appears only once in // the hashtable, with its value being // an array of strings containing the multiple values sent // by the POST method. // // pThe keys and values in the hashtable are stored in their // decoded form, so // any + characters are converted to spaces, and characters // sent in hexadecimal notation (like i%xx/i) are // converted to specified encoding. // // @param len an integer specifying the length, //in characters, of the //codeServletInputStream/code //object that is also passed to this //method // @param in the codeServletInputStream/code //object that contains the data sent //from the client // @param enc a String specifying the
RE: Connection aborted by peer: socket write error
The client (most notably, the browser) closed the socket. Maybe the user hit the "Stop" button. Maybe the browser crashed. You can pretty much ignore this, however you must be aware that writing to servlet's output stream can result in this exception at any time (as users are free to hit "Stop" at any time during connection). Attila. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, February 26, 2001 8:57 PM To: [EMAIL PROTECTED] Subject: Connection aborted by peer: socket write error Whats causing tis error, and how can I get rid of it ? Ctx( /Phase2 ): IOException in: R( /Phase2 + /img/MapInfo.gif + null) Connection aborted by peer: socket write error Billy Ciano MapInfo Internet Engineer 1 Global View Troy,NY 12180 Main:(518)285-6000 E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Servlet Unit Testing strategies
Inside HttpUnit there is the com.meterware.servletunit package that emulates a ServletContext and lets servlets run inside it and receive WebRequests. In my understanding it allows for unit testing of servlets as per point 2). Attila. -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 2:29 PM To: [EMAIL PROTECTED] Subject: Servlet Unit Testing strategies Hi Tomcat developers, I'd like to have your opinion on servlet unit testing. I have written a simple extension to JUnit called J2EEUnit to do that but I'd like to knwo if there is a general consensus on servlet unit testing, regarding it's usefulness : Do you think : 1) It is useless. Just need to put a good facade in front of your business code and for the remaining part related to Servlets, functional tests are fine (using a tool such as HttpUnit), 2) It is nice to be able to unit test the part of the code related to servlets (i.e. the controller in a MVC model).It is possible to come up with a tool to do that (ex: J2EEUnit) 3) With the current servlet API it is not possible to come up with a framework that will let you properly do unit tests. It will have lots of shortcomings. The only solution is to extend the Servlet API by our own Servlet Test API. Then have Tomcat implement it. Once we have this, it will then be possible to create a tool/framework that make use of this Test API to unit test servlet. The next step will to promote this API so that it becomes a standard and other Servlet engine implement it. For point 3), are you aware of any project/discussion/JSR on the subject ? Thanks a lot. Vincent Massol J2EEUnit author - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
8859_1 hardcoded in one more place...
Hi! I wondered why do all of my servlets receive wrong characters in form data, and have found the answer by looking at org.apache.tomcat.util.RequestUtil.java; it delegates the work of parsing the POST-ed form data to javax.servlet.http.HttpUtils.parsePostData(), which is evil as it takes only the input stream (that is, the bytes) as input with NO ENCODING, so it blibdly assumes ISO-8859-1. Well, for large part of the world outside USA, there are charsets that differ from ISO-8859-1. Here in Hungary we're quite used to ISO-8859-2 (my personal favorite is UTF-8, however). The logic behind javax.servlet.http.HttpUtils.parsePostData() is clearly broken: a method that is supposed to deal with characters while receiving a byte stream. I think Tomcat should plainly not use it, but instead use similar code that also takes an encoding parameter (which is available to the relevant method in org.apache.tomcat.util.RequestUtil). Cheers, Attila. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
