Lost with sources in CVS
Hi, Ok, I'm a newbie in the Tomcat development area, but not in java or CVS, and I don't understand anything of what's it like in Tomcat. I downloaded the whole thing and ran the ant build. And now I find the same java sources in what the hell is this locations, js152, j152, catalina, build or whatever. I find sources in directory path's without the proper package, usually tests, Clock2 applets or contributions. I will probably be my lesser understanding, but I have no idea how to work in these sources. Which is the real source, will it be overwritten after an update and build (because I suspect the build directory is written out each time) ? Could anyone for instance tell me where I have to work in sources if I want to make a change in the servlet response (I just want that and I will do it, no discussion please..) I may be blunt, but TMHO the source and developmant environment is a mess ... Sorry I have to say this KR, Hans
Lost with sources in CVS
Hi Yoav It that so ? Well ,for instance, this is what I *find*: server:/usr/src/tomcat/5-5-4# find . -name HttpServletResponse.java gives me: ./build/servlet-api-2.4/src/javax/servlet/http/HttpServletResponse.java ./jakarta-servletapi-5/jsr154/src/share/javax/servlet/http/HttpServletResponse.java ./jakarta-servletapi-5/jsr154/dist/src/javax/servlet/http/HttpServletResponse.java OK, which of the 3 ? If I find implementing *Response classes there is quite a list .. server:/usr/src/tomcat/5-5-4# find . -name *Response.java ./build/servlet-api-2.4/src/javax/servlet/http/HttpServletResponse.java ./build/servlet-api-2.4/src/javax/servlet/ServletResponse.java ./jakarta-servletapi-5/jsr154/src/share/javax/servlet/http/HttpServletResponse.java ./jakarta-servletapi-5/jsr154/src/share/javax/servlet/ServletResponse.java ./jakarta-servletapi-5/jsr154/dist/src/javax/servlet/http/HttpServletResponse.java ./jakarta-servletapi-5/jsr154/dist/src/javax/servlet/ServletResponse.java ./jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationResponse.java ./jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java ./jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/DummyResponse.java ./jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Response.java ./jakarta-tomcat-catalina/tester/src/tester/org/apache/tester/UpperCaseResponse.java ./jakarta-tomcat-catalina/tester/src/tester/org/apache/tester/CharArrayResponse.java ./jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Response.java ./jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Response.java ./jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java ./jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java ./jakarta-tomcat-connectors/webapp/java/org/apache/catalina/connector/warp/WarpResponse.java KR, Hans - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 9:55 PM Subject: RE: Lost with sources in CVS Hi, That's OK, don't feel bad asking questions ;) And don't feel bad when people say you're clueless if you say it's a mess ;) For Tomcat 5, Tomcat's source is divided into several CVS modules. These are jakarta-tomcat-5, jakarta-tomcat-catalina, jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-servletapi-5. The last one in the previous list contains the Servlet API classes, so if you want to change the HttpServletResponse interface, that's where you would start. The build script does checkouts as needed, both for Tomcat's own source (the above CVS modules) and dependencies as listed in the build.properties.default file. The checkouts don't use the CVS -C switch, so they won't override any changes you've made. As to your build directory question, you should try it instead of ranting. You'll find the build script fairly intelligent in not removing your changes. Of course, if you run the clean Ant target, the directory will be cleaned out. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Hans Verschoor [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 3:41 PM To: [EMAIL PROTECTED] Subject: Lost with sources in CVS Hi, Ok, I'm a newbie in the Tomcat development area, but not in java or CVS, and I don't understand anything of what's it like in Tomcat. I downloaded the whole thing and ran the ant build. And now I find the same java sources in what the hell is this locations, js152, j152, catalina, build or whatever. I find sources in directory path's without the proper package, usually tests, Clock2 applets or contributions. I will probably be my lesser understanding, but I have no idea how to work in these sources. Which is the real source, will it be overwritten after an update and build (because I suspect the build directory is written out each time) ? Could anyone for instance tell me where I have to work in sources if I want to make a change in the servlet response (I just want that and I will do it, no discussion please..) I may be blunt, but TMHO the source and developmant environment is a mess ... Sorry I have to say this KR, Hans
HTTP headers and end of response, reposted for better reading
Hi all, (repost for better reading) I am working at an inplementation of RFC2671 Digest Authentication. I want to do the authentication in my servlet application because I need additional data with the userid and password. For reasons of session management and security I should be able to send an Authentication-Info header in my response. This is the commonly accepted implementation scheme: If the login fails a 401 is sent thus: new login, when the login is ok an Authentication-Info header is send together with the normal 200 OK response. So what, You can set headers in the HttpServletResponse would one say, but here's a problem: RFC2617 literally states: The Authentication-Info header is allowed in the trailer of an HTTP message transferred via chunked transfer encoding. Some browsers (MSIE and Mozilla) have taken this as: '... is ONLY allowed ...'. I had a discussion with Paul Leach from Microsoft, one of the co-authors of RFC2617, and he pointed out that the reason for it was that with a given quality of protection (auth-int) the content of the message is part of the calculation to check wether the Authentication-Info header is valid and for that reason (huh?) the Authentication-Info header has to follow the message content block (funny enough MSIE and Mozilla do not support this option, only Opera does). However, the placement of HTTP headers at the end of a response is currently not supported in Tomcat. This all brings me in a stalemate position: IE and Mozilla are the most widely used browsers by far but will only accept the Authentication-Info header at the end but Tomcat does not support this. This leaves only the standard options for digest athentication: a fairly simple check against userid:password pairs, which is not acceptable for me ( no user categories, only atomic userid's, database replications needed, no addtional data allowed when checking login, less detection of tampering, no password change polices, no invisible digest changes, session management by cookies, etc). I realize that the implementation of trailing headers means implications for the Servlet API, something like: HttpServletResponse.setHeader(String name, String value, boolean atEnd). So I had the idea to prefix the header name with a + sign to indicate that the header should follow the content and that chunked encoding should be in place. I had a look at the Response source code, but until now it was not very clear to me how to implement the trick. To conclude, of course my preferred suggestion would be: append a boolean argument to the setHeader methods of the HttpServletResponse interface, not to the addHeader of course and add a method: isHeaderAtEnd (String name) to detect wether the header is before or after the content. This suggestions should be followed by all servlet engine implementors. The + sign prepending trick would not have implications for the Servlet API. When looking at the Tomcat source I cannot oversee what sources would be affected, especially those involved in connectors. Now that was a long story, who can help me ? KR, Hans
HTTP headers and end of response
Hi all, I am working at an inplementation of RFC2671 Digest Authentication. I want to do the authentication in my servlet application because I need additional data with the userid and password. For reasons of session management and security I should be able to send an Authentication-Info header in my response. This is the commonly accepted implementation: If the login fails a 401 is sent thus: new login, when the login is ok an Authentication-Info header is send together with the normal 200 OK response. So what, You can set headers in the HttpServletResponse would one say, but here's a problem: RFC2617 literally states: The Authentication-Info header is allowed in the trailer of an HTTP message transferred via chunked transfer encoding. Some browsers (MSIE and Mozilla) have taken this as: '... is ONLY allowed ...'. I had a discussion with Paul Leach from Microsoft, one of the co-authors of RFC2617, and he pointed out that the reason for it was that with a given quality of protection (auth-int) the content of the message is part of the calculation to check wether the Authentication-Info header is valid and for that reason (huh?) the Authentication-Info header has to follow the message content block (funny enough MSIE and Mozilla do not support this option, only Opera does). However, the placement of HTTP headers at the end of a response is currently not supported in Tomcat. This all brings me in a stalemate position: IE and Mozilla are the most used browsers by far but will only accept the Authentication-Info header at the end but Tomcat does not support this. This leaves only the standard options for digest athentication: a fairly simple check against userid:password pairs, which is not acceptable for me ( no user categories, only atomic userid's, database replications needed, no addtional data allowed when checking login, less detection of tampering, no password change polices, no invisible digest changes, session management by cookies, etc). I realize that the implementation of trailing headers means implications for the Servlet API, something like: HttpServletResponse.setHeader(String name, String value, boolean atEnd). So I had the idea to prefix the header name with a + sign to indicate that the header should follow the content and that chunked encoding should be in place. I had a look at the Response source code, but until now it was not very clear to me how to implement the trick. To conclude, of course my preferred suggestion would be: append a boolean argument to the setHeader methods of the HttpServletResponse interface, not to the addHeader of course and add a method: isHeaderAtEnd (String name) to detect wether the header is before or after the content. This suggestions should be followed by all servlet engine implementors. The + sign prepending trick would not have implications for the Servlet API. When looking at the Tomcat source I cannot oversee what sources would be affected, especially those involved in connectors. Now that was a long story, who can help me ? KR, Hans
Re: Losing line numbers in stracktraces
Thx, Dave ! It works. I did put debug=true in my ant javac task and recompiled the whole thing. Do you think debuglevel=lines would work also ? Regads, Hans - Original Message - From: David Rees [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 2:36 AM Subject: Re: Losing line numbers in stracktraces Hans Verschoor wrote: I have a problem reading stacktrace info when Tomcat throws an exception caused by a servlet or a class calld by a servlet I have my classes compiled into in the . WEB-INF/classes directory and (so far) I use no war or jar. When an exception is thrown the stacktrace does not show line numbers but Unknown source, which is not so handy. The classes are compiled correctly, in other circumstances the line numbers DO appear in stacktraces using the same classes. I am a relative newbie, so my questions are: 1. Do I need to configure the webapploader explicitly ? 2. Do I need some switch on de java statement when starting tomcat ? Make sure you compile your classes with the -g flag to javac. Otherwise, line numbers will be optimized out. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Losing line numbers in stracktraces
Hello I have a problem reading stacktrace info when Tomcat throws an exception caused by a servlet or a class calld by a servlet I have my classes compiled into in the . WEB-INF/classes directory and (so far) I use no war or jar. When an exception is thrown the stacktrace does not show line numbers but Unknown source, which is not so handy. The classes are compiled correctly, in other circumstances the line numbers DO appear in stacktraces using the same classes. I am a relative newbie, so my questions are: 1. Do I need to configure the webapploader explicitly ? 2. Do I need some switch on de java statement when starting tomcat ? Kind regards, Hans
