Q: Why using introspection and reflection inside a compiled JSP?
** sorry people for reposting - i got no answer so far. maybe the e-mail got lost. can someone comment on this, please? thx! ** hi all, this might be regarded as a user question but i think this is so much internal that this is the right list to post to. if not, please excuse me. i will then repost on the users list. ok, here's what i'd like to know: looking at the java code generated from a JSP i found this: in the JSP (the details of the tag are irrelevant. the important thing is the property): my:tag foo="false" in the generated .java file: JspRuntimeLibrary.introspecthelper(_jspx_th_my_tag_0, "foo","false",null,null, false); since the type of the attribute can be determined at compile time i wonder why introspection / reflection is used inspite of the performance drawback. did i overlook something? can anyone anser this? thank you! robert -- Robert Klemme Software Engineer - myview technologies GmbH Co. KG Riemekestrae 160 ~ D-33106 Paderborn ~ Germany E-Mail: mailto:[EMAIL PROTECTED] Telefon: +49/5251/69090-321 ~ Fax: +49/5251/69090-399 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Servlet ClassLoader
| You're right about the normal delegation model for Java2. However, the Servlet | 2.3 Spec (Proposed Final Draft) gives a servlet container the option to "look | before delegating" -- see Section 9.6.2. Tomcat 4.0 does this. I've been wondering quite some time: how can this be a "option"? I find that very disturbing! Wouldn't that make tons of portability problems? The classloading isn't exactly something that's the easies thing with Java to grasp, and when things change from container to container, thing start to get really frustrating.. | The intention of this language is that you can have version X of a library | installed as a shared resource, and version Y of the library available in | WEB-INF/lib. In the 2.3 model, Y will override X. In the standard delegation | model (i.e. Tomcat 3.2) you'd get the classes from X no matter what you did. Yes, and this sounds much more sensible. Why not take away the "option" part of that section?! I know that you don't personally have the sole responsibility for that spec, but I just wondered why it is like this! I agree! This is a very intuitive approach for loading classes in webapps, and should be specified without options. I don't know the community process that well, and I don't know the exact status of 2.3, but is it too late to remove that option and make it mandatory? Reg, Gummi Haf
Re: Bugzilla and emails?
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is it possible to get Bugzilla to email open bugs to either the list or interested individuals on an automated basis? Nope, afaik, but it might be easy to do a script that queries the DB and sends appropriate emails... Any volunteer? -- Pier Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Your Bugzilla password.
To use the wonders of Bugzilla, you can use the following: E-mail address: [EMAIL PROTECTED] Password: bugzilla522 To change your password, go to: http://nagoya.apache.org/bugzilla/userprefs.cgi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: serializing XML to a ServletOutputStream fails
On Mon, Feb 05, 2001 at 11:24:55AM +0100, Zhu Ming wrote: Maybe you should not use character set "UTF-8". I remember that it's 8-bit Unicode. As I know, Chinese and Korean has 16-bit code. So at least, you should try 16-bit Unicode. I forgot the name, maybe it's "UTF-16". But I'm not sure if JDK have fully support to "UTF-16". UTF-8 is an encoding that allows the multibyte (16 and higher) Unicode code points to be encoded in 8 bits, not limited to 8 bits. If a byte has its high order bit set then you know that the next few bytes are also part of that particular code-point. So UTF-8 also handles the entire Unicode set. XML itself defaults to UTF-8 so its something that _should_ work 'out of the box'... -MM P.S. I've also posted this problem to HotDispatch so if you can help me solve the problem you could get $50... ;-) -- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: serializing XML to a ServletOutputStream fails
From: "Michael Mealling" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, February 05, 2001 7:54 PM
Subject: Re: serializing XML to a ServletOutputStream fails
P.S. I've also posted this problem to HotDispatch so if you
can help me solve the problem you could get $50... ;-)
response.setContentType("text/xml; charset=UTF-8");
Could you try following code instead of this?
response.setContentType("text/xml; charset=8859_1");
-
takashi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: serializing XML to a ServletOutputStream fails
On Mon, Feb 05, 2001 at 08:17:57PM +0900, Takashi Okamoto wrote:
From: "Michael Mealling" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, February 05, 2001 7:54 PM
Subject: Re: serializing XML to a ServletOutputStream fails
P.S. I've also posted this problem to HotDispatch so if you
can help me solve the problem you could get $50... ;-)
response.setContentType("text/xml; charset=UTF-8");
Could you try following code instead of this?
response.setContentType("text/xml; charset=8859_1");
Sure. Same thing. It appears that I get the same output
regardless of what I set the content type to...
-MM
--
Michael Mealling| Vote Libertarian! | www.rwhois.net/michael
Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821
Network Solutions | www.lp.org | [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Your Bugzilla password.
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: To use the wonders of Bugzilla, you can use the following: E-mail address: [EMAIL PROTECTED] Password: bugzilla522 To change your password, go to: http://nagoya.apache.org/bugzilla/userprefs.cgi This is cool... It was nacho disabling the account on bugzilla (I believe!) Pier -- Pier Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Your Bugzilla password.
Yep, i've tested that a user can engage sending the password to the tomcat-dev bugzilla user to the list :(, but after that the user cannot log in as is disabled :) Saludos , Ignacio J. Ortega -Mensaje original- De: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Enviado el: lunes 5 de febrero de 2001 12:52 Para: [EMAIL PROTECTED] Asunto: Re: Your Bugzilla password. [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: To use the wonders of Bugzilla, you can use the following: E-mail address: [EMAIL PROTECTED] Password: bugzilla522 To change your password, go to: http://nagoya.apache.org/bugzilla/userprefs.cgi This is cool... It was nacho disabling the account on bugzilla (I believe!) Pier -- Pier Fumagalli mailto:[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: serializing XML to a ServletOutputStream fails
I found the following implementation source code from
the tomcat 3.2 codeline, in src\org\apache\tomcat\core\ResponseImpl.java
or
http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat/src/share/org/apac
he/tomcat/core/Attic/ResponseImpl.java?rev=1.33.2.5content-type=text/vnd.vi
ewcvs-markup
/** Write a chunk of bytes. Should be called only from
ServletOutputStream implementations,
* No need to implement it if your adapter implements
ServletOutputStream.
* Headers and status will be written before this method is exceuted.
*/
public void doWrite( byte buffer[], int pos, int count) throws
IOException {
// XXX fix if charset is other than default.
if( body==null)
body=new StringBuffer();
body.append(new String(buffer, pos, count,
Constants.DEFAULT_CHAR_ENCODING) );
}
So, it looks like that tomcat 3.2 have only implemented
ServletOutputStream for default charactor set, but not
for the others.
Ming
P.S.: Thanks the Unicode lesson. :) ... It seems I have no chance
to get $50 by my poor Unicode knowledge.
-Original Message-
From: Michael Mealling [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 11:55
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: serializing XML to a ServletOutputStream fails
On Mon, Feb 05, 2001 at 11:24:55AM +0100, Zhu Ming wrote:
Maybe you should not use character set "UTF-8". I remember
that it's 8-bit Unicode. As I know, Chinese and Korean has
16-bit code. So at least, you should try 16-bit Unicode.
I forgot the name, maybe it's "UTF-16". But I'm not sure if
JDK have fully support to "UTF-16".
UTF-8 is an encoding that allows the multibyte (16 and higher)
Unicode code points to be encoded in 8 bits, not limited to 8 bits.
If a byte has its high order bit set then you know that the next
few bytes are also part of that particular code-point. So UTF-8
also handles the entire Unicode set. XML itself defaults to UTF-8
so its something that _should_ work 'out of the box'...
-MM
P.S. I've also posted this problem to HotDispatch so if you
can help me solve the problem you could get $50... ;-)
--
Michael Mealling| Vote Libertarian! | www.rwhois.net/michael
Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#:
14198821
Network Solutions | www.lp.org | [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: serializing XML to a ServletOutputStream fails
Use the PrintWriter object returned by
response.getWriter().
You will find more info at
http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/ServletResponse.html
--- Michael Mealling [EMAIL PROTECTED] wrote:
(This might be a bug so I'm cc-ing to tomcat-dev)
Hi,
I'm trying to serialize some XML out to a
ServletOutputStream but
the resulting XML on the client side contains
corrupted Unicode
characters (the DOM I'm serializing out contains
Chinese, Korean,
English, etc). Here's the code in question:
response.setContentType("text/xml;
charset=UTF-8");
ServletOutputStream out =
response.getOutputStream();
This code looks like its the right way to do this
but either
I've hit a bug or else I'm missing something (an
encoding somewhere
between a Stream and a Writer?)
__
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Tomcat 3.3 Release Plan Voting Results
Hi All, My tally of the Tomcat 3.3 Release Plan shows the release plan being approved with the following vote totals. +1 8 +08 01 -0none -1 none Thanks for the show of support. I'll be e-mailing those who voluteered earlier to work in specific areas. Together, I hope we can bring Tomcat 3.3 to a state where the vote to release Tomcat 3.3, which should occur in a couple of months, will be as positive as this one. Cheers, Larry __ Larry Isaacs [EMAIL PROTECTED] SAS Institute Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 3 Connector Default Bug Owner
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 04, 2001 7:55 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3 Connector Default Bug Owner Dan Milstein wrote: Craig (or anyone who has admin control over Bugzilla), I notice that you're set as the "default owner" for the "connectors" component for bugs within Tomcat 3. I'd like to volunteer to take that role over (for the time being, at least), but I don't know how to reset that. Can someone set this up / explain to me how to do so? Thanks Dan ... it looks like someone already got you assigned there. It does require admin rights on Bugzilla to change stuff like this (which I do have), then it's all done through online admin screens. It would probably be appropriate for someone focused on 3.x development to become default owner of the remaining components as well (Jasper, Servlet, Webapps, and Unknown) -- any volunteers? Hi Craig, As the TC 3.3 release manager, I probably should be the default owner. When you get a chance, go ahead and change this. Thanks Dan for volunteering on the connector. Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bugzilla categories
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] From: [EMAIL PROTECTED] X-Sender: costin@costin To: [EMAIL PROTECTED] Subject: Bugzilla categories X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Hi, What about another category - "Encoding" for all encoding-related bugs ? ( that would include all "special chars", charsets, etc). It's a big issue and I want to have all the related bugs grouped togheter. I think that 'i18n' would be more appropriate. Arieh ( I'll work on them - but it's not easy and will take few weeks to sort it out ) -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 3.3 Release Plan Voting Results
Hi Larry, I did not vote since I have no right to do it, but I would like to help. I am starting to use TC 3.x HEAD and getting familiar with its internals. If there are some fixes that do not demand for a wide knowledge of Tomcat (as if they just involve a couple of modules) I am willing to do that kind of work. I will also review as much code as I can (which is something that helps learning more about TC). If there are preferences about which modules should benefit more from reviews, please say so. Thanks, Paulo Gaspar -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Monday, February 05, 2001 15:37 Hi All, My tally of the Tomcat 3.3 Release Plan shows the release plan being approved with the following vote totals. +18 +08 01 -0none -1none Thanks for the show of support. I'll be e-mailing those who voluteered earlier to work in specific areas. Together, I hope we can bring Tomcat 3.3 to a state where the vote to release Tomcat 3.3, which should occur in a couple of months, will be as positive as this one. Cheers, Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 3 Connector Default Bug Owner
Done Saludos , Ignacio J. Ortega -Mensaje original- De: Larry Isaacs [mailto:[EMAIL PROTECTED]] Enviado el: lunes 5 de febrero de 2001 16:02 Para: '[EMAIL PROTECTED]' Asunto: RE: Tomcat 3 Connector Default Bug Owner -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 04, 2001 7:55 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3 Connector Default Bug Owner Dan Milstein wrote: Craig (or anyone who has admin control over Bugzilla), I notice that you're set as the "default owner" for the "connectors" component for bugs within Tomcat 3. I'd like to volunteer to take that role over (for the time being, at least), but I don't know how to reset that. Can someone set this up / explain to me how to do so? Thanks Dan ... it looks like someone already got you assigned there. It does require admin rights on Bugzilla to change stuff like this (which I do have), then it's all done through online admin screens. It would probably be appropriate for someone focused on 3.x development to become default owner of the remaining components as well (Jasper, Servlet, Webapps, and Unknown) -- any volunteers? Hi Craig, As the TC 3.3 release manager, I probably should be the default owner. When you get a chance, go ahead and change this. Thanks Dan for volunteering on the connector. Larry - 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: serializing XML to a ServletOutputStream fails
Hi Michael, I'll be working on a number of "encoding"-related problems, and support for different charsets is one of them. The problem is not easy, and it'll take few weeks - but you should have most of the issues resolved before tc3.3 beta. You can help in few ways: 1. Open a bug, with Encoding category. 2. Write a simple servlet that outputs the Unicode you want, test it with tomcat standalone. Check if it reproduce the problem and attach it to the bug. ( all test cases will be added to the sanity test, and that's a release criteria - so it'll have to be fixed :-) 3. Try outputing the unicode without the xml serializer. It may be an xml problem ( AFAIK OutputStream doesn't care about the content, and it works fine for images and any binary tesxt ). I have a strong feeling that in this case the problem is not in tomcat :-) ( well, if it is in xml I'll also have to deal with it :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: serializing XML to a ServletOutputStream fails
Maybe you should not use character set "UTF-8". I remember that it's 8-bit Unicode. As I know, Chinese and Korean has 16-bit code. So at least, you should try 16-bit Unicode. I forgot the name, maybe it's "UTF-16". But I'm not sure if JDK have fully support to "UTF-16". UTF8 is ok - it means ASCII characters are encoded with one byte, non-ASCII with more bytes. AFAIK JDK supports both UTF8 and UTF16, I'm not sure about browsers. In any case, the problem shouldn't be that. Please check a simpler case, without the xml serializer. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Working combination of apache+lservModule+tomcat? or IIS5 + tomcat?
Remeber to download ApacheModuleJServ.dll and add the following line in the tomcat.conf file LoadModule jserv_module @tomcat@/modules/ApacheModuleJServ.dll where @tomcat@/modules is the directory the above dll located or you can also download and install JServ and point to the LoadModule to the @Jserv@/ApacheModuleJServ.dll. However the trick is that you have to make a copy of the servlet.jar and name it as jsdk.jar so that the JServ can point to jsdk.jar because JServ is still trying to find the jsdk.jar released with the JSDK2.0 Good luck, David --- Charles Chen [EMAIL PROTECTED] wrote: Hi, Sorry if this is not the right list to ask such a simple question. I thought this list are read by all those tomcat experts and therefore may get this answer more quickly. I am on Win2K platform and have been struggling to get the Java web app running under apache+tomcat. It is all due to choosing the correct version of the software I guess, but it is also too difficult to find out those right versions from the web. Could someone tell me what is the working combination of apache + JservModule + tomcat? I downloaded all the latestes version (Apache 1.1.13 + tomcat 3.2.1). It did not work! I managed to get them all installed and configured. Apache was started with no complains. But I could not request any jsp or servlet services. It is a similar problem I have with the IIS 5.0 + tomcat combination. It did not work on Win2K. Only if I am willing to go back to IIS4 and some older version of tomcat might I get it working. But I would like to use the latest servlet API (at least 2.2). Any help or pointers would be appreciated. Many thanks and regards, Charles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Milstein Sent: 04 February 2001 19:18 To: [EMAIL PROTECTED] Subject: Tomcat 3 Connector Default Bug Owner Craig (or anyone who has admin control over Bugzilla), I notice that you're set as the "default owner" for the "connectors" component for bugs within Tomcat 3. I'd like to volunteer to take that role over (for the time being, at least), but I don't know how to reset that. Can someone set this up / explain to me how to do so? -Dan -- Dan Milstein // [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] __ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13Interceptor.java
hgomez 01/02/05 08:04:01
Modified:src/share/org/apache/tomcat/modules/server
Ajp13Interceptor.java
Log:
Avoid that ajp13 send 2 times END_OF_RESPONSE.
The problems occurs when using RequestDispatcher and Forward via ajp13
Revision ChangesPath
1.6 +4 -3
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java
Index: Ajp13Interceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Ajp13Interceptor.java 2000/12/26 23:35:34 1.5
+++ Ajp13Interceptor.java 2001/02/05 16:04:00 1.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java,v
1.5 2000/12/26 23:35:34 costin Exp $
- * $Revision: 1.5 $
- * $Date: 2000/12/26 23:35:34 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java,v
1.6 2001/02/05 16:04:00 hgomez Exp $
+ * $Revision: 1.6 $
+ * $Date: 2001/02/05 16:04:00 $
*
*
*
@@ -265,6 +265,7 @@
{
if(!finished) {
super.finish();
+ finished = true; // Avoid END_OF_RESPONSE sent 2 times
ajp13.finish();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Servlet ClassLoader
Gudmundur Hafsteinsson wrote: | You're right about the normal delegation model for Java2. However, the Servlet | 2.3 Spec (Proposed Final Draft) gives a servlet container the option to "look | before delegating" -- see Section 9.6.2. Tomcat 4.0 does this. I've been wondering quite some time: how can this be a "option"? I find that very disturbing! Wouldn't that make tons of portability problems? The classloading isn't exactly something that's the easies thing with Java to grasp, and when things change from container to container, thing start to get really frustrating.. | The intention of this language is that you can have version X of a library | installed as a shared resource, and version Y of the library available in | WEB-INF/lib. In the 2.3 model, Y will override X. In the standard delegation | model (i.e. Tomcat 3.2) you'd get the classes from X no matter what you did. Yes, and this sounds much more sensible. Why not take away the "option" part of that section?! I know that you don't personally have the sole responsibility for that spec, but I just wondered why it is like this! I agree! This is a very intuitive approach for loading classes in webapps, and should be specified without options. I don't know the community process that well, and I don't know the exact status of 2.3, but is it too late to remove that option and make it mandatory? Servlet 2.3 is currently in "Proposed Final Draft" status. The expert group is currently considering several clarifications and minor changes. Feedback suggesting anything else should be sent to "[EMAIL PROTECTED]". On the particular issue of class loaders, this is an area where existing container implementations differ substantially already. In fact, there is no guarantee that any particular container provides for shared JAR files at all (it is not specified behavior), so it would be difficult to impose this kind of a restriction without going to the effort to define a lot more about how shared class loaders work to ensure portability. Applications that wish to protect themselves from class loader differences need only follow two rules: * Don't use any "shared library" capability of your servlet container. * Place all the library JARs you need into WEB-INF/lib. The challenge, of course, is dealing with things that the container itself makes available in a shared manner. For Tomcat, that issue shows up with the XML parser, which is needed by Jasper to parse TLD files, as well as pages in XML syntax. One of the things we definitely need to look at is migrating the parser that Jasper uses into a separate Jasper-only classloader, so that it does not "pollute" the class loader space of web apps. Reg, Gummi Haf Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: serializing XML to a ServletOutputStream fails
Michael Mealling wrote:
On Mon, Feb 05, 2001 at 08:17:57PM +0900, Takashi Okamoto wrote:
From: "Michael Mealling" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, February 05, 2001 7:54 PM
Subject: Re: serializing XML to a ServletOutputStream fails
P.S. I've also posted this problem to HotDispatch so if you
can help me solve the problem you could get $50... ;-)
response.setContentType("text/xml; charset=UTF-8");
Could you try following code instead of this?
response.setContentType("text/xml; charset=8859_1");
Sure. Same thing. It appears that I get the same output
regardless of what I set the content type to...
That is because you are using an output stream, which is just a stream of
uninterpreted bytes from the viewpoint of the servlet container. Setting the
content type with a character encoding, as described above, will affect the Writer
that is returned by response.getWriter() -- as long as you call setContentType()
first.
-MM
Craig McClanahan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RequestDispatcher and exceptions
Hi, I'm working on few bugs related with RequestDispatcher ( well, it started with parameter handling, but RequestDispatcher is the place that have to be resolved first in order to resolve parameters - since it is doing special things with the params ). The main issue is what should happen if an exception is thrown in include() ? The current behavior is that the error handler is called, and it displays the "500 whatever" or the error page for that exception. But by reading the spec, it seems that the "correct" thing to do is to just throw the exception - include() does have a throw declaration and is documented to throw exceptions. My understanding is that "error handlers" ( as declared in server.xml or the implicit ones ) should be called only on the top-level request. ( a servlet including another one may be able to deal with the errors - if it doesn't catch them they will be thrown anyway ).. The particular test is /test/servlet/dispatch.PrintWriterTest1Servlet where it expects the error in include to be reported instead of thrown. My preference would be to fix the test and throw exceptions from include(). On the other side this changes the behavior of tomcat - and I need a second opinion. If indeed the include() is supposed to throw the exception, then it's a spec issue and the previous behavior doesn't matter. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 4 SecurityManager and Jasper ClassLoader changes
From Glenn's mail When Jasper is run in a servlet container it no longer puts the class files in a package, they are now in the default package. From the current (I think) public draft, jsp12.pdf: (emphasis mine) The JSP Page implementation object belongs to an implementation-dependent ___named___ package. The package used may even vary between one JSP and another, so minimal assumptions should be made. One implication of this is that classes in the unnamed package should not be used without an explicit "import" of the class. If I read this correctly, the classes are required to _not_ be in the default package. -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Friday, February 02, 2001 8:29 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 4 SecurityManager and Jasper ClassLoader changes In answer, here is a copy of the original message I posted. Glenn Original Message Subject: Tomcat 4 Jasper ClassLoading changes to support SecurityManager Date: Thu, 25 Jan 2001 16:46:20 -0600 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] In order to make it easier to integrate the SecurityManager into Jasper for Tomcat 4 and to change some of Japsers annoying behaviours, I have been working on switching Jasper over to the URLClassLoader. I have the class loading changes in place and Jasper passes all watchdog tests. I wanted to run these changes past everyone before I finish cleaning up the changes and committing it. (I still have some work to do on JspC and still need to add support for the SecurityManager.) Jasper now creates a URLClassLoader for each JSP page and defers any other class loading to the web app context class loader. Using a single class loader per JSP allowed me to remove all the code that increments the class version number, i.e. the work directory no longer has multiple *.java and *.class files for the same JSP page. These changes also made it easy for me to put the java source and class files in the same directory tree as found in the web app context. When Jasper is run in a servlet container it no longer puts the class files in a package, they are now in the default package. These changes simplified the code quite a bit and also gave a performance improvement. When running watchdog tests the new jasper was ~25% faster than the current jasper on a first compile or on first jsp class access after restart. On recompile of a jsp page it was 37% faster. Execution of JSP servlet after it had already been compiled and loaded was slightly faster. Regards, Glenn Mel Martinez wrote: --- Glenn Nielsen [EMAIL PROTECTED] wrote: I have completed the changes necessary to implement the Java SecurityManager in Tomcat 4. I have also completed switching Jasper over to using the URLClassLoader. Glenn, Could you describe (briefly) the nature of the change in terms of the API? I.E. Did you just reimplement JasperLoader to extend URLClassLoader or did you create a new loader class entirely? I am currently using the tc3.x jasper API by extending it (to add a variety of needed features) and am going to have to make the plunge to tc4.x eventually. Up till now I am pretty sure I've avoided any dependency that would preclude using the tc4.x version. Just staying on my toes here. Thanks, Mel __ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java
[EMAIL PROTECTED] wrote: When Jasper is run in a servlet container it no longer puts the class files in a package, they are now in the default package. As was discussed earlier on TOMCAT-DEV, this is going to cause portability problems for people who use beans that are not in packages. With this change, such beans will work in Tomcat but not when the app is moved to a different container that *does* put JSP-generated servlets into a package. The previous behavior (Jasper-generated servlets go into a package) avoided this, because it essentially disallowed non-packaged beans. Therefore, I prefer it. (Also, I seem to remember a discussion on the expert group for JSP 1.2 that non-packaged beans and generarted classes should be disallowed, but I have not yet located any reference to this in the 1.2 spec.) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: RequestDispatcher and exceptions
[EMAIL PROTECTED] wrote: Hi, I'm working on few bugs related with RequestDispatcher ( well, it started with parameter handling, but RequestDispatcher is the place that have to be resolved first in order to resolve parameters - since it is doing special things with the params ). The main issue is what should happen if an exception is thrown in include() ? The current behavior is that the error handler is called, and it displays the "500 whatever" or the error page for that exception. But by reading the spec, it seems that the "correct" thing to do is to just throw the exception - include() does have a throw declaration and is documented to throw exceptions. My understanding is that "error handlers" ( as declared in server.xml or the implicit ones ) should be called only on the top-level request. ( a servlet including another one may be able to deal with the errors - if it doesn't catch them they will be thrown anyway ).. The particular test is /test/servlet/dispatch.PrintWriterTest1Servlet where it expects the error in include to be reported instead of thrown. My preference would be to fix the test and throw exceptions from include(). On the other side this changes the behavior of tomcat - and I need a second opinion. If indeed the include() is supposed to throw the exception, then it's a spec issue and the previous behavior doesn't matter. In Tomcat 4, the following rules are applied: * If the included servlet throws ServletException or IOException, propogate it on to the calling servlet (i.e. no error page behavior). * If the included servlet throws any other exception (such as NullPointerException), wrap it in a ServletException and propogate that to the calling servlet (i.e. no error page behavior). In other words, I understood the spec the same way you did. Error pages only happen at the top-level servlet. -- Costin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java
"Craig R. McClanahan" wrote: [EMAIL PROTECTED] wrote: When Jasper is run in a servlet container it no longer puts the class files in a package, they are now in the default package. As was discussed earlier on TOMCAT-DEV, this is going to cause portability problems for people who use beans that are not in packages. With this change, such beans will work in Tomcat but not when the app is moved to a different container that *does* put JSP-generated servlets into a package. The previous behavior (Jasper-generated servlets go into a package) avoided this, because it essentially disallowed non-packaged beans. Therefore, I prefer it. (Also, I seem to remember a discussion on the expert group for JSP 1.2 that non-packaged beans and generarted classes should be disallowed, but I have not yet located any reference to this in the 1.2 spec.) If you check the code for JasperLoader you will find that it requires all classes to be in a package, the only class that does not have to be in a package is the JSP page itself. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: RequestDispatcher and exceptions
[EMAIL PROTECTED] wrote: My preference would be to fix the test and throw exceptions from include(). On the other side this changes the behavior of tomcat - and I need a second opinion. If indeed the include() is supposed to throw the exception, then it's a spec issue and the previous behavior doesn't matter. In Tomcat 4, the following rules are applied: * If the included servlet throws ServletException or IOException, propogate it on to the calling servlet (i.e. no error page behavior). * If the included servlet throws any other exception (such as NullPointerException), wrap it in a ServletException and propogate that to the calling servlet (i.e. no error page behavior). Great, I'll do something similar in tomcat3.3. My only issue is with the special treatement of RuntimeExceptions - is there a need to wrap them with ServletException ? I would treat included servlets in the same way as "normal" servlets ( from error handling perspective). Just the spec requirement (Section 8.5 for 2.3 PFD; I'm sure the 2.2 spec had a similar statement. ( I'm thinking of Security exceptions - all of them are Runtime, and the "common" behavior is to catch them if you expect them. ) In any case, this is a minor detail ( compared with the decision to throw or not). Costin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/task ApacheConfig.java
danmil 01/02/05 15:04:26
Modified:src/share/org/apache/tomcat/task Tag: tomcat_32
ApacheConfig.java
Log:
Added configuraton for NetWare.
Contributed by: Mike Anderson ([EMAIL PROTECTED])
Revision ChangesPath
No revision
No revision
1.12.2.2 +7 -0
jakarta-tomcat/src/share/org/apache/tomcat/task/Attic/ApacheConfig.java
Index: ApacheConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/task/Attic/ApacheConfig.java,v
retrieving revision 1.12.2.1
retrieving revision 1.12.2.2
diff -u -r1.12.2.1 -r1.12.2.2
--- ApacheConfig.java 2000/08/28 03:08:42 1.12.2.1
+++ ApacheConfig.java 2001/02/05 23:04:24 1.12.2.2
@@ -112,6 +112,13 @@
mod_jk.println();
mod_jk.println("JkWorkersFile \"" + new File(tomcatHome,
WORKERS_CONFIG).toString().replace('\\', '/') + "\"");
mod_jk.println("JkLogFile \"" + new File(tomcatHome,
JK_LOG_LOCATION).toString().replace('\\', '/') + "\"");
+ } else if( System.getProperty( "os.name" ).startsWith("NetWare")) {
+ // NetWare is a special case
+ pw.println("LoadModule jserv_module modules/JServ.nlm");
+ mod_jk.println("LoadModule jk_module modules/mod_jk.nlm");
+ mod_jk.println();
+ mod_jk.println("JkWorkersFile \"" + new File(tomcatHome,
WORKERS_CONFIG).toString().replace('\\', '/') + "\"");
+ mod_jk.println("JkLogFile \"" + new File(tomcatHome,
JK_LOG_LOCATION).toString().replace('\\', '/') + "\"");
} else {
// XXX XXX change it to mod_jserv_${os.name}.so, put all so in tomcat
// home
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_util.c
danmil 01/02/05 15:22:04
Modified:src/native/mod_jk/common jk_util.c
Log:
When the plugin is shutting down, the thread that the code is being run on
will likely only have a 16k stack. Since jk_log creates an 8k buffer on
the stack, there were some cases that we ran off the stack.
Contributed by: Mike Anderson ([EMAIL PROTECTED])
Revision ChangesPath
1.4 +14 -1 jakarta-tomcat/src/native/mod_jk/common/jk_util.c
Index: jk_util.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_util.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_util.c 2001/02/02 17:29:05 1.3
+++ jk_util.c 2001/02/05 23:22:04 1.4
@@ -56,7 +56,7 @@
/***
* Description: Utility functions (mainly configuration) *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.3 $ *
+ * Version: $Revision: 1.4 $ *
***/
@@ -194,7 +194,13 @@
}
if(l-level = level) {
+#ifdef NETWARE
+/* On NetWare, this can get called on a thread that has a limited stack so */
+/* we will allocate and free the temporary buffer in this function */
+char *buf;
+#else
char buf[HUGE_BUFFER_SIZE];
+#endif
char *f = (char *)(file + strlen(file) - 1);
va_list args;
int used = 0;
@@ -209,6 +215,10 @@
#ifdef WIN32
used = _snprintf(buf, HUGE_BUFFER_SIZE, "[%s (%d)]: ", f, line);
#elif defined(NETWARE) // until we get a snprintf function
+buf = (char *) malloc(HUGE_BUFFER_SIZE);
+if (NULL == buf)
+ return -1;
+
used = sprintf(buf, "[%s (%d)]: ", f, line);
#else
used = snprintf(buf, HUGE_BUFFER_SIZE, "[%s (%d)]: ", f, line);
@@ -227,6 +237,9 @@
#endif
va_end(args);
l-log(l, level, buf);
+#ifdef NETWARE
+free(buf);
+#endif
}
return rc;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/native/mod_jk/netscape jk_nsapi_plugin.c
danmil 01/02/05 15:23:17
Modified:src/native/mod_jk/netscape jk_nsapi_plugin.c
Log:
Fix a problem when submitting dating from a form with a POST request.
NetWare 5.1 doesn't have some of the assumed functionality
(netbuf_getbytes).
Submitted by: Mike Anderson ([EMAIL PROTECTED])
Revision ChangesPath
1.2 +4 -2 jakarta-tomcat/src/native/mod_jk/netscape/jk_nsapi_plugin.c
Index: jk_nsapi_plugin.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/netscape/jk_nsapi_plugin.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- jk_nsapi_plugin.c 2000/08/26 02:03:53 1.1
+++ jk_nsapi_plugin.c 2001/02/05 23:23:16 1.2
@@ -56,7 +56,7 @@
/***
* Description: NSAPI plugin for Netscape servers *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.1 $ *
+ * Version: $Revision: 1.2 $ *
***/
@@ -188,7 +188,9 @@
unsigned i;
netbuf *inbuf = p-sn-inbuf;
-#ifdef netbuf_getbytes
+/* Until we get a service pack for NW5.1 and earlier that has the latest */
+/* Enterprise Server, we have to go through the else version of this code*/
+#if defined(netbuf_getbytes) !defined(NETWARE)
i = netbuf_getbytes(inbuf, b, l);
if(NETBUF_EOF == i || NETBUF_ERROR == i) {
return JK_FALSE;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config ApacheConfig.java
danmil 01/02/05 15:29:57
Modified:src/share/org/apache/tomcat/modules/config ApacheConfig.java
Log:
Added configuraton for NetWare.
Contributed by: Mike Anderson ([EMAIL PROTECTED])
Revision ChangesPath
1.4 +7 -0
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java
Index: ApacheConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ApacheConfig.java 2001/02/02 04:26:21 1.3
+++ ApacheConfig.java 2001/02/05 23:29:56 1.4
@@ -151,6 +151,13 @@
mod_jk.println();
mod_jk.println("JkWorkersFile \"" + new File(tomcatHome,
WORKERS_CONFIG).toString().replace('\\', '/') + "\"");
mod_jk.println("JkLogFile \"" + new File(tomcatHome,
JK_LOG_LOCATION).toString().replace('\\', '/') + "\"");
+ } else if( System.getProperty( "os.name" ).startsWith("NetWare")) {
+ // NetWare is a special case
+ pw.println("LoadModule jserv_module modules/JServ.nlm");
+ mod_jk.println("LoadModule jk_module modules/mod_jk.nlm");
+ mod_jk.println();
+ mod_jk.println("JkWorkersFile \"" + new File(tomcatHome,
WORKERS_CONFIG).toString().replace('\\', '/') + "\"");
+ mod_jk.println("JkLogFile \"" + new File(tomcatHome,
JK_LOG_LOCATION).toString().replace('\\', '/') + "\"");
} else {
// XXX XXX change it to mod_jserv_${os.name}.so, put all so in tomcat
// home
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/doc tomcat-ug.html
danmil 01/02/05 15:36:50 Modified:src/doc tomcat-ug.html Log: Cleaned up HTML, fixed typos. Contributed by Chris Pepper [EMAIL PROTECTED] Revision ChangesPath 1.5 +597 -562 jakarta-tomcat/src/doc/tomcat-ug.html Index: tomcat-ug.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ug.html,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- tomcat-ug.html2000/08/25 22:13:09 1.4 +++ tomcat-ug.html2001/02/05 23:36:49 1.5 @@ -1,253 +1,290 @@ - +!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" html - head -!-- $Id: tomcat-ug.html,v 1.4 2000/08/25 22:13:09 alex Exp $ -- -!-- Copyright 1999, Apache Software Foundation -- +head +!-- $Id: tomcat-ug.html,v 1.5 2001/02/05 23:36:49 danmil Exp $ -- +!-- Copyright 1999,2001 Apache Software Foundation -- meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" link rel="stylesheet" href="style.css" titleTomcat User's Guide/title !-- Changed by: Costin Manolache, 20-Mar-2000 -- !-- Changed by: Gal Shachor, 27-Mar-2000 -- - /head - body link="#ff" vlink="#800080" -!-- Banner element, all hail the Project! -- -table border="0" width="100%" cellspacing="0" cellpadding="0" +/head + +body link="#ff" vlink="#800080" + +!-- Banner element, all hail the Project! -- + +table border="0" width="100%" cellspacing="0" cellpadding="0" tr -td width="50%" - p align="left" -a href="http://jakarta.apache.org/index.html" - img src="images/banner.gif" - width="350" - height="100" - alt="The Jakarta Project" - border="0"/a -/td -td width="50%" - p align="right"img border="0" src="images/tomcat.gif" width="100" height="71" alt="The mighty Tomcat - Meow!"/p -/td + td width="50%"a + href="http://jakarta.apache.org/index.html"img + src="images/banner.gif" width="350" height="100" + alt="The Jakarta Project" border="0"/a/td + td width="50%" align="right"img border="0" src="images/tomcat.gif" width="100" height="71" alt="The mighty Tomcat - Meow!"/td /tr -/table +/table -H1Tomcat User's Guide/H1 -pThis document is an introduction to the Tomcat servlet container. -It should be enough for anyone to install, configure, and deploy -Tomcat. As well, it answers many questions common to new users. We encourage all users to add answers to questions into the -a href="http://jakarta.apache.org/faq/faqindex.html" - Tomcat FAQ/a and/or this document, if they don't already exist. - If you have any comments or suggestions about this document don't - hesitate to send them to the Tomcat - a href="http://jakarta.apache.org/getinvolved/mail.html"mailing lists/a. - - pThis document began life as iTomcat: A Minimalistic User's - Guide/i by Gal Shachor, and has been revised by many others. - It should be considered a bwork in progress/b. Since the + +H1Tomcat User's Guide/H1 + +pThis document is an introduction to the Tomcat servlet + container. It should be enough for anyone to install, + configure, and deploy Tomcat. As well, it answers many + questions common to new users. We encourage all users to + add answers to questions into the a + href="http://jakarta.apache.org/faq/faqindex.html" + Tomcat FAQ/a and/or this document, if they don't + already exist. If you have any comments or suggestions + about this document don't hesitate to send them to the + Tomcat a + href="http://jakarta.apache.org/getinvolved/mail.html"mailing + lists/a./p + + pThis document began life as citeTomcat: A Minimalistic User's + Guide/cite by Gal Shachor, and has been revised by many others. + It should be considered a strongwork in progress/strong. Since the Tomcat source tree is constantly changing, the information herein may be out of date. The only definitive reference at this point is the a href="http://jakarta.apache.org/downloads/sourceindex.html"source code/a./p - pquot;???quot; means I'm not sure if this should go in, or where it should go or be referred to as, if it does indeed - belong. Other editorial comments are surrounded in [square brackets]. -/p + belong. Other editorial comments are surrounded in [square brackets]./p - p - Other important documents: ul -lia href="http://jakarta.apache.org/faq/faqindex.html"Tomcat
Re: RequestDispatcher and exceptions
In Tomcat 4, the following rules are applied: * If the included servlet throws ServletException or IOException, propogate it on to the calling servlet (i.e. no error page behavior). * If the included servlet throws any other exception (such as NullPointerException), wrap it in a ServletException and propogate that to the calling servlet (i.e. no error page behavior). Great, I'll do something similar in tomcat3.3. My only issue is with the special treatement of RuntimeExceptions - is there a need to wrap them with ServletException ? I would treat included servlets in the same way as "normal" servlets ( from error handling perspective). Just the spec requirement (Section 8.5 for 2.3 PFD; I'm sure the 2.2 spec had a similar statement. ??? Section 8.5 in 2.3 PFD says: "Only runtime exceptions and checked exceptions of type ServletException and IOException should be propagated ... if thrown by the target of RequestDispatcher. All other exceptions should be wrapped ... " My understanding of this is that NullPointerException should be propagated, not wrapped, same for security and any other RuntimeException. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Tomcat 4] Session Handling Enhancements
The session handling enhancements proposed by Kief Morris [EMAIL PROTECTED] have been committed on the Tomcat 4.0 CVS repository. On an initial review, I plan to make the following changes, and welcome additional thoughts and comments: (1) Session Save/Restore Across App Restarts Currently, StandardManager saves and restores sessions across app restarts (i.e. autoreload if turned on, or normal shutdown and startup). It should be modified to use the new passivate() and activate() methods of the session implementation to warn interested session attributes that this activity is taking place. (2) Modify StandardSession.readObject() and writeObject() Currently, when the session is being serialized, the attributes are removed via removeAttribute() -- which triggers calls to valueUnbound() of attributes that implement HttpSessionBindingListener, among other things. Likewise, when the session is reloaded in readObject, setAttribute() is called and triggers calls to valueBound(). These calls were initially made to give session attributes some knowledge that a restart was being done. Now that the activate and passivate mechanisms are in place, I propose that these mechanisms be changed to *not* unbind and bind the attributes during these processes. Any interested attribute can implement HttpSessionAttributeListener instead. (3) Change "final" classes One of the challenges Kief ran into is that StandardManager and StandardSession are both marked final, and therefore cannot be subclassed. I propose to remove the "final" modifier so that this restriction is no longer in place. Additional refactoring can be performed separately, but you should at least be able to subclass these classes. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: RequestDispatcher and exceptions
[EMAIL PROTECTED] wrote: In Tomcat 4, the following rules are applied: * If the included servlet throws ServletException or IOException, propogate it on to the calling servlet (i.e. no error page behavior). * If the included servlet throws any other exception (such as NullPointerException), wrap it in a ServletException and propogate that to the calling servlet (i.e. no error page behavior). Great, I'll do something similar in tomcat3.3. My only issue is with the special treatement of RuntimeExceptions - is there a need to wrap them with ServletException ? I would treat included servlets in the same way as "normal" servlets ( from error handling perspective). Just the spec requirement (Section 8.5 for 2.3 PFD; I'm sure the 2.2 spec had a similar statement. ??? Section 8.5 in 2.3 PFD says: "Only runtime exceptions and checked exceptions of type ServletException and IOException should be propagated ... if thrown by the target of RequestDispatcher. All other exceptions should be wrapped ... " My understanding of this is that NullPointerException should be propagated, not wrapped, same for security and any other RuntimeException. Mea culpa. Costin's interpretation is correct (I was too focused on the "checked exceptions" part of the statement quoted above), and Tomcat 4 is currently broken in this respect. That will get changed tonight. Costin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: RequestDispatcher and exceptions
Section 8.5 in 2.3 PFD says: "Only runtime exceptions and checked exceptions of type ServletException and IOException should be propagated ... if thrown by the target of RequestDispatcher. All other exceptions should be wrapped ... " My understanding of this is that NullPointerException should be propagated, not wrapped, same for security and any other RuntimeException. Yes - and the same requirement is in the 2.2 version as well - that exceptions inheriting from RuntimeException should be popped up to the caller. - Danny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa JDBCRealm.java
nacho 01/02/05 18:05:46
Modified:src/share/org/apache/tomcat/modules/aaa JDBCRealm.java
Log:
Bugzilla #307 #407
Authentication failes using the JDBCRealm with Sybase ASE 11.9.2
for Linux BugRat Report#560
reported by: [EMAIL PROTECTED] (Allan Schweitz)
JDBCRealm: Call trim() on names and roles read
out of database BugRat Report#707
reported by [EMAIL PROTECTED] (Adam Rabung)
Revision ChangesPath
1.3 +44 -37
jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/JDBCRealm.java
Index: JDBCRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/JDBCRealm.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JDBCRealm.java2001/02/04 22:08:24 1.2
+++ JDBCRealm.java2001/02/06 02:05:46 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/JDBCRealm.java,v 1.2
2001/02/04 22:08:24 nacho Exp $
- * $Revision: 1.2 $
- * $Date: 2001/02/04 22:08:24 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/JDBCRealm.java,v 1.3
2001/02/06 02:05:46 nacho Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/02/06 02:05:46 $
*
* The Apache Software License, Version 1.1
*
@@ -76,8 +76,13 @@
/**
* Implmentation of bRealm/b that works with any JDBC supported database.
- * See the JDBCRealm.howto for more details on how to set up the database and for
configuration options. TODO:
- * - Work on authentication with non-plaintext passwords
+ * See the JDBCRealm.howto for more details on how to set up the database and
+ * for configuration options.
+ *
+ *
+ * TODO: - Work on authentication with non-plaintext passwords
+ *
+ *
* @author Craig R. McClanahan
* @author Carson McDonald
* @author Ignacio J. Ortega
@@ -210,44 +215,48 @@
/**
* Set the column in the user role table that names a role
* @param roleNameCol The column name
- */
+ */
public void setRoleNameCol(String roleNameCol) {
this.roleNameCol = roleNameCol;
}
/**
* Gets the digest algorithm used for credentials in the database
- * could be the same that MessageDigest accepts vor algorithm and "No" that is
the Default
- * @return
- */
+ * could be the same that MessageDigest accepts vor algorithm and "No" that
+ * is the Default
+ * @return
+ */
public String getDigest() {
return digest;
}
/**
* Sets the digest algorithm used for credentials in the database
- * could be the same that MessageDigest accepts vor algorithm and "No" that is
the Default
+ * could be the same that MessageDigest accepts vor algorithm and "No"
+ * that is the Default
* @param algorithm the Encode type
- */
+ */
public void setDigest(String algorithm) {
digest = algorithm;
}
-
-/**
- * When connectOnInit is setted to "true" the JDBC connection is started at tomcat
init
- * if false the connection is started in the first times is needed.
- * @param s "true" or "false"
- */
-public void setConnectOnInit(String s) {
-connectOnInit = Boolean.valueOf(s).booleanValue();
+
+/**
+ * When connectOnInit is true the JDBC connection is started at tomcat init
+ * if false the connection is started the first times it is needed.
+ * @param b
+ */
+public void setConnectOnInit(boolean b) {
+connectOnInit = b;
}
/**
* If there are any errors with the JDBC connection, executing
- * the query or anything we return false (don't authenticate). This event is
also logged.
+ * the query or anything we return false (don't authenticate). This event
+ * is also logged.
* If there is some SQL exception the connection is set to null.
* This will allow a retry on the next auth attempt. This might not
- * be the best thing to do but it will keep tomcat from needing a restart if
the database goes down.
+ * be the best thing to do but it will keep tomcat from needing a restart
+ * if the database goes down.
*
* @param username Username of the Principal to look up
* @param credentials Password or other credentials to use in authenticating
this username
@@ -322,7 +331,8 @@
(connectionPassword == null || connectionPassword.equals(""))) {
dbConnection = DriverManager.getConnection(connectionURL);
} else {
-dbConnection = DriverManager.getConnection(connectionURL,
connectionName, connectionPassword);
+dbConnection = DriverManager.getConnection(connectionURL,
+
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm JDBCRealm.java
nacho 01/02/05 18:11:08
Modified:catalina/src/share/org/apache/catalina/realm JDBCRealm.java
Log:
Bugzilla Bugs #307 #407
*Authentication failes using the JDBCRealm with Sybase ASE 11.9.2
for Linux BugRat Report#560
reported by: [EMAIL PROTECTED] (Allan Schweitz)
*JDBCRealm: Call trim() on names and roles read
out of database BugRat Report#707
reported by [EMAIL PROTECTED] (Adam Rabung)
Revision ChangesPath
1.9 +3 -3
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java
Index: JDBCRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JDBCRealm.java2000/12/31 16:30:35 1.8
+++ JDBCRealm.java2001/02/06 02:11:08 1.9
@@ -396,13 +396,13 @@
boolean found = false;
if (rs1.next()) {
if( digest.equals("") || digest.equalsIgnoreCase("No")){
-if(credentials.equals(rs1.getString(1))) {
+if(credentials.equals(rs1.getString(1).trim())) {
if(debug = 2)
log(sm.getString("jdbcRealm.authenticateSuccess",
username));
found = true;
}else if (credentials.equals(
-Digest(rs1.getString(1),digest))) {
+Digest(rs1.getString(1).trim(),digest))) {
if (debug = 2)
log(sm.getString("jdbcRealm.authenticateSuccess",
username));
@@ -424,7 +424,7 @@
preparedRoles.setString(1, username);
ResultSet rs2 = preparedRoles.executeQuery();
while (rs2.next()) {
- principal.addRole(rs2.getString(1));
+ principal.addRole(rs2.getString(1).trim());
}
rs2.close();
return (principal);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
[Bug 532] Changed - JDBCRealm auth fails using interbase interclient
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=532 *** shadow/532 Mon Feb 5 16:44:41 2001 --- shadow/532.tmp.14727Mon Feb 5 18:20:17 2001 *** *** 2,15 | JDBCRealm auth fails using interbase interclient | ++ |Bug #: 532 Product: Tomcat 3| ! | Status: NEW Version: 3.2.1 Final | ! | Resolution:Platform: PC | ! | Severity: MajorOS/Version: | | Priority: MediumComponent: Auth| ++ | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED] | - | CC list: Cc: | ++ | URL: | ++ --- 2,14 | JDBCRealm auth fails using interbase interclient | ++ |Bug #: 532 Product: Tomcat 3| ! | Status: RESOLVEDVersion: 3.2.1 Final | ! | Resolution: FIXED Platform: PC | ! | Severity: MajorOS/Version: All | | Priority: MediumComponent: Auth| ++ | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED] | ++ | URL: | ++ *** *** 25,28 the database with a null parameter. The code I'm referring to is circa line 306 in ! apache/tomcat/request/JDBCRealm.java --- 24,31 the database with a null parameter. The code I'm referring to is circa line 306 in ! apache/tomcat/request/JDBCRealm.java ! ! --- Additional Comments From [EMAIL PROTECTED] 2001-02-05 18:20 --- ! Fixed in Tomcat 3.2.2 ! Fixed in Tomcat 3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/shell startup2.bat tomcat2.bat
nacho 01/02/05 18:46:31
Modified:.build.xml
src/facade22/org/apache/tomcat/facade JspInterceptor.java
src/share/org/apache/jasper/compiler JasperMangler.java
src/share/org/apache/tomcat/modules/config
LoaderInterceptor11.java
src/share/org/apache/tomcat/startup Main.java Tomcat.java
src/share/org/apache/tomcat/util/compat Jdk11Compat.java
Jdk12Support.java
Added: src/shell startup2.bat tomcat2.bat
Log:
This commit is intented to let Tomcat33
to use a classloader for internal classes
isolating tomcat internal classes on
his own classloader and with a common
repository with only servlet.jar in it ...
* Start a webapp in a true isolated sandbox shielded from any jar needed to run
Tomcat itself i.e no more xml parser coocon blues :)
* Be able to mix isolated ( aka trusted ) and non isolated apps in the same server.
Sorry to send only bats i dont know sh at all..
but they only start Tomcat with only a jar in classpath tomcat.jar,
basicly it contains classes needed for bootstraping tomcat and can be used on jdk11
systems too.
build the new dir layout doing "build new",
and using "startup2.bat" to start it,
then you can try i.e use crimson for tomcat
and xerces for Cocoon without put xerces in
the server classpath.
Revision ChangesPath
1.107 +30 -0 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.106
retrieving revision 1.107
diff -u -r1.106 -r1.107
--- build.xml 2001/01/25 05:07:32 1.106
+++ build.xml 2001/02/06 02:46:24 1.107
@@ -78,6 +78,8 @@
file="${ant.home}/lib/parser.jar"/
copy tofile="${tomcat.build}/lib/jaxp.jar" file="${jaxp}/jaxp.jar"/
copy tofile="${tomcat.build}/lib/parser.jar" file="${jaxp}/parser.jar"/
+copy tofile="${tomcat.build}/lib/jaxp.jar" file="${jaxp}/jaxp.jar"/
+copy tofile="${tomcat.build}/lib/crimson.jar" file="${jaxp}/crimson.jar"/
!-- This act as a "default", Tomcat3.3 will not load it in
classpath, just a hack to ease the transition
@@ -401,6 +403,33 @@
zip zipfile="${Name}-${version}.zip" basedir="${tomcat.dist}" includes="**"/
/target
+ target name="dist-new" depends="dist"
+mkdir dir="${tomcat.dist}/lib/shared"/
+mkdir dir="${tomcat.dist}/lib/common"/
+copy file ="${tomcat.dist}/lib/servlet.jar"
+todir="${tomcat.dist}/lib/common" /
+copy file ="${tomcat.dist}/lib/jasper.jar"
+todir="${tomcat.dist}/lib/shared" /
+copy file ="${tomcat.dist}/lib/tomcat_util.jar"
+todir="${tomcat.dist}/lib/shared" /
+ /target
+
+ target name="new" depends="main"
+mkdir dir="${tomcat.build}/lib/shared"/
+mkdir dir="${tomcat.build}/lib/common"/
+copy file ="${tomcat.build}/lib/servlet.jar"
+todir="${tomcat.build}/lib/common" /
+copy file ="${tomcat.build}/lib/jasper.jar"
+todir="${tomcat.build}/lib/shared" /
+copy file ="${tomcat.build}/lib/tomcat_util.jar"
+todir="${tomcat.build}/lib/shared" /
+!--
+delete
+fileset dir="${tomcat.build}/classes"/
+/delete
+--
+ /target
+
!-- Admin agreagate --
@@ -417,6 +446,7 @@
delete dir="${tomcat.build}"/
delete dir="${tomcat.dist}"/
/target
+
target name="all" depends="clean,dist"/
target name="main" depends="tomcat,webapps,sanity-test"/
1.12 +23 -7
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java
Index: JspInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JspInterceptor.java 2001/02/01 04:44:57 1.11
+++ JspInterceptor.java 2001/02/06 02:46:25 1.12
@@ -51,7 +51,7 @@
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
- */
+ */
package org.apache.tomcat.facade;
import javax.servlet.*;
@@ -67,6 +67,7 @@
import org.apache.tomcat.util.log.*;
import org.apache.tomcat.util.*;
import org.apache.tomcat.util.depend.*;
+import org.apache.tomcat.util.compat.*;
import org.apache.jasper.*;
import org.apache.jasper.Constants;
@@ -594,6 +595,7 @@
javac.setEncoding(javaEncoding);
String cp=System.getProperty("java.class.path")+ sep +
ctxt.getClassPath() + sep + ctxt.getOutputDir();
+//System.out.println("classpath:"+cp);
javac.setClasspath( cp );
RE: cvs commit: jakarta-tomcat/src/shell startup2.bat tomcat2.bat
This commit is intented to let Tomcat33 to use a classloader for internal classes isolating tomcat internal classes on his own classloader and with a common Nice demonstration of my capability to write songs in swahili, :)) Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Bug 532] Changed - JDBCRealm auth fails using interbase interclient
How do I unsubscribe this.It has become so painful.I have tried thru the address given at the bottom ,and no use. Please suggest me what to do. Thanks, Arvind _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/shell tomcat.sh
costin 01/02/05 20:44:53
Modified:src/shell tomcat.sh
Log:
Shell changes to match Nacho's bat file.
The new behavior is enabled by default, comment out the first line
if you want to go back.
( after a transition period I'll remove the old code from the startup
script - it'll be much simpler and cleaner )
Revision ChangesPath
1.20 +22 -7 jakarta-tomcat/src/shell/tomcat.sh
Index: tomcat.sh
===
RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.sh,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- tomcat.sh 2000/08/15 14:25:06 1.19
+++ tomcat.sh 2001/02/06 04:44:53 1.20
@@ -1,6 +1,6 @@
#!/bin/sh
#
-# $Id: tomcat.sh,v 1.19 2000/08/15 14:25:06 glenn Exp $
+# $Id: tomcat.sh,v 1.20 2001/02/06 04:44:53 costin Exp $
# Shell script to start and stop the server
@@ -12,6 +12,9 @@
#jre -cp runner.jar:servlet.jar:classes org.apache.tomcat.shell.Startup $*
#java -cp runner.jar:servlet.jar:classes org.apache.tomcat.shell.Startup $*
+NEW_LOADER=1
+export NEW_LOADER
+
if [ -f $HOME/.tomcatrc ] ; then
. $HOME/.tomcatrc
fi
@@ -91,6 +94,15 @@
oldCP=$CLASSPATH
unset CLASSPATH
+
+if [ "$NEW_LOADER" = "1" ]; then
+ MAIN=org.apache.tomcat.startup.Main
+ export MAIN
+ CLASSPATH=${TOMCAT_HOME}/lib/tomcat.jar
+else
+ MAIN=org.apache.tomcat.startup.Tomcat
+
+## Temp - old script
for i in ${TOMCAT_HOME}/lib/* ; do
if [ "$CLASSPATH" != "" ]; then
CLASSPATH=${CLASSPATH}:$i
@@ -114,6 +126,9 @@
CLASSPATH=${CLASSPATH}:${oldCP}
fi
+# End - NEW_LOADER
+fi
+
export CLASSPATH
# We start the server up in the background for a couple of reasons:
@@ -126,9 +141,9 @@
echo Using TOMCAT_HOME: ${TOMCAT_HOME}
if [ "$1" = "-security" ] ; then
echo Starting with a SecurityManager
-$JAVACMD $TOMCAT_OPTS -Djava.security.manager
-Djava.security.policy==${TOMCAT_HOME}/conf/tomcat.policy -Dtomcat.home=${TOMCAT_HOME}
org.apache.tomcat.startup.Tomcat "$@"
+$JAVACMD $TOMCAT_OPTS -Djava.security.manager
-Djava.security.policy==${TOMCAT_HOME}/conf/tomcat.policy -Dtomcat.home=${TOMCAT_HOME}
$MAIN "$@"
else
- $JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME}
org.apache.tomcat.startup.Tomcat "$@"
+ $JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN "$@"
fi
# $JAVACMD org.apache.tomcat.shell.Startup "$@"
@@ -137,8 +152,8 @@
echo Using classpath: ${CLASSPATH}
echo Using JAVA_HOME: ${JAVA_HOME}
echo Using TOMCAT_HOME: ${TOMCAT_HOME}
- $JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME}
org.apache.tomcat.startup.Tomcat -stop "$@"
-# $JAVACMD org.apache.tomcat.shell.Shutdown "$@"
+ CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/stop-tomcat.jar
+ $JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME}
org.apache.tomcat.startup.StopTomcat "$@"
elif [ "$1" = "run" ] ; then
shift
@@ -147,9 +162,9 @@
echo Using TOMCAT_HOME: ${TOMCAT_HOME}
if [ "$1" = "-security" ] ; then
echo Starting with a SecurityManager
-$JAVACMD $TOMCAT_OPTS -Djava.security.manager
-Djava.security.policy==${TOMCAT_HOME}/conf/tomcat.policy -Dtomcat.home=${TOMCAT_HOME}
org.apache.tomcat.startup.Tomcat "$@"
+$JAVACMD $TOMCAT_OPTS -Djava.security.manager
-Djava.security.policy==${TOMCAT_HOME}/conf/tomcat.policy -Dtomcat.home=${TOMCAT_HOME}
$MAIN "$@"
else
- $JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME}
org.apache.tomcat.startup.Tomcat "$@"
+ $JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN "$@"
fi
# $JAVACMD org.apache.tomcat.shell.Startup "$@"
# no
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: serializing XML to a ServletOutputStream fails
UTF-16 is not an acceptable encoding for XML as it takes two bytes per
character, is byte order sensitive, and the XML tags would not be
recognized...
UTF-8 is the correct encoding! Any 31 bit character in the ISO10646
specification can be correctly represented in UTF-8. UNICODE is the first
65768 characters of ISO10646.
A CKJ character code point value of 0x6123 is represented in UTF-8 as three
bytes E6 84 A3.
What byte values are you seeing for the encoding of a given Chinese code
point?
- Original Message -
From: Zhu Ming [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, February 05, 2001 4:24 AM
Subject: RE: serializing XML to a ServletOutputStream fails
Hi,
Maybe you should not use character set "UTF-8". I remember
that it's 8-bit Unicode. As I know, Chinese and Korean has
16-bit code. So at least, you should try 16-bit Unicode.
I forgot the name, maybe it's "UTF-16". But I'm not sure if
JDK have fully support to "UTF-16".
I'm not an Unicode expert. I'll be happy if what I say can
be a hint to solve this problem.
Ming
-Original Message-
From: Michael Mealling [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 03:04
To: [EMAIL PROTECTED]
Subject: serializing XML to a ServletOutputStream fails
(This might be a bug so I'm cc-ing to tomcat-dev)
Hi,
I'm trying to serialize some XML out to a ServletOutputStream but
the resulting XML on the client side contains corrupted Unicode
characters (the DOM I'm serializing out contains Chinese, Korean,
English, etc). Here's the code in question:
response.setContentType("text/xml; charset=UTF-8");
ServletOutputStream out = response.getOutputStream();
out.print("?xml version=\"1.0\" encoding=\"UTF-8\"?\n" +
"!DOCTYPE cnrp PUBLIC \"-//IETF//DTD CNRP 1.0//EN\"" +
" \"http://www.ietf.org/cnrp.dtd\"\n");
out.flush();
OutputFormat format = new OutputFormat(document);
format.setOmitXMLDeclaration(true);
format.setIndenting(true); // it makes debuggin easier
format.setEncoding("UTF-8"); // this is the default anyway
XMLSerializer serializer = new XMLSerializer(out, format);
serializer.serialize(document.getDocumentElement());
The XML that the client gets is fine except that the non-ASCII subset
of the UTF-8 encoded Unicode characters are garbled. I can serialize
the XML out to a FileOutputStream and it works just fine.
I'm running Tomcat 3.2.1 that's the backend for a remote
Apache 1.3.17 server using ajp13 (and thus mod_jk).
This code looks like its the right way to do this but either
I've hit a bug or else I'm missing something (an encoding somewhere
between a Stream and a Writer?)
-MM
--
--
--
Michael Mealling | Vote Libertarian! | www.rwhois.net/michael
Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#:
14198821
Network Solutions | www.lp.org | [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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/http Parameters.java
costin 01/02/05 22:24:27
Modified:src/share/org/apache/tomcat/util/http Parameters.java
Log:
All parameter handling code is now part of Parameters.
The internal representation of parameters is now encapsulated,
no external class can access the internal details.
This is still the old code and representation ( hashatble of
name- value[] ), but a the processing has been improved and now follows the
rules defined in the spec for merging GET/POST params and merging
RequestDispatcher queries.
It'll also simplify RequestDispatcher a lot by removing all the hacky
code to support parameter saving/restoring.
( this started as a fix for JspInterceptor to deal with jsp_precompile,
but it's better to do a real fix instead of a simple hack. )
Revision ChangesPath
1.7 +285 -174
jakarta-tomcat/src/share/org/apache/tomcat/util/http/Parameters.java
Index: Parameters.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/http/Parameters.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Parameters.java 2001/01/01 00:17:24 1.6
+++ Parameters.java 2001/02/06 06:24:26 1.7
@@ -70,11 +70,29 @@
* @author Costin Manolache
*/
public final class Parameters extends MultiMap {
+// Transition: we'll use the same Hashtable( String-String[] )
+// for the beginning. When we are sure all accesses happen through
+// this class - we can switch to MultiMap
+private Hashtable paramHashStringArray=new Hashtable();
+private boolean didQueryParameters=false;
+private boolean didReadFormData=false;
+private boolean didMerge=false;
+
+MessageBytes queryMB;
+MimeHeaders headers;
+
public static final int INITIAL_SIZE=4;
-private boolean isSet=false;
-private boolean isFormBased=false;
-
+// Garbage-less parameter merging.
+// In a sub-request with parameters, the new parameters
+// will be stored in child. When a getParameter happens,
+// the 2 are merged togheter. The child will be altered
+// to contain the merged values - the parent is allways the
+// original request.
+private Parameters child=null;
+private Parameters parent=null;
+private Parameters currentChild=null;
+
/**
*
*/
@@ -82,30 +100,282 @@
super( INITIAL_SIZE );
}
+public void setQuery( MessageBytes queryMB ) {
+ this.queryMB=queryMB;
+}
+
+public void setHeaders( MimeHeaders headers ) {
+ this.headers=headers;
+}
+
public void recycle() {
super.recycle();
- isSet=false;
- isFormBased=false;
+ paramHashStringArray.clear();
+ didQueryParameters=false;
+ didReadFormData=false;
+ currentChild=null;
+ didMerge=false;
}
+
+// Sub-request support
-/**
+public Parameters getCurrentSet() {
+ if( currentChild==null )
+ return this;
+ return currentChild;
+}
+
+/** Create ( or reuse ) a child that will be used during a sub-request.
+ All future changes ( setting query string, adding parameters )
+ will affect the child ( the parent request is never changed ).
+ Both setters and getters will return the data from the deepest
+ child, merged with data from parents.
+*/
+public void push() {
+ // We maintain a linked list, that will grow to the size of the
+ // longest include chain.
+ // The list has 2 points of interest:
+ // - request.parameters() is the original request and head,
+ // - request.parameters().currentChild() is the current set.
+ // The -child and parent- links are preserved ( currentChild is not
+ // the last in the list )
+
+ // create a new element in the linked list
+ // note that we reuse the child, if any - pop will not
+ // set child to null !
+ if( currentChild.child==null ) {
+ currentChild.child=new Parameters();
+ currentChild.child.parent=currentChild;
+ } // it is not null if this object already had a child
+ // i.e. a deeper include() ( we keep it )
+
+ // the head will be the new element.
+ currentChild=currentChild.child;
+}
+
+/** Discard the last child. This happens when we return from a
+ sub-request and the parameters are locally modified.
*/
-public boolean isEvaluated() {
- return isSet;
+public void pop() {
+ if( currentChild==null ) {
+ throw new RuntimeException( "Attempt to pop without a push" );
+ }
+ currentChild.recycle();
+ currentChild=currentChild.parent;
+ // don't remove the top.
+
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Request.java
costin 01/02/05 22:29:19
Modified:src/share/org/apache/tomcat/core Request.java
Log:
Corresponding changes in Request - the parameter representation and handling
is now encapsulated in Parameters.
The Request and RequestDispatcher will create and manipulate Parameters,
by adding data ( handlePostParameters() is a special case that will
"feed" all the post body to Parameters ). Parameters are not dealing with
reading data or anything similar - just store and manipulate params.
Revision ChangesPath
1.88 +30 -57jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java
Index: Request.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v
retrieving revision 1.87
retrieving revision 1.88
diff -u -r1.87 -r1.88
--- Request.java 2001/01/14 20:23:04 1.87
+++ Request.java 2001/02/06 06:29:19 1.88
@@ -135,9 +135,9 @@
protected MimeHeaders headers;
// Processed information ( redundant ! )
-protected Hashtable parameters = new Hashtable();
+protected Parameters params=new Parameters();
+//protected Hashtable parametersH = new Hashtable();
protected boolean didReadFormData;
-protected boolean didParameters;
protected int contentLength = -1;
protected String contentType = null;
@@ -192,6 +192,8 @@
public Request() {
headers = new MimeHeaders();
scookies = new Cookies( headers );
+ params.setQuery( queryMB );
+ params.setHeaders( headers );
initRequest();
}
@@ -319,26 +321,31 @@
// Parameters
-
-// XXX optimize for common case ( single params )
-public String getParameter(String name ) {
- String[] values = getParameterValues(name);
-if (values != null) {
-return values[0];
-} else {
- return null;
-}
-}
-public String[] getParameterValues(String name) {
- handleParameters();
-return (String[])parameters.get(name);
+/** Read the body, if POST, and add the post parameters.
+ * Before this method is called, only query-line parameters
+ * are available.
+ */
+public void handlePostParameters() {
+ int needData=params.needContent();
+
+ if( needData 0 ) {
+ try {
+ byte[] formData = new byte[needData];
+ readBody( formData, needData );
+ params.processData( formData );
+ } catch(IOException ex ) {
+ // XXX should we throw exception or log ?
+ return;
+ }
+ }
}
-public Enumeration getParameterNames() {
- handleParameters();
-return parameters.keys();
+public Parameters parameters() {
+ return params;
}
+
+
// encoding/type
@@ -598,15 +605,6 @@
this.container=container;
}
-public void setParameters( Hashtable h ) {
- if(h!=null)
- this.parameters=h;
-}
-
-public Hashtable getParameters() {
- return parameters;
-}
-
// Attributes
public Object getAttribute(String name) {
@@ -693,35 +691,10 @@
}
// Utils - facade for RequestUtil
-private void handleParameters() {
- if(!didParameters) {
- String qString=queryString().toString();
- if(qString!=null) {
- didParameters=true;
- Parameters.processFormData( qString, parameters );
- }
- }
- if (!didReadFormData) {
- didReadFormData = true;
- int len=Parameters.formContentLength( getContentType(),
- getContentLength());
- if( len 0 ) {
- // based on HttpUtils, very ,very slow and bad
- byte[] formData = new byte [contentLength];
- try {
- readBody( formData, contentLength );
- } catch(IOException ex ) {
- return;
- }
- Hashtable postParameters=Parameters.processFormData(formData);
- parameters = Parameters.mergeParameters(parameters,
- postParameters);
- }
- }
-}
-
-private int readBody(byte body[], int len)
+/** Read request data, filling a byte[]
+ */
+public int readBody(byte body[], int len)
throws IOException
{
int offset = 0;
@@ -810,7 +783,8 @@
public void initRequest() {
context = null;
attributes.clear();
-
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa AccessInterceptor.java
costin 01/02/05 22:30:58
Modified:src/share/org/apache/tomcat/modules/aaa
AccessInterceptor.java
Log:
Use Parameters in AccessInterceptor.
Revision ChangesPath
1.5 +9 -2
jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/AccessInterceptor.java
Index: AccessInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/aaa/AccessInterceptor.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- AccessInterceptor.java2001/01/29 07:08:45 1.4
+++ AccessInterceptor.java2001/02/06 06:30:58 1.5
@@ -61,6 +61,7 @@
import org.apache.tomcat.core.*;
import org.apache.tomcat.util.*;
+import org.apache.tomcat.util.http.*;
import java.util.*;
import java.io.*;
@@ -511,8 +512,14 @@
public void doService(Request req, Response res)
throws Exception
{
- String username=req.getParameter( "j_username" );
- String password=req.getParameter( "j_password" );
+ // In order to process the form we need to read the POST
+ // body, if any
+ req.handlePostParameters();
+
+ Parameters params=req.parameters();
+
+ String username=params.getParameter( "j_username" );
+ String password=params.getParameter( "j_password" );
Context ctx=req.getContext();
String errorPage=ctx.getFormErrorPage();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpServletRequestFacade.java JspInterceptor.java
costin 01/02/05 22:33:35
Modified:src/facade22/org/apache/tomcat/facade
HttpServletRequestFacade.java JspInterceptor.java
Log:
ServletRequestFacade will now use Parameters. It'll also implement the
API requirements about when and how the POST parameters are read.
JspInterceptor will now deal with jsp_precompile.
Revision ChangesPath
1.17 +27 -3
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletRequestFacade.java
Index: HttpServletRequestFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletRequestFacade.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- HttpServletRequestFacade.java 2001/01/01 00:17:22 1.16
+++ HttpServletRequestFacade.java 2001/02/06 06:33:35 1.17
@@ -94,6 +94,8 @@
private boolean usingStream = false;
private boolean usingReader = false;
+private boolean parametersProcessed=false;
+
/** Not public
*/
HttpServletRequestFacade(Request request) {
@@ -106,6 +108,7 @@
void recycle() {
usingReader=false;
usingStream=false;
+ parametersProcessed=false;
if( sessionFacade!=null) sessionFacade.recycle();
if( isFacade != null ) isFacade.recycle();
isFacadeInitialized=false;
@@ -230,15 +233,36 @@
/** Adapter: Request doesn't deal with this servlet convention
*/
public String getParameter(String name) {
-return request.getParameter( name );
+ if( ! parametersProcessed ) {
+ request.parameters().handleQueryParameters();
+ if( request.method().equals("POST")) {
+ request.handlePostParameters();
+ }
+ parametersProcessed=true;
+ }
+return request.parameters().getParameter( name );
}
public String[] getParameterValues(String name) {
-return request.getParameterValues(name);
+ if( ! parametersProcessed ) {
+ request.parameters().handleQueryParameters();
+ if( request.method().equals("POST")) {
+ request.handlePostParameters();
+ }
+ parametersProcessed=true;
+ }
+return request.parameters().getParameterValues(name);
}
public Enumeration getParameterNames() {
-return request.getParameterNames();
+ if( ! parametersProcessed ) {
+ request.parameters().handleQueryParameters();
+ if( request.method().equals("POST")) {
+ request.handlePostParameters();
+ }
+ parametersProcessed=true;
+ }
+return request.parameters().getParameterNames();
}
public String getPathInfo() {
1.13 +62 -0
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java
Index: JspInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/JspInterceptor.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JspInterceptor.java 2001/02/06 02:46:25 1.12
+++ JspInterceptor.java 2001/02/06 06:33:35 1.13
@@ -279,6 +279,8 @@
}
jspServlet.setServletClassName(jspServletCN);
+ } else {
+ ctx.addServlet( new JspPrecompileH());
}
}
@@ -373,6 +375,26 @@
return 0; // not a jsp
}
+ // if it's a jsp_precompile request, don't execute - just
+ // compile ( if needed ). Since we'll compile the jsp on
+ // the first request the only special thing is to not
+ // execute the jsp if jsp_precompile param is in parameters.
+ String qString=req.queryString().toString();
+ // look for ?jsp_precompile or jsp_precompile
+
+ // quick test to see if we need to worry about params
+ // ( preserve lazy eval for parameters )
+ boolean pre_compile=false;
+ int i=(qString==null) ? -1: qString.indexOf( "jsp_precompile" );
+ if( i= 0 ) {
+ // Probably we are in the problem case.
+ req.parameters().handleQueryParameters();
+ String p=req.parameters().getParameter( "jsp_precompile");
+ if( p==null || p.equalsIgnoreCase("true")) {
+ pre_compile=true;
+ }
+ }
+
// Each .jsp file is compiled to a servlet, and will
// have a dependency to check if it's expired
Dependency dep= handler.getServletInfo().getDependency();
@@ -386,6 +408,18 @@
// we need to compile... ( or find previous .class )
JasperLiaison liasion=new JasperLiaison(getLog(), debug);
liasion.processJspFile(req, jspFile, handler, args);
+
+
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade RequestDispatcherImpl.java
costin 01/02/05 22:35:56
Modified:src/facade22/org/apache/tomcat/facade
RequestDispatcherImpl.java
Log:
A bigger change in RequestDispatcherImpl:
- the parameter manipulation ( by using access to the internal representation)
is removed
- Parameters is used to provide merging query parameter and restoring the
old parameters ( same mechanism as before - a stack, but no garbage is
generated in the common case ).
This also includes few changes needed to deal with the exceptions as
requested by the spec.
Revision ChangesPath
1.15 +156 -229
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/RequestDispatcherImpl.java
Index: RequestDispatcherImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/RequestDispatcherImpl.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- RequestDispatcherImpl.java2001/01/28 19:45:52 1.14
+++ RequestDispatcherImpl.java2001/02/06 06:35:55 1.15
@@ -63,6 +63,7 @@
import org.apache.tomcat.core.*;
import org.apache.tomcat.util.StringManager;
import org.apache.tomcat.util.compat.*;
+import org.apache.tomcat.util.http.*;
import java.io.*;
import java.util.*;
import java.security.*;
@@ -100,11 +101,26 @@
* @author [EMAIL PROTECTED]
*/
final class RequestDispatcherImpl implements RequestDispatcher {
+static final boolean debug=true;
// Use the strings from core
private static StringManager sm = StringManager.
getManager("org.apache.tomcat.resources");
+
+// Attributes that will be replaced during include
+private static final String A_REQUEST_URI=
+ "javax.servlet.include.request_uri";
+private static final String A_CONTEXT_PATH=
+ "javax.servlet.include.context_path";
+private static final String A_SERVLET_PATH=
+ "javax.servlet.include.servlet_path";
+private static final String A_PATH_INFO=
+ "javax.servlet.include.path_info";
+private static final String A_QUERY_STRING=
+ "javax.servlet.include.query_string";
+
Context context;
+
// path dispatchers
String path;
String queryString;
@@ -136,6 +152,8 @@
}
// Public methods
+
+// Wrappers for jdk1.2 priviledged actions
Jdk11Compat jdk11Compat=Jdk11Compat.getJdkCompat();
RDIAction forwardAction=new RDIAction( this,false);
RDIAction includeAction=new RDIAction( this,true);
@@ -144,36 +162,34 @@
throws ServletException, IOException
{
if( System.getSecurityManager() != null ) {
-// final ServletRequest req = request;
-// final ServletResponse res = response;
try {
forwardAction.prepare( request, response );
jdk11Compat.doPrivileged( forwardAction );
-
-// java.security.AccessController.doPrivileged(
-// new java.security.PrivilegedExceptionAction()
-// {
-// public Object run() throws ServletException, IOException {
-// doForward(req,res);
-// return null;
-// }
-// }
-// );
-// } catch( PrivilegedActionException pe) {
-// Exception e = pe.getException();
} catch( Exception e) {
- if( e instanceof ServletException )
- throw (ServletException)e;
- if( e instanceof RuntimeException )
- throw (RuntimeException)e;
- // can only be IOException
- throw (IOException)e;
+ wrapException( e, null );
}
} else {
doForward(request,response);
}
}
+public void include(ServletRequest request, ServletResponse response)
+ throws ServletException, IOException
+{
+ if( System.getSecurityManager() != null ) {
+ try {
+ includeAction.prepare( request, response );
+ jdk11Compat.doPrivileged( includeAction );
+ } catch( Exception e) {
+ wrapException( e, null );
+ }
+ } else {
+ doInclude(request,response);
+ }
+}
+
+// Actual forward/include impl
+
private void doForward(ServletRequest request, ServletResponse response)
throws ServletException, IOException
{
@@ -211,8 +227,12 @@
// merge query string as specified in specs - before, it may affect
// the way the request is handled by special interceptors
- if( queryString != null )
- addQueryString( realRequest, queryString );
+
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade ServletHandler.java
costin 01/02/05 22:36:25
Modified:src/facade22/org/apache/tomcat/facade ServletHandler.java
Log:
Coresponding changes in ServletHandler - the exceptions are propagated
from included servlets ( instead of wrapping them )
Revision ChangesPath
1.13 +11 -4
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletHandler.java
Index: ServletHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletHandler.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ServletHandler.java 2001/01/20 23:25:44 1.12
+++ ServletHandler.java 2001/02/06 06:36:25 1.13
@@ -427,7 +427,9 @@
}
// Overrides the default handler
-public void service ( Request req, Response res ) {
+public void service ( Request req, Response res )
+ throws Exception
+{
if( state!=STATE_READY ) {
if( state!= STATE_DISABLED ) {
init();
@@ -497,8 +499,8 @@
} else {
servlet.service(reqF, resF);
}
- // catch just UnavailableException, so we can set a timer if needed
- // other exceptions will be thrown
+ // catch just UnavailableException, so we can set a timer if needed
+ // other exceptions will be thrown
} catch ( UnavailableException ex ) {
// if new exception, save and set timer if necessary
if ( res.getErrorException() != ex ) {
@@ -524,6 +526,7 @@
handleServiceError( req, res, ex );
return;
}
+
// clear any error exception since none were thrown
res.setErrorException(null);
res.setErrorURI(null);
@@ -566,9 +569,13 @@
}
protected void handleServiceError( Request req, Response res, Throwable t )
+ throws Exception
{
// if in included, defer handling to higher level
- if (res.isIncluded()) return;
+ if (res.isIncluded()) {
+ throw (Exception)t;
+ }
+ // only for top-level servlets
handleError( req, res, t );
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core BaseInterceptor.java Container.java
costin 01/02/05 22:40:07
Modified:src/share/org/apache/tomcat/core BaseInterceptor.java
Container.java
Log:
A small change in Container/BaseInterceptor regarding module add.
The "registerHooks" needs access to the ContextManager and Context ( for
local interceptors ) to do anything usefull.
( the method was added last year to allow modules full control over how
they are added to the server, including ordering. It is not used so far,
but if we run into ordering problems with the modules that will be the
solution. )
Revision ChangesPath
1.41 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java
Index: BaseInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- BaseInterceptor.java 2001/02/03 05:43:18 1.40
+++ BaseInterceptor.java 2001/02/06 06:40:06 1.41
@@ -587,7 +587,7 @@
* Most modules are added to the Hooks automatically. A module
* overriding this method has full control over this process.
*/
-public int registerHooks(Hooks h) {
+public int registerHooks(Hooks h, ContextManager cm, Context ctx) {
return DECLINED;
}
1.46 +1 -1 jakarta-tomcat/src/share/org/apache/tomcat/core/Container.java
Index: Container.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Container.java,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- Container.java2001/02/01 04:47:12 1.45
+++ Container.java2001/02/06 06:40:06 1.46
@@ -422,7 +422,7 @@
bi.setContext( getContext() );
if( Hooks.hasHook( bi, "registerHooks" ) ) {
- bi.registerHooks( hooks );
+ bi.registerHooks( hooks, contextM, context );
} else {
hooks.addModule( bi );
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Context.java ContextManager.java
costin 01/02/05 22:41:08
Modified:src/share/org/apache/tomcat/core Context.java
ContextManager.java
Log:
Estetic change in the way Contexts are displayed: use host:/path
instead of Ctx ( )
Revision ChangesPath
1.138 +2 -2 jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java
Index: Context.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java,v
retrieving revision 1.137
retrieving revision 1.138
diff -u -r1.137 -r1.138
--- Context.java 2001/02/03 07:34:41 1.137
+++ Context.java 2001/02/06 06:41:07 1.138
@@ -1033,8 +1033,8 @@
}
public final String toString() {
- return "Ctx( " + (vhost==null ? "" :
- vhost + ":" ) + path + ")";
+ return (vhost==null ? "DEFAULT:" : vhost + ":" ) +
+("".equals(path) ? "/ROOT" : path);
}
// --- Logging ---
1.166 +1 -2
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.165
retrieving revision 1.166
diff -u -r1.165 -r1.166
--- ContextManager.java 2001/02/03 05:43:18 1.165
+++ ContextManager.java 2001/02/06 06:41:07 1.166
@@ -512,7 +512,7 @@
existingI[i].addContext( this, ctx );
}
ctx.setState( Context.STATE_ADDED );
- log("Adding context " + ctx.toString());
+ log("Adding " + ctx.toString());
} catch( TomcatException ex ) {
log( "Error adding context " + ctx , ex );
continue;
@@ -927,7 +927,6 @@
BaseInterceptor ri[];
int status;
ri=req.getContainer().getInterceptors( Container.H_handleError );
-
for( int i=0; i ri.length; i++ ) {
status=ri[i].handleError( req, res, t );
if( status!=0 ) return;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config AutoWebApp.java
costin 01/02/05 22:42:01
Modified:src/share/org/apache/tomcat/modules/config AutoWebApp.java
Log:
Better (and fewer) messages in AutoWebApp.
Revision ChangesPath
1.3 +4 -2
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoWebApp.java
Index: AutoWebApp.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoWebApp.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AutoWebApp.java 2001/02/02 22:38:30 1.2
+++ AutoWebApp.java 2001/02/06 06:42:01 1.3
@@ -204,15 +204,17 @@
if(host==null) host="DEFAULT";
String path="/" + unEscapePath( name );
- log("Auto-Adding " + name + " " + host + " " + path );
if( path.equals("/ROOT") )
path="";
Hashtable loaded=(Hashtable)hosts.get(host);
if( loaded != null loaded.get( path ) != null ) {
- log( "Already loaded");
+ log( "Already loaded: " + host + ":" +
+ ( "".equals(path) ? "/" : path ) );
return; // already loaded
}
+ log("Auto-Adding " + host + ":" +
+ ( "".equals(path) ? "/" : path ) );
if (dir.isDirectory()) {
Context ctx=new Context();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config LogSetter.java
costin 01/02/05 22:42:28
Modified:src/share/org/apache/tomcat/modules/config LogSetter.java
Log:
Added the missing options for removing and configuring timestamps.
Revision ChangesPath
1.6 +21 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LogSetter.java
Index: LogSetter.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LogSetter.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- LogSetter.java2001/02/03 07:34:41 1.5
+++ LogSetter.java2001/02/06 06:42:28 1.6
@@ -140,6 +140,8 @@
String path;
String verbosityLevel;
boolean servletLogger=false;
+boolean timestamps=true;
+String tsFormat=null;
public LogSetter() {
}
@@ -165,6 +167,20 @@
public void setServletLogger( boolean b ) {
servletLogger=b;
}
+
+/** Display the time of the event ( log ).
+ */
+public void setTimestamps( boolean b ) {
+ timestamps=b;
+}
+
+/** Set the format of the timestamp.
+ "msec" will display the raw time ( fastest ),
+ otherwise a SimpleDateFormat.
+*/
+public void setTimestampFormat( String s ) {
+ tsFormat=s;
+}
/**
* The log will be added and opened as soon as the module is
@@ -205,7 +221,11 @@
// construct a queue logger
QueueLogger ql=new QueueLogger();
ql.setName(name);
-
+ if( ! timestamps )
+ ql.setTimestamp( "false" );
+ if( tsFormat!=null )
+ ql.setTimestampFormat( tsFormat );
+
if( path!=null )
ql.setPath(path);
if( verbosityLevel!= null )
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config PathSetter.java
costin 01/02/05 22:43:59
Modified:src/share/org/apache/tomcat/modules/config PathSetter.java
Log:
Better messages in pathsetter.
home will be displayed, but installDir only if different, also
simpler message.
Revision ChangesPath
1.4 +7 -4
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/PathSetter.java
Index: PathSetter.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/PathSetter.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- PathSetter.java 2001/02/03 05:22:19 1.3
+++ PathSetter.java 2001/02/06 06:43:59 1.4
@@ -126,13 +126,11 @@
// Make it absolute
home=FileUtil.getCanonicalPath( home );
cm.setHome( home );
- log( "engineInit: home= " + home );
String installDir=cm.getInstallDir();
if( installDir!= null ) {
installDir=FileUtil.getCanonicalPath( installDir );
cm.setInstallDir( installDir );
- log( "engineInit: install= " + installDir );
}
// if only one is set home==installDir
@@ -179,8 +177,13 @@
}
cm.setWorkDir( workDir );
- if(debug1) log( "Setting: " + cm.getInstallDir() + " " +
- cm.getHome() + " " + workDir);
+ if( debug0 ||
+ ! cm.getHome().equals( cm.getInstallDir() ) ) {
+ log( "install=" + cm.getInstallDir());
+ }
+ log( "home=" + cm.getHome());
+ if( debug0)
+ log( " work=" + workDir);
}
/** Adjust paths for a context - make the base and all loggers
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config ServerXmlReader.java
costin 01/02/05 22:45:05
Modified:src/share/org/apache/tomcat/modules/config
ServerXmlReader.java
Log:
Fewer messages in ServerXmlReader.
If server.xml is read from TOMCAT_HOME, don't display the long path again.
Revision ChangesPath
1.4 +5 -3
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ServerXmlReader.java
Index: ServerXmlReader.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ServerXmlReader.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ServerXmlReader.java 2001/02/04 22:24:16 1.3
+++ ServerXmlReader.java 2001/02/06 06:45:05 1.4
@@ -131,13 +131,17 @@
if( f.exists() ){
cm.setNote( "configFile", f.getAbsolutePath());
loadConfigFile(xh,f,cm);
+ String s=f.getAbsolutePath();
+ if( s.startsWith( cm.getHome()))
+ s="$TOMCAT_HOME" + s.substring( cm.getHome().length());
+ log( "Config=" + s);
// load server-*.xml
/*Vector v = getUserConfigFiles(f);
for (Enumeration e = v.elements();
e.hasMoreElements() ; ) {
f = (File)e.nextElement();
loadConfigFile(xh,f,cm);
-
+ cm.log(sm.getString("tomcat.loading") + " " + f);
}
*/
}
@@ -148,14 +152,12 @@
public static void loadConfigFile(XmlMapper xh, File f, ContextManager cm)
throws TomcatException
{
- cm.log(sm.getString("tomcat.loading") + " " + f);
try {
xh.readXml(f,cm);
} catch( Exception ex ) {
cm.log( sm.getString("tomcat.fatalconfigerror"), ex );
throw new TomcatException(ex);
}
- cm.log(sm.getString("tomcat.loaded") + " " + f);
}
public static void setTagRules( XmlMapper xh ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config WorkDirSetup.java
costin 01/02/05 22:45:30
Modified:src/share/org/apache/tomcat/modules/config WorkDirSetup.java
Log:
Removed duplicated code ( it is also part of PathSetter )
Revision ChangesPath
1.4 +0 -22
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/WorkDirSetup.java
Index: WorkDirSetup.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/WorkDirSetup.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- WorkDirSetup.java 2000/12/29 19:53:53 1.3
+++ WorkDirSetup.java 2001/02/06 06:45:30 1.4
@@ -115,28 +115,6 @@
// Callbacks
-/** Adjust context manager paths
- */
-public void engineInit( ContextManager cm )
- throws TomcatException
-{
- initWorkDir(cm);
-}
-
-private void initWorkDir(ContextManager cm) {
- String workDir=cm.getWorkDir();
- if( workDir==null ) {
- workDir= DEFAULT_WORK_DIR;
- }
-
- if( ! FileUtil.isAbsolute( workDir )) {
- workDir=FileUtil.
- getCanonicalPath(cm.getHome() + File.separator+
- workDir);
- }
- cm.setWorkDir( workDir );
-}
-
public void addContext(ContextManager cm, Context ctx) {
// not explicitely configured
if( ctx.getWorkDir() == null)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators ErrorHandler.java
costin 01/02/05 22:46:29
Modified:src/share/org/apache/tomcat/modules/generators
ErrorHandler.java
Log:
Fixes for the error handling. More debugging ( maybe we'll need it again )
Revision ChangesPath
1.6 +24 -13
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java
Index: ErrorHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ErrorHandler.java 2001/01/31 01:56:46 1.5
+++ ErrorHandler.java 2001/02/06 06:46:29 1.6
@@ -86,16 +86,9 @@
showDebugInfo=b;
}
-public void engineInit( ContextManager cm )
- throws TomcatException
-{
+public void engineInit(ContextManager cm ) {
}
-public void addContext( ContextManager cm, Context ctx)
- throws TomcatException
-{
-}
-
/** Add default error handlers
*/
public void contextInit( Context ctx)
@@ -131,6 +124,8 @@
ctx.addErrorPage( "301", "tomcat.redirectHandler");
ctx.addServlet( new NotFoundHandler(this, showDebugInfo));
ctx.addErrorPage( "404", "tomcat.notFoundHandler");
+
+ if( debug 0 ) log( "Init " + ctx + " " + showDebugInfo);
}
public int handleError( Request req, Response res, Throwable t ) {
@@ -143,6 +138,7 @@
ctx=rootContext;
}
+ if( debug 0 ) log( "In error handler " +t );
if( t==null ) {
handleStatusImpl( cm, ctx, req, res, res.getStatus() );
} else {
@@ -207,8 +203,13 @@
// reset error exception
res.setErrorException( null );
- errorServlet.service( req, res );
- Exception ex=res.getErrorException();
+ Exception ex=null;
+ try {
+ errorServlet.service( req, res );
+ ex=res.getErrorException();
+ } catch (Exception ex1 ) {
+ ex=ex1;
+ }
if( ex!=null ! (ex instanceof IOException) ) {
// we can ignore IOException - probably the user
// has clicked "STOP"
@@ -229,6 +230,9 @@
void handleErrorImpl( ContextManager cm, Context ctx,
Request req, Response res , Throwable t )
{
+ if( debug0 )
+ log( "Handle error in " + req + " " + t.getMessage() );
+
/** The exception must be available to the user.
Note that it is _WRONG_ to send the trace back to
the client. AFAIK the trace is the _best_ debugger.
@@ -283,11 +287,13 @@
boolean isDefaultHandler = false;
if ( errorLoop( ctx, req ) ){
-return;
+ log( "Error loop for " + req + " error " + t);
+ return;
}
if ( errorServlet==null) {
errorServlet = ctx.getServletByName("tomcat.exceptionHandler");
isDefaultHandler = true;
+ if( debug0 ) ctx.log( "Using default handler " + errorServlet );
}
if (errorServlet == null) {
@@ -315,8 +321,13 @@
// reset error exception
res.setErrorException( null );
- errorServlet.service( req, res );
- Exception ex=res.getErrorException();
+ Exception ex=null;
+ try {
+ errorServlet.service( req, res );
+ ex=res.getErrorException();
+ } catch(Exception ex1 ) {
+ ex=ex1;
+ }
if( ex!=null ! (ex instanceof IOException) ) {
// we can ignore IOException - probably the user
// has clicked "STOP"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers LogEvents.java
costin 01/02/05 22:47:38
Modified:src/share/org/apache/tomcat/modules/loggers LogEvents.java
Log:
First use of registerHooks: LogEvents will add itself to the
server only if debug5 on ContextManager.
( LogEvents is very usefull in seeing what happens inside the server,
I recommend you use it for debugging )
Revision ChangesPath
1.2 +17 -0
jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers/LogEvents.java
Index: LogEvents.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers/LogEvents.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- LogEvents.java2001/01/01 01:58:38 1.1
+++ LogEvents.java2001/02/06 06:47:38 1.2
@@ -61,6 +61,7 @@
import org.apache.tomcat.core.*;
import org.apache.tomcat.util.*;
+import org.apache.tomcat.util.hooks.*;
import java.io.*;
import java.net.*;
import java.util.*;
@@ -70,10 +71,25 @@
* output )
*/
public class LogEvents extends BaseInterceptor {
+boolean enabled=false;
public LogEvents() {
}
+public void setEnabled( boolean b ) {
+ enabled=b;
+}
+
+public int registerHooks( Hooks hooks, ContextManager cm, Context ctx ) {
+ if( enabled || cm.getDebug() 5 ) {
+ enabled=true;
+ log( "Adding LogEvents, cm.debug=" + cm.getDebug() + " "
+ + enabled);
+ hooks.addModule( this );
+ }
+ return DECLINED;
+}
+
// Request notifications
public int requestMap(Request request ) {
log( "requestMap " + request);
@@ -209,6 +225,7 @@
BaseInterceptor i )
throws TomcatException
{
+ if( ! enabled ) return;
if( ctx==null)
log( "addInterceptor " + i );
else {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util CharChunk.java
costin 01/02/05 22:48:36
Modified:src/share/org/apache/tomcat/util CharChunk.java
Log:
Removing debug message.
Revision ChangesPath
1.6 +1 -1 jakarta-tomcat/src/share/org/apache/tomcat/util/CharChunk.java
Index: CharChunk.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/CharChunk.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- CharChunk.java2001/01/29 07:08:57 1.5
+++ CharChunk.java2001/02/06 06:48:36 1.6
@@ -369,7 +369,7 @@
public final static String unescapeURL(String str)
{
// old code
- System.out.println("XXX old unescape URL "+ str);
+ //System.out.println("XXX old unescape URL "+ str);
if (str == null) return null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/test HttpClient.java
costin 01/02/05 22:48:54
Modified:src/share/org/apache/tomcat/util/test HttpClient.java
Log:
Removing debug message.
Revision ChangesPath
1.5 +0 -2
jakarta-tomcat/src/share/org/apache/tomcat/util/test/HttpClient.java
Index: HttpClient.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/test/HttpClient.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- HttpClient.java 2001/01/28 19:53:11 1.4
+++ HttpClient.java 2001/02/06 06:48:53 1.5
@@ -131,14 +131,12 @@
/** The port used to send the request
*/
public void setPort(String portS) {
- System.out.println("HttpClient.setPort " + portS + " " + port);
this.port=Integer.valueOf( portS).intValue();
}
/** Set the port as int - different name to avoid confusing introspection
*/
public void setPortInt(int i) {
- System.out.println("HttpClient.setPort " + i + " " + port );
this.port=i;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/tests/webpages/params - New directory
costin 01/02/05 22:49:32 jakarta-tomcat/src/tests/webpages/params - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF/classes/params - New directory
costin 01/02/05 22:51:17 jakarta-tomcat/src/tests/webpages/WEB-INF/classes/params - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/tests/webpages/params isParams.jsp params.jsp paramsIS.jsp
costin 01/02/05 22:53:33
Added: src/tests/webpages/WEB-INF/classes/params
InputStreamParams.java Params.java
ParamsInputStream.java
src/tests/webpages/params isParams.jsp params.jsp
paramsIS.jsp
Log:
Starting to add test cases for params.
More to come - we need to test RD + params ( ordering, multiple levels,
etc ), what happen with the body ( it is processed only on getParameter ),
both for jsp and servlets.
Also, what happens with invalid query strings, what happens with
POST with query string ( query should take precedence ).
The encoding tests will be added later, when the encoding issues will be
treated.
Revision ChangesPath
1.1
jakarta-tomcat/src/tests/webpages/WEB-INF/classes/params/InputStreamParams.java
Index: InputStreamParams.java
===
package request;
import java.io.*;
import java.text.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
/**
*
*/
public class InputStreamParams extends HttpServlet {
public void service(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/plain");
PrintWriter out = response.getWriter();
InputStream in=request.getInputStream();
out.println("START BODY: " );
int c;
while( (c=in.read()) = 0 ) {
out.write( (char)c );
}
out.println();
out.println("END BODY");
// Now get parameters - only query should be available :-)
Enumeration paramN=request.getParameterNames();
while( paramN.hasMoreElements() ) {
String name=(String)paramN.nextElement();
String all[]=request.getParameterValues(name);
out.print(name);
out.print(" = [ " );
for( int i=0; iall.length; i++ ) {
if( i0 ) out.print( " , ");
out.print( all[i] );
}
out.println( " ]");
}
out.println(request.getQueryString());
}
}
1.1
jakarta-tomcat/src/tests/webpages/WEB-INF/classes/params/Params.java
Index: Params.java
===
package request;
import java.io.*;
import java.text.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
/**
*
*/
public class Params extends HttpServlet {
public void service(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/plain");
PrintWriter out = response.getWriter();
out.println("Request parameters: " );
Enumeration paramN=request.getParameterNames();
while( paramN.hasMoreElements() ) {
String name=(String)paramN.nextElement();
String all[]=request.getParameterValues(name);
out.print(name);
out.print(" = [ " );
for( int i=0; iall.length; i++ ) {
if( i0 ) out.print( " , ");
out.print( all[i] );
}
out.println( " ]");
}
out.println(request.getQueryString());
}
}
1.1
jakarta-tomcat/src/tests/webpages/WEB-INF/classes/params/ParamsInputStream.java
Index: ParamsInputStream.java
===
package request;
import java.io.*;
import java.text.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
/**
*
*/
public class ParamsInputStream extends HttpServlet {
public void service(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
PrintWriter out = response.getWriter();
response.setContentType("text/plain");
Enumeration paramN=request.getParameterNames();
while( paramN.hasMoreElements() ) {
String name=(String)paramN.nextElement();
String all[]=request.getParameterValues(name);
out.print(name);
out.print(" = [ " );
for( int i=0; iall.length; i++ ) {
if( i0 ) out.print( " , ");
out.print( all[i] );
}
out.println( " ]");
}
out.println("QueryString= " + request.getQueryString());
InputStream in=request.getInputStream();
out.println("START BODY: " );
int c;
while( (c=in.read()) = 0 )
