Re: Tomcat 5.0.28 release
I'm sorry, but can't remember - why do we still need the endorsed ? I tought they were a temporary solution for JDK1.4 and some validation problems - tomcat should work fine with any SAX/DOM parser, including the one in JDK1.4. The only problem is JDK1.3 - and I agree that it would be better to just provide a patch for 1.3 ( or ask the user to install a parser in jre/ext or classpath, to get the same behavior as in 1.4 ). Or even better - in Bootstrap check if we're in 1.3 and add the parser to the classpath, otherwise use whatever is in jdk ( and maybe turn validation of if the version of jdk and parser is not the right one ). In any case - modularizing the distribution would be really good. Having a core JDK1.5 distro, and additional packages to add JDK1.4 and JDK1.3 support is good. It would also be good to distribute more components as optional plug-ins. Again - I missed a lot of discussions, probably most of this has been discussed, I'll try more searches on the archives :-) Costin Tim Funk wrote: Didn't we already try that with the tomcat 4 LE edition? -Tim Remy Maucherat wrote: My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: autostart for /admin - was Re: StandardClassLoader ?
Costin Manolache wrote: Remy Maucherat wrote: The time is mostly parsing web.xml. However, it's nothing when compared to starting certain webapps (such as the admin webapp), where *one* webapp takes more time than starting up the rest of Tomcat (including all the simple webapps, JMX and the modeler descriptors, etc). Does it really need load-on-startup for its ApplicationServlet ?? Try it without ;) I tried. Do we really need to load /admin on startup ? Most people never use it, or use it only ocasionally. How many times do you configure the server ? I know, but it doesn't work right now (it's Struts' fault :( ). If you have ideas to make it work, then I'm obviously +1 for removing the load-on-startup thing. One simple solution is to add % // Force the initialization of action servlet RequestDispatcher actionS=getServletContext().getNamedDispatcher(action).include(request,response); % in login.jsp This seems good enough already. A better solution is to add a small filter that will make sure struts is initialized. However that doesn't seem to work with login.jsp - the filter is not called ( I tried explicit match, by name, etc ). login.jsp is a forward. Did you try mapping the filter on a forward ? BTW, does the spec says that the form login page is excluded from filters ?? That's undefined, as it's some kind of internal dispatching of the container. It seemed reasonable trying to do it with a RD forward. I can check in both the filter and the small hack to login.jsp, it seems to work fine. Having lazy loaded webapps as a generic solution will help both admin/ but also other infrequently used webapps. BTW - load-on-startup doesn't necesarily mean server startup ( at least that's my understanding ), it means when the webapp is started. I don't think we can have that. It doesn't fit the way the other stuff works (deployer, mapper). Well, the mapper is already able to deal with webapps that are removed/added/reloaded. A lazy loaded app is like an app that has a single mapping, /* - mapped to a lazy-load action that will read web.xml and add the other mappings. I think it's a very reasonable use case - performance is not only about HelloWorld response time, but also about hosting 1000s small ( and infrequently used ) apps. Apache can handle very large numbers of virtual hosts and apps. Well, you can use DOM for web.xml - but you need DOM only when changing settings, so you can also create the dom lazy, and use the .ser form on regular startup. DOM is for server.xml. I don't think we need to save web.xml, right ? Well, that's a big discussion, let's leave it for another time :-) I agree. I'm kinda running out of optimization ideas, though (I don't know if you profiled the regular request processing lately, but there's really nothing left). There doesn't seem to be too much which is doable with the startup overall. See above. I ran out of ideas for the basic path long ago ( or at least out of interest :-), it is more than enough for most uses. Optimizations for the other direction - very larger number of apps/vhosts - are more interesting. So is optimizing the uptime - having tomcat never need a restart is sometimes better than slightly better startup time. I did a lot already for the 1 webapps use case, for example removing the need for one backgroud thread per webapp in 5.0.x. I don't really see what it changes for production servers: if something as heavy as the admin webapp starts up, it's going to kill the server performance. I agree delaying webapp startup would give a better impression of performance, but it would be actually bad for a number of configurations. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30368] - Problem with URLDecode
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30368. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30368 Problem with URLDecode --- Additional Comments From [EMAIL PROTECTED] 2004-08-10 07:56 --- Mark thanks for your reply. My expected behaviour was (and still is) that the servlet container should make no assumption about an encoding of the URI. getPathInfo() should URLdecode the % xx characters but nothing else. The further interpretation should be in the responsibility of my servlet, i.e. in our case we UTF-8-decode the servlet path as well as the query string. From your comment I read that you consider querystring parameters the same as servlet paths but the default behaviour in Tomcat is not the same. As I wrote we have passed UTF-8-Strings via querystring parameters for a long time. getParameter() does the URLdecoding and afterwards we manually UTF-8- decode this string. Now we have started to use the servlet path and use getPathInfo() and expected the same and run into the problem described here. With your connector attributes I think we should Tomcat let UTF-8-decode the URL but then we have to omit the UTF-8-decoding from our servlet. But is that portable across other servlet containers? We will not use your suggestion but use our own implementation of getPathInfo(). Again in short: IMO the servlet path obtained by getPathInfo() should be handled the same way as the querystring handled by getParameter(). Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: md5 sums for jakarta downloads
Begin forwarded message: From: Andy Mudrak [EMAIL PROTECTED] Date: 10 August 2004 00:57:44 BST To: [EMAIL PROTECTED] Subject: md5 sums for jakarta downloads Hi, I noticed that your MD5 sums on your website are not all formatted correctly. I specifically downloaded the Tomcat 5.0.27 MD5 file, and found this out. Not that its a big deal or anything like that, but itd be good to have the MD5 properly formatted, that is the MD5 sum and then the file name Thanks, Andy Mudrak [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: md5 sums for jakarta downloads
Pier Fumagalli wrote: Begin forwarded message: From: Andy Mudrak [EMAIL PROTECTED] Date: 10 August 2004 00:57:44 BST To: [EMAIL PROTECTED] Subject: md5 sums for jakarta downloads Hi, I noticed that your MD5 sums on your website are not all formatted correctly. I specifically downloaded the Tomcat 5.0.27 MD5 file, and found this out. Not that its a big deal or anything like that, but itd be good to have the MD5 properly formatted, that is the MD5 sum and then the file name I am not sure that is a good idea: +++ -bash-2.05b$ openssl md5 toto MD5(toto)= efd6b079984c77cd80254ff266e9ab43 +++ And looking in the Jakarta Binary downloads I have found that a lot of other MD5 file are using the Tomcat format. Thanks, Andy Mudrak [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs setup.xml
mturk 2004/08/10 02:33:33 Modified:webapps/docs setup.xml Log: Added link to WIndows-service-howto. Revision ChangesPath 1.8 +4 -0 jakarta-tomcat-catalina/webapps/docs/setup.xml Index: setup.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/setup.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- setup.xml 30 Dec 2003 16:54:48 - 1.7 +++ setup.xml 10 Aug 2004 09:33:33 - 1.8 @@ -51,6 +51,10 @@ will not be any tray icon present when Tomcat is running. Note that when choosing to run Tomcat at the end of installation, the tray icon will be used even if Tomcat was installed as a service./li +liRefer to the +a href=windows-service-howto.htmlWindows Service HOW-TO/a +for information on how to manage Tomcat as Windows NT service. +/li /ul /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Shapira, Yoav wrote: Hi, A TOMCAT_5_0 branch was created at the time 5.0.27 was released. I'm not gung-ho about making significant Tomcat 5.0 additions and enhancements, given the advanced state of Tomcat 5.1 development. If there's a showstopper, security, or spec-compliance bug than of course it will be fixed and additional releases made. I didn't know there was a branch already! Thanks - that's great. As for the nature of the changes, the bug fixes are important fixes in the area of JSR 45 spec-compliance. I believe they affect all tools that use JSR 45 for debugging, not just NetBeans. However, if you really want this strongly, feel free to submit patches back-porting the CVS HEAD patches onto the TOMCAT_5_0 branch code, and we'll look at them. Thanks. As for JDK 1.5 specifically: Tomcat 5.1 will support JDK 1.5 without needing to modify anything. Tomcat 5.0 doesn't make that claim, but it does let you modify parsers as you want using the standard endorsed classloading mechanism. Of course I've already said that on the bug report ;) I guess there are two possible perceptions of this problem. One is that we should strive for the cleanest possible architecture, and have multiple releases each targetting a particular platform. The other is that there should be a single universal release that supports a range of platforms, and the architecture should be able to accomodate all of them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. Hi, Oh and BTW, definitely -1 on committing to regular monthly releases. They'll come when they're ready: that's always been the process. And ready itself is also ambiguously defined as a critical fix, significant enhancements, large number of bug fixes, or a combination thereof. If the average duration between releases for us has been 1 month, that's great, but it's a coincidence that I don't want to commit to ;) There are far too many variables in our work for that. Agreed, it is not reasonable to commit to regular release schedule (based on my own experience ;) In my mind, release schedule is an approximate guideline, not committment. Yoav Shapira Millennium Research Informatics Petr -Original Message- From: Petr Jiricka [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 12:43 PM To: [EMAIL PROTECTED] Subject: Tomcat 5.0.28 release Hi, we have been using Tomcat in the NetBeans product for about 4 years now (since the 3.2 beta releases), so first off, Thanks! for all your great work. Tomcat provides NetBeans users with the ability to run their applications out of the box, debug in on the Java and JSP level, and generally serves as an excellent testing environment for web applications developed using NetBeans. Now, on behalf of the Sun Developer Tools group, I'd like to propose a next release of the Tomcat 5.0.x codeline, i.e. Tomcat 5.0.28. The goals of this release would be the following: - Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model. - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) - Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered. From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue
cvs commit: jakarta-tomcat-catalina/catalina/src/bin service.bat
mturk 2004/08/10 04:10:26 Modified:catalina/src/bin service.bat Log: Set the JVM to reflect the set JAVA_HOME. Revision ChangesPath 1.7 +12 -4 jakarta-tomcat-catalina/catalina/src/bin/service.bat Index: service.bat === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/service.bat,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- service.bat 28 Jul 2004 05:32:36 - 1.6 +++ service.bat 10 Aug 2004 11:10:26 - 1.7 @@ -63,6 +63,10 @@ :doInstall rem Install the service +echo Installing the service '%SERVICE_NAME%' ... +echo Using CATALINA_HOME:%CATALINA_HOME% +echo Using JAVA_HOME:%JAVA_HOME% + rem Use the environment variables as an exaple rem Each command line option is prefixed with PR_ @@ -71,20 +75,24 @@ set PR_INSTALL=%EXECUTABLE% set PR_LOGPATH=%CATALINA_HOME%\logs set PR_CLASSPATH=%JAVA_HOME%\lib\tools.jar;%CATALINA_HOME%\bin\bootstrap.jar -%EXECUTABLE% //IS//%SERVICE_NAME% --Jvm auto --StartClass org.apache.catalina.startup.Bootstrap --StopClass org.apache.catalina.startup.Bootstrap --StartParams start --StopParams stop +rem Set the server jvm frrom JAVA_HOME +set PR_JVM=%JAVA_HOME%\jre\bin\server\jvm.dll +rem You can use the 'set PR_JVM=auto' for default JVM +%EXECUTABLE% //IS//%SERVICE_NAME% --StartClass org.apache.catalina.startup.Bootstrap --StopClass org.apache.catalina.startup.Bootstrap --StartParams start --StopParams stop rem Clear the environment variables. They are not needed any more. set PR_DISPLAYNAME= set PR_DESCRIPTION= set PR_INSTALL= set PR_LOGPATH= set PR_CLASSPATH= +set PR_JVM= rem Set extra parameters %EXECUTABLE% //US//%SERVICE_NAME% --JvmOptions -Dcatalina.base=%CATALINA_BASE%;-Dcatalina.home=%CATALINA_HOME%;-Djava.endorsed.dirs=%CATALINA_HOME%\common\endorsed --StartMode jvm --StopMode jvm rem More extra parameters set PR_STDOUTPUT=%CATALINA_HOME%\logs\stdout.log set PR_STDERROR=%CATALINA_HOME%\logs\stderr.log -%EXECUTABLE% //US//%SERVICE_NAME% ++JvmOptions -Djava.io.tmpdir=%CATALINA_BASE%\temp -echo The service '%SERVICE_NAME%' has been installed +%EXECUTABLE% //US//%SERVICE_NAME% ++JvmOptions -Djava.io.tmpdir=%CATALINA_BASE%\temp --JvmMs 128 --JvmMx 256 +echo The service '%SERVICE_NAME%' has been installed. :end cd %CURRENT_DIR% - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat5.exe tomcat5w.exe
mturk 2004/08/10 04:15:58 Modified:procrun/bin tomcat5.exe tomcat5w.exe Log: Latest Tomcat5 and Tomcat5w binaries. Fixes the environment and JvmMs and JvmMx parsing. Revision ChangesPath 1.4 +129 -115 jakarta-tomcat-connectors/procrun/bin/tomcat5.exe Binary file 1.4 +94 -99jakarta-tomcat-connectors/procrun/bin/tomcat5w.exe Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Remy Maucherat wrote: Petr Jiricka wrote: - Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model. I do manage to integrate patches in the JBoss tree without the need for a stable release, whenever I really need a particular fix. IMO, you should be prepared to do the same once in a while, it's easier for everyone. I believe Tomcat is used in a number of high profile servers (in addition to your usage), so making a release each time someone needs something (I suppose in the few days before a freeze of the relevant products, it would probably be every 5 minutes ;) ) isn't possible. The advantage of stable releases is that these are much more thoroughly tested by the community than ad-hoc builds. Also, a stable release is a way of saying to the community that we believe that what we have now works together, it is safe to use the fixes that have come in. We should not be asking why to do a release - let's ask why not?. We could easily do a custom build with just the bugfixes we need, but I think the community would benefit if the fixes are exposed in a public release. As for the other part of your question - yes, our main motivation for a new release is to use it in our product, but we are not talking about days. In fact, we have been testing NetBeans with Tomcat 5 since January, and submitted a fair number of bug reports since then. I believe monthly releases are reasonable - we are definitely not talking about a release every 5 minutes :) - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) This is disruptive for 5.0.x. So, sorry, but I vote no for that one. My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?). Ok, we have a different opinion here, see my reply to Yoav. - Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered. This makes sense, but you need to indicate which patches need to be backported. I expect it's the JSP debugging related fixes then ? Yes, we'd like to see the JSP debugging bugfixes in, but I am not only talking about bugfixes requested by Sun. If the community feels strongly that a particular bugfix should be ported to 5.0.x, then it can be done. This should be a community effort, not a Sun release. From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue development of the 5.0.x codebase. Nice plan :) (ok, actually, we did that already before starting the refactoring, as Yoav mentioned) Thanks again. Petr Rémy - 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]
Re: Tomcat 5.0.28 release
Costin Manolache wrote: I'm sorry, but can't remember - why do we still need the endorsed ? I tought they were a temporary solution for JDK1.4 and some validation problems - tomcat should work fine with any SAX/DOM parser, including the one in JDK1.4. This would be good, if it's indeed possible. I just tried removing common/endorsed/*.jar from Tomcat 5.0.27, and it seemed to work ok on JDK 1.4.2_04. I didn't try any XML tags in JSTL (which often prove fragile wrt. parser configuration), but at first sight it works. The only problem is JDK1.3 - and I agree that it would be better to just provide a patch for 1.3 ( or ask the user to install a parser in jre/ext or classpath, to get the same behavior as in 1.4 ). Or even better - in Bootstrap check if we're in 1.3 and add the parser to the classpath, otherwise use whatever is in jdk ( and maybe turn validation of if the version of jdk and parser is not the right one ). In any case - modularizing the distribution would be really good. Having a core JDK1.5 distro, and additional packages to add JDK1.4 and JDK1.3 support is good. It would also be good to distribute more components as optional plug-ins. I agree this is a good plan, as long as there is a way to build a single distribution that supports all the supported platforms (or at least JDK 1.4.x + 1.5). Thanks Petr Again - I missed a lot of discussions, probably most of this has been discussed, I'll try more searches on the archives :-) Costin Tim Funk wrote: Didn't we already try that with the tomcat 4 LE edition? -Tim Remy Maucherat wrote: My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?). - 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]
RE: Fwd: md5 sums for jakarta downloads
Hi, The format I use for MD5 sums is the standard one. Every other project I know uses this format, so I think if anything this user needs to adjust his preferences ;) However, if there's a standard or spec somewhere that mandates we use md5 -r (reverse output format), then sure, someone point me to it and I'll follow that spec when signing releases. Yoav Shapira Millennium Research Informatics -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 5:26 AM To: Tomcat Developers List Subject: Re: Fwd: md5 sums for jakarta downloads Pier Fumagalli wrote: Begin forwarded message: From: Andy Mudrak [EMAIL PROTECTED] Date: 10 August 2004 00:57:44 BST To: [EMAIL PROTECTED] Subject: md5 sums for jakarta downloads Hi, I noticed that your MD5 sums on your website are not all formatted correctly. I specifically downloaded the Tomcat 5.0.27 MD5 file, and found this out. Not that it's a big deal or anything like that, but it'd be good to have the MD5 properly formatted, that is the MD5 sum and then the file name... I am not sure that is a good idea: +++ -bash-2.05b$ openssl md5 toto MD5(toto)= efd6b079984c77cd80254ff266e9ab43 +++ And looking in the Jakarta Binary downloads I have found that a lot of other MD5 file are using the Tomcat format. Thanks, Andy Mudrak [EMAIL PROTECTED] - 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]
RE: Tomcat 5.0.28 release
Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. As for the nature of the changes, the bug fixes are important fixes in the area of JSR 45 spec-compliance. I believe they affect all tools that use JSR 45 for debugging, not just NetBeans. Ahh -- that's good. Please make sure to note them as such when you report them. It will raise their importance significantly. them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. The disk space benefits aren't worth it. The central administration benefits might be, but I wonder how many people use this. Maybe an informal survey on the user list is worth doing? The rest of what you said, I agree with. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0.28 release
I for one use the CATALINA_BASE vs CATALINA_HOME Mitchell Marx -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 8:53 AM To: Tomcat Developers List Subject: RE: Tomcat 5.0.28 release Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. As for the nature of the changes, the bug fixes are important fixes in the area of JSR 45 spec-compliance. I believe they affect all tools that use JSR 45 for debugging, not just NetBeans. Ahh -- that's good. Please make sure to note them as such when you report them. It will raise their importance significantly. them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. The disk space benefits aren't worth it. The central administration benefits might be, but I wonder how many people use this. Maybe an informal survey on the user list is worth doing? The rest of what you said, I agree with. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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]
Re: Fwd: md5 sums for jakarta downloads
This is the md5 output generated by BSD md5 and not necessarily a standard, GNU md5sum generates a different format that is not standard as well. For maven, just the checksum portion of the content is stored in the file. It would be nice if there was a standard in this area, but I have yet to see one in the internet community. We have the same problem with generating md5 checksums for the maven repository at the moment. -Mark Shapira, Yoav wrote: Hi, The format I use for MD5 sums is the standard one. Every other project I know uses this format, so I think if anything this user needs to adjust his preferences ;) However, if there's a standard or spec somewhere that mandates we use md5 -r (reverse output format), then sure, someone point me to it and I'll follow that spec when signing releases. Yoav Shapira Millennium Research Informatics -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 5:26 AM To: Tomcat Developers List Subject: Re: Fwd: md5 sums for jakarta downloads Pier Fumagalli wrote: Begin forwarded message: From: Andy Mudrak [EMAIL PROTECTED] Date: 10 August 2004 00:57:44 BST To: [EMAIL PROTECTED] Subject: md5 sums for jakarta downloads Hi, I noticed that your MD5 sums on your website are not all formatted correctly. I specifically downloaded the Tomcat 5.0.27 MD5 file, and found this out. Not that it's a big deal or anything like that, but it'd be good to have the MD5 properly formatted, that is the MD5 sum and then the file name... I am not sure that is a good idea: +++ -bash-2.05b$ openssl md5 toto MD5(toto)= efd6b079984c77cd80254ff266e9ab43 +++ And looking in the Jakarta Binary downloads I have found that a lot of other MD5 file are using the Tomcat format. Thanks, Andy Mudrak [EMAIL PROTECTED] - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/ajp/proxy mod_proxy.c
mturk 2004/08/10 06:49:11 Modified:ajp/proxy mod_proxy.c Log: Use the pool for add_worker call. Revision ChangesPath 1.32 +1 -1 jakarta-tomcat-connectors/ajp/proxy/mod_proxy.c Index: mod_proxy.c === RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/mod_proxy.c,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- mod_proxy.c 9 Aug 2004 15:10:02 - 1.31 +++ mod_proxy.c 10 Aug 2004 13:49:11 - 1.32 @@ -1300,7 +1300,7 @@ return apr_pstrcat(cmd-temp_pool, BalancerMember , err, NULL); } /* Add the worker to the load balancer */ -ap_proxy_add_worker_to_balancer(balancer, worker); +ap_proxy_add_worker_to_balancer(cmd-pool, balancer, worker); return NULL; } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: md5 sums for jakarta downloads
For example here are the outputs of the various signing tools we use at this time: BSD md5: md5 commons-collections-3.1.jar MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36 while the GNU md5 script generates the following: [EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar And maven just generates and uses: d1dcb0fbee884bb855bb327b8190af36 Yes, the nice thing about BSD md5 is that the -r can be used to make it look like the GNU md5sum output, it would probably be good if we started to use this as it will be more prevalent and possibly is the closest one can get to a standard: md5 -r commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar Mark R. Diggory wrote: This is the md5 output generated by BSD md5 and not necessarily a standard, GNU md5sum generates a different format that is not standard as well. For maven, just the checksum portion of the content is stored in the file. It would be nice if there was a standard in this area, but I have yet to see one in the internet community. We have the same problem with generating md5 checksums for the maven repository at the moment. -Mark Shapira, Yoav wrote: Hi, The format I use for MD5 sums is the standard one. Every other project I know uses this format, so I think if anything this user needs to adjust his preferences ;) However, if there's a standard or spec somewhere that mandates we use md5 -r (reverse output format), then sure, someone point me to it and I'll follow that spec when signing releases. Yoav Shapira Millennium Research Informatics -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 5:26 AM To: Tomcat Developers List Subject: Re: Fwd: md5 sums for jakarta downloads Pier Fumagalli wrote: Begin forwarded message: From: Andy Mudrak [EMAIL PROTECTED] Date: 10 August 2004 00:57:44 BST To: [EMAIL PROTECTED] Subject: md5 sums for jakarta downloads Hi, I noticed that your MD5 sums on your website are not all formatted correctly. I specifically downloaded the Tomcat 5.0.27 MD5 file, and found this out. Not that it's a big deal or anything like that, but it'd be good to have the MD5 properly formatted, that is the MD5 sum and then the file name... I am not sure that is a good idea: +++ -bash-2.05b$ openssl md5 toto MD5(toto)= efd6b079984c77cd80254ff266e9ab43 +++ And looking in the Jakarta Binary downloads I have found that a lot of other MD5 file are using the Tomcat format. Thanks, Andy Mudrak [EMAIL PROTECTED] - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_util.c mod_proxy.h
mturk 2004/08/10 06:50:53
Modified:ajp/proxy proxy_util.c mod_proxy.h
Log:
Shared memory support. The shared memory is inside
apache scoreboard. If it ever gets back ported we could use it on 2.0
Revision ChangesPath
1.23 +45 -12jakarta-tomcat-connectors/ajp/proxy/proxy_util.c
Index: proxy_util.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/proxy_util.c,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- proxy_util.c 9 Aug 2004 15:07:20 - 1.22
+++ proxy_util.c 10 Aug 2004 13:50:53 - 1.23
@@ -16,6 +16,7 @@
/* Utility routines for Apache proxy */
#include mod_proxy.h
#include ap_mpm.h
+#include scoreboard.h
#include apr_version.h
#if (APR_MAJOR_VERSION 1)
@@ -23,6 +24,9 @@
#define apr_socket_create apr_socket_create_ex
#endif
+/* Global balancer counter */
+static int lb_workers = 0;
+
static int proxy_match_ipaddr(struct dirconn_entry *This, request_rec *r);
static int proxy_match_domainname(struct dirconn_entry *This, request_rec *r);
static int proxy_match_hostname(struct dirconn_entry *This, request_rec *r);
@@ -1038,7 +1042,7 @@
return can not create thread mutex;
}
#endif
-
+
return NULL;
}
@@ -1137,52 +1141,76 @@
}
PROXY_DECLARE(void)
-ap_proxy_add_worker_to_balancer(proxy_balancer *balancer, proxy_worker *worker)
+ap_proxy_add_worker_to_balancer(apr_pool_t *pool, proxy_balancer *balancer,
proxy_worker *worker)
{
int i;
double median, ffactor = 0.0;
-proxy_runtime_worker *runtime, *workers;
+proxy_runtime_worker *runtime, *workers;
+#if PROXY_HAS_SCOREBOARD
+lb_score *score;
+#else
+void *score;
+#endif
+#if PROXY_HAS_SCOREBOARD
+int mpm_daemons;
+
+ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, mpm_daemons);
+/* Check if we are prefork or single child */
+if (worker-hmax mpm_daemons 1)
+score = ap_get_scoreboard_lb(getpid(), lb_workers);
+else
+#endif
+{
+/* Use the plain memory */
+score = apr_pcalloc(pool, sizeof(proxy_runtime_stat));
+}
+if (!score)
+return;
runtime = apr_array_push(balancer-workers);
runtime-w = worker;
+runtime-s = (proxy_runtime_stat *)score;
+runtime-s-id = lb_workers;
+/* TODO: deal with the dynamic overflow */
+++lb_workers;
/* Recalculate lbfactors */
workers = (proxy_runtime_worker *)balancer-workers-elts;
for (i = 0; i balancer-workers-nelts; i++) {
/* Set to the original configuration */
-workers[i].lbfactor = workers[i].w-lbfactor;
-ffactor += workers[i].lbfactor;
+workers[i].s-lbfactor = workers[i].w-lbfactor;
+ffactor += workers[i].s-lbfactor;
}
if (ffactor 100.0) {
int z = 0;
for (i = 0; i balancer-workers-nelts; i++) {
-if (workers[i].lbfactor == 0.0)
+if (workers[i].s-lbfactor == 0.0)
++z;
}
if (z) {
median = (100.0 - ffactor) / z;
for (i = 0; i balancer-workers-nelts; i++) {
-if (workers[i].lbfactor == 0.0)
-workers[i].lbfactor = median;
+if (workers[i].s-lbfactor == 0.0)
+workers[i].s-lbfactor = median;
}
}
else {
median = (100.0 - ffactor) / balancer-workers-nelts;
for (i = 0; i balancer-workers-nelts; i++)
-workers[i].lbfactor += median;
+workers[i].s-lbfactor += median;
}
}
else if (ffactor 100.0) {
median = (ffactor - 100.0) / balancer-workers-nelts;
for (i = 0; i balancer-workers-nelts; i++) {
-if (workers[i].lbfactor median)
-workers[i].lbfactor -= median;
+if (workers[i].s-lbfactor median)
+workers[i].s-lbfactor -= median;
}
}
for (i = 0; i balancer-workers-nelts; i++) {
/* Update the status entires */
-workers[i].lbstatus = workers[i].lbfactor;
+workers[i].s-lbstatus = workers[i].s-lbfactor;
}
}
@@ -1756,4 +1784,9 @@
ap_run_pre_connection(conn-connection, conn-sock);
return OK;
+}
+
+PROXY_DECLARE(int) ap_proxy_lb_workers(void)
+{
+return (lb_workers + PROXY_DYNAMIC_BALANCER_LIMIT);
}
1.29 +25 -4 jakarta-tomcat-connectors/ajp/proxy/mod_proxy.h
Index: mod_proxy.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/mod_proxy.h,v
retrieving revision
RE: Fwd: md5 sums for jakarta downloads
Hi, Well, as always, when there's an established practice I'd like a stronger reason than it would probably be good to change it ;) I see what you mean, but I don't know that the GNU md5 is any more prevalent than the BSD md5 or vice versa... Yoav Shapira Millennium Research Informatics -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 9:52 AM To: Tomcat Developers List Cc: [EMAIL PROTECTED] Subject: Re: Fwd: md5 sums for jakarta downloads For example here are the outputs of the various signing tools we use at this time: BSD md5: md5 commons-collections-3.1.jar MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36 while the GNU md5 script generates the following: [EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar And maven just generates and uses: d1dcb0fbee884bb855bb327b8190af36 Yes, the nice thing about BSD md5 is that the -r can be used to make it look like the GNU md5sum output, it would probably be good if we started to use this as it will be more prevalent and possibly is the closest one can get to a standard: md5 -r commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar Mark R. Diggory wrote: This is the md5 output generated by BSD md5 and not necessarily a standard, GNU md5sum generates a different format that is not standard as well. For maven, just the checksum portion of the content is stored in the file. It would be nice if there was a standard in this area, but I have yet to see one in the internet community. We have the same problem with generating md5 checksums for the maven repository at the moment. -Mark Shapira, Yoav wrote: Hi, The format I use for MD5 sums is the standard one. Every other project I know uses this format, so I think if anything this user needs to adjust his preferences ;) However, if there's a standard or spec somewhere that mandates we use md5 -r (reverse output format), then sure, someone point me to it and I'll follow that spec when signing releases. Yoav Shapira Millennium Research Informatics -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 5:26 AM To: Tomcat Developers List Subject: Re: Fwd: md5 sums for jakarta downloads Pier Fumagalli wrote: Begin forwarded message: From: Andy Mudrak [EMAIL PROTECTED] Date: 10 August 2004 00:57:44 BST To: [EMAIL PROTECTED] Subject: md5 sums for jakarta downloads Hi, I noticed that your MD5 sums on your website are not all formatted correctly. I specifically downloaded the Tomcat 5.0.27 MD5 file, and found this out. Not that it's a big deal or anything like that, but it'd be good to have the MD5 properly formatted, that is the MD5 sum and then the file name... I am not sure that is a good idea: +++ -bash-2.05b$ openssl md5 toto MD5(toto)= efd6b079984c77cd80254ff266e9ab43 +++ And looking in the Jakarta Binary downloads I have found that a lot of other MD5 file are using the Tomcat format. Thanks, Andy Mudrak [EMAIL PROTECTED] - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_balancer.c
mturk 2004/08/10 06:52:51
Modified:ajp/proxy proxy_balancer.c
Log:
Use the proxy_runtime_stat that either comes from scoreboard or
directly allocating memory if there is no scoreboard support or it is not
neaded, due to the fact that we have single child process.
Revision ChangesPath
1.5 +9 -8 jakarta-tomcat-connectors/ajp/proxy/proxy_balancer.c
Index: proxy_balancer.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/proxy_balancer.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- proxy_balancer.c 9 Aug 2004 15:08:28 - 1.4
+++ proxy_balancer.c 10 Aug 2004 13:52:51 - 1.5
@@ -31,6 +31,7 @@
#define PROXY_BALANCER_UNLOCK(b)APR_SUCCESS
#endif
+
/* Retrieve the parameter with the given name*/
static char *get_path_param(apr_pool_t *pool, char *url,
const char *name)
@@ -162,7 +163,7 @@
* This is for cases when worker is in error state.
* It will force the even request distribution
*/
-total_factor += worker-lbfactor;
+total_factor += worker-s-lbfactor;
}
worker++;
}
@@ -207,7 +208,7 @@
* Lbstatus is of higher importance then
* the number of empty slots.
*/
-if (worker-lbstatus candidate-lbstatus) {
+if (worker-s-lbstatus candidate-s-lbstatus) {
candidate = worker;
}
}
@@ -221,9 +222,9 @@
/* XXX: The lbfactor can be update using bytes transfered
* Right now, use the round-robin scheme
*/
-worker-lbstatus += worker-lbfactor;
-if (worker-lbstatus = total_factor)
-worker-lbstatus = worker-lbfactor;
+worker-s-lbstatus += worker-s-lbfactor;
+if (worker-s-lbstatus = total_factor)
+worker-s-lbstatus = worker-s-lbfactor;
}
worker++;
}
@@ -289,9 +290,9 @@
workers = (proxy_runtime_worker *)(*balancer)-workers-elts;
for (i = 0; i (*balancer)-workers-nelts; i++) {
/* For now assume that all workers are OK */
-workers-lbstatus += workers-lbfactor;
-if (workers-lbstatus = 100.0)
-workers-lbstatus = workers-lbfactor;
+workers-s-lbstatus += workers-s-lbfactor;
+if (workers-s-lbstatus = 100.0)
+workers-s-lbstatus = workers-s-lbfactor;
workers++;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/ajp/proxy mod_proxy.c proxy_balancer.c proxy_util.c mod_proxy.h
mturk 2004/08/10 07:58:24
Modified:ajp/proxy mod_proxy.c proxy_balancer.c proxy_util.c
mod_proxy.h
Log:
Implement the worker retry functionality.
It uses either worker-retry option or default 60 second retry
that is on each revolution extended by another 60 seconds.
Revision ChangesPath
1.33 +1 -1 jakarta-tomcat-connectors/ajp/proxy/mod_proxy.c
Index: mod_proxy.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/mod_proxy.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- mod_proxy.c 10 Aug 2004 13:49:11 - 1.32
+++ mod_proxy.c 10 Aug 2004 14:58:24 - 1.33
@@ -97,7 +97,7 @@
else if (!strcasecmp(key, retry)) {
ival = atoi(val);
if (ival 1)
-return Retry must be al least one second;
+return Retry must be at least one second;
worker-retry = apr_time_from_sec(ival);
}
else if (!strcasecmp(key, ttl)) {
1.6 +7 -4 jakarta-tomcat-connectors/ajp/proxy/proxy_balancer.c
Index: proxy_balancer.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/proxy_balancer.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- proxy_balancer.c 10 Aug 2004 13:52:51 - 1.5
+++ proxy_balancer.c 10 Aug 2004 14:58:24 - 1.6
@@ -146,11 +146,14 @@
/* First try to see if we have available candidate */
for (i = 0; i balancer-workers-nelts; i++) {
-/* If the worker is not error state
- * or not in disabled mode
+/* See if the retry timeout is ellapsed
+ * for the workers flagged as IN_ERROR
+ */
+if (!PROXY_WORKER_IS_USABLE(worker-w))
+ap_proxy_retry_worker(BALANCER, worker-w, r-server)
+/* If the worker is not in error state
+ * or not disabled.
*/
-
-/* TODO: read the scoreboard status */
if (PROXY_WORKER_IS_USABLE(worker-w)) {
if (!candidate)
candidate = worker;
1.24 +47 -2 jakarta-tomcat-connectors/ajp/proxy/proxy_util.c
Index: proxy_util.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/proxy_util.c,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- proxy_util.c 10 Aug 2004 13:50:53 - 1.23
+++ proxy_util.c 10 Aug 2004 14:58:24 - 1.24
@@ -1471,6 +1471,31 @@
return rv;
}
+PROXY_DECLARE(int) ap_proxy_retry_worker(const char *proxy_function,
+ proxy_worker *worker,
+ server_rec *s)
+{
+if (worker-status PROXY_WORKER_IN_ERROR) {
+apr_interval_time_t diff;
+apr_time_t now = apr_time_now();
+if (worker-retry)
+diff = worker-retry;
+else
+diff = apr_time_from_sec(60 + 60 * worker-retries++);
+if (now worker-error_time + diff) {
+worker-status = ~PROXY_WORKER_IN_ERROR;
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+ proxy: %s: retrying the worker for (%s),
+ proxy_function, worker-hostname);
+return OK;
+}
+else
+return DECLINED;
+}
+else
+return OK;
+}
+
PROXY_DECLARE(int) ap_proxy_acquire_connection(const char *proxy_function,
proxy_conn_rec **conn,
proxy_worker *worker,
@@ -1483,10 +1508,22 @@
ap_log_error(APLOG_MARK, APLOG_ERR, rv, s,
proxy: %s: failed to initialize worker for (%s),
proxy_function, worker-hostname);
-return DECLINED;
+return HTTP_INTERNAL_SERVER_ERROR;
}
worker-status = PROXY_WORKER_INITIALIZED;
}
+
+if (!PROXY_WORKER_IS_USABLE(worker)) {
+/* Retry the worker */
+ap_proxy_retry_worker(proxy_function, worker, s);
+
+if (!PROXY_WORKER_IS_USABLE(worker)) {
+ap_log_error(APLOG_MARK, APLOG_ERR, rv, s,
+ proxy: %s: disabled connection for (%s),
+ proxy_function, worker-hostname);
+return HTTP_SERVICE_UNAVAILABLE;
+}
+}
#if APR_HAS_THREADS
if (worker-hmax) {
rv = apr_reslist_acquire(worker-cp-res, (void **)conn);
@@ -1508,7 +1545,7 @@
ap_log_error(APLOG_MARK, APLOG_ERR, rv, s,
Re: autostart for /admin - was Re: StandardClassLoader ?
Remy Maucherat wrote: One simple solution is to add % // Force the initialization of action servlet RequestDispatcher actionS=getServletContext().getNamedDispatcher(action).include(request,response); % in login.jsp This seems good enough already. Ok, I'll check it in then after I figure out why the filter didn't work, A better solution is to add a small filter that will make sure struts is initialized. However that doesn't seem to work with login.jsp - the filter is not called ( I tried explicit match, by name, etc ). login.jsp is a forward. Did you try mapping the filter on a forward ? BTW, does the spec says that the form login page is excluded from filters ?? That's undefined, as it's some kind of internal dispatching of the container. It seemed reasonable trying to do it with a RD forward. Well, if I have a filter on /* and / ( and I added for *.jsp, *.do and anything I could think of ) - I tought it'll be invoked for all requests in that context. Even if it is forwarded. I don't really see what it changes for production servers: if something as heavy as the admin webapp starts up, it's going to kill the server performance. I agree delaying webapp startup would give a better impression of performance, but it would be actually bad for a number of configurations. True. The lazy loading should be paired with automatic unloading/sleep of apps not used recently - again, based on config. In most servers I know, a small number of webapps are used most of the time, and the most webapps are almost never used, or just for very short time. Well - that's just an idea, I don't have an immediate itch for this one. I am impressed with Eclipse plugin architecture - and the way they manage the memory. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: autostart for /admin - was Re: StandardClassLoader ?
Costin Manolache wrote: Remy Maucherat wrote: BTW, does the spec says that the form login page is excluded from filters ?? That's undefined, as it's some kind of internal dispatching of the container. It seemed reasonable trying to do it with a RD forward. Well, if I have a filter on /* and / ( and I added for *.jsp, *.do and anything I could think of ) - I tought it'll be invoked for all requests in that context. Even if it is forwarded. Well, no. different invocation is a separate mapping (INCLUDE, FORWARD, etc; and no, there's no ALL mapping ;) ). I don't really see what it changes for production servers: if something as heavy as the admin webapp starts up, it's going to kill the server performance. I agree delaying webapp startup would give a better impression of performance, but it would be actually bad for a number of configurations. True. The lazy loading should be paired with automatic unloading/sleep of apps not used recently - again, based on config. In most servers I know, a small number of webapps are used most of the time, and the most webapps are almost never used, or just for very short time. Well - that's just an idea, I don't have an immediate itch for this one. I am impressed with Eclipse plugin architecture - and the way they manage the memory. Ah ok. Well, we could try to be progressivly adding these new features to the new branch, since I assume it would stay as stable-but-with-significant-feature-additions for some time. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
I would have to agree with the gentlemen from Sun and NetBeans that it is preferable to have a standard stable version bundled with other products as opposed to some other file set which one cannot independently reproduce. Why? Users of NetBeans, etc, would like to know that they can reproduce the same behavior outside the IDE by grabbing the same version label from Jakarta. If NetBeans uses its own set of source versions, then users never know what might differ between the NetBeans Tomcat behavior and standard Tomcat releases. I happen to be responsible for the redistribution of a modified Tomcat and have come to noting each and every deviation (change or addition) from the standard Tomcat release upon which I'm based for this reason. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30561] New: - NamingService doesn't correctly start/stop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30561.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30561
NamingService doesn't correctly start/stop
Summary: NamingService doesn't correctly start/stop
Product: Tomcat 5
Version: 5.0.27
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
1/ When you start the NamingService for the first time, with no
Context.INITIAL_CONTEXT_FACTORY property, everything works fine. The default
value is null.
2/ When you stop the NamingService, the property is then , and not null.
3/ If you want to restart the NamingService, the oldValue isn't null and so
it's used. So, the NamingService doesn't start.
This is my solution, in the start method:
oldValue = System.getProperty(Context.INITIAL_CONTEXT_FACTORY);
if (oldValue != null oldValue.length() 0 ) {
oldIcValue = oldValue;
} else {
System.setProperty(Context.INITIAL_CONTEXT_FACTORY, Constants.Package
+ .java.javaURLContextFactory);
}
Now, when you start + stop + start the NamingService, the service works fine.
Frederic
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. The disk space benefits aren't worth it. The central administration benefits might be, but I wonder how many people use this. Maybe an informal survey on the user list is worth doing? How about the other way around - stop support for the combined tomcat, and default to multi-user ( or multi-config ). I would be very happy to see the server layout change to support multiple configurations. Something like: /bin /lib - with manifest/properties file used to select what goes to common, server, shared :-) /servers /servers/all /servers/minimal With conf/ and webapps/ under each server. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: autostart for /admin - was Re: StandardClassLoader ?
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: BTW, does the spec says that the form login page is excluded from filters ?? That's undefined, as it's some kind of internal dispatching of the container. It seemed reasonable trying to do it with a RD forward. Well, if I have a filter on /* and / ( and I added for *.jsp, *.do and anything I could think of ) - I tought it'll be invoked for all requests in that context. Even if it is forwarded. Well, no. different invocation is a separate mapping (INCLUDE, FORWARD, etc; and no, there's no ALL mapping ;) ). Feel free to redirect me to tomcat-user :-), but is there any way to filter the form login page, or is it un-filtrable ? If it is included/forwarded/etc - it should be included from somewhere, and a filter would apply there. From what I see in the code, the form login happens before the filters - so I'm starting to understand why it doesn't work, but from a spec point a view, it looks like a small bug. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: md5 sums for jakarta downloads
Yes, well, I actually do not think much thought has gone into this subject at Apache, until know I think perople have thought the .md5 file format was a standard or something. I've been researching md5 applications in terms of attempting to make a recommendation to the repository group on the appropriate format to use in the ASF Repository project. To date my research shows that both applications support the GNU checksum filename.ext format when performing a md5sum (GNU) or cksum (BSD) check against the file/md5 pair. And that the GNU version of md5sum cannot handle the BSD's default md5 format. Since BSD cksum can read the GNU format, BSD md5 can produce the GNU format, and installations of the GNU toolkit and that md5 file format are much more prevalent than BSD and its format, then my recommendation is that would be the appropriate format to use for the time being. Its quite clear that the majority of the computers on the internet are not BSD systems, no matter how great the OS is ;-). IMHO, the decision for the appropriate md5 file format should be based on what applications require in the real world, not on which servers Apache actually uses in production. -Mark Diggory Shapira, Yoav wrote: Hi, Well, as always, when there's an established practice I'd like a stronger reason than it would probably be good to change it ;) I see what you mean, but I don't know that the GNU md5 is any more prevalent than the BSD md5 or vice versa... Yoav Shapira Millennium Research Informatics -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 9:52 AM To: Tomcat Developers List Cc: [EMAIL PROTECTED] Subject: Re: Fwd: md5 sums for jakarta downloads For example here are the outputs of the various signing tools we use at this time: BSD md5: md5 commons-collections-3.1.jar MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36 while the GNU md5 script generates the following: [EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar And maven just generates and uses: d1dcb0fbee884bb855bb327b8190af36 Yes, the nice thing about BSD md5 is that the -r can be used to make it look like the GNU md5sum output, it would probably be good if we started to use this as it will be more prevalent and possibly is the closest one can get to a standard: md5 -r commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar Mark R. Diggory wrote: This is the md5 output generated by BSD md5 and not necessarily a standard, GNU md5sum generates a different format that is not standard as well. For maven, just the checksum portion of the content is stored in the file. It would be nice if there was a standard in this area, but I have yet to see one in the internet community. We have the same problem with generating md5 checksums for the maven repository at the moment. -Mark Shapira, Yoav wrote: Hi, The format I use for MD5 sums is the standard one. Every other project I know uses this format, so I think if anything this user needs to adjust his preferences ;) However, if there's a standard or spec somewhere that mandates we use md5 -r (reverse output format), then sure, someone point me to it and I'll follow that spec when signing releases. Yoav Shapira Millennium Research Informatics -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 5:26 AM To: Tomcat Developers List Subject: Re: Fwd: md5 sums for jakarta downloads Pier Fumagalli wrote: Begin forwarded message: From: Andy Mudrak [EMAIL PROTECTED] Date: 10 August 2004 00:57:44 BST To: [EMAIL PROTECTED] Subject: md5 sums for jakarta downloads Hi, I noticed that your MD5 sums on your website are not all formatted correctly. I specifically downloaded the Tomcat 5.0.27 MD5 file, and found this out. Not that it's a big deal or anything like that, but it'd be good to have the MD5 properly formatted, that is the MD5 sum and then the file name... I am not sure that is a good idea: +++ -bash-2.05b$ openssl md5 toto MD5(toto)= efd6b079984c77cd80254ff266e9ab43 +++ And looking in the Jakarta Binary downloads I have found that a lot of other MD5 file are using the Tomcat format. Thanks, Andy Mudrak [EMAIL PROTECTED] - 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] --
RE: Tomcat 5.0.28 release
Hola, I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. It's the same good reason as for every upgrade: so that you (as the user) can use code that's simpler and more efficient because it doesn't have to account for differences between JDKs. This is not specific to Tomcat, it's a more generic product development decision. At some point you want to drop support for an older version of X because the cost of supporting it isn't worth the benefit. I'm not saying we've reached that point with JDK 1.3 yet, but the possibility must be reconsidered periodically and/or every time we're debating the work for a major new release branch. How about the other way around - stop support for the combined tomcat, and default to multi-user ( or multi-config ). I would be very happy to see the server layout change to support multiple configurations. Something like: /bin /lib - with manifest/properties file used to select what goes to common, server, shared :-) /servers /servers/all /servers/minimal With conf/ and webapps/ under each server. That's not a bad idea. I wouldn't mind it. It doesn't seem any worse than the current $CATALINA_HOME/$CATALINA_BASE approach. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: md5 sums for jakarta downloads
Shapira, Yoav wrote: Hi, Well, as always, when there's an established practice I'd like a stronger reason than it would probably be good to change it ;) I see what you mean, but I don't know that the GNU md5 is any more prevalent than the BSD md5 or vice versa... Maven format is the one we should use in Jakarta ;-) Probably the discussion must be moved to [EMAIL PROTECTED] so that the whole jakarta uses the same format and that we write a description of the format to use somewhere (if not yet done). Yoav Shapira Millennium Research Informatics -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 9:52 AM To: Tomcat Developers List Cc: [EMAIL PROTECTED] Subject: Re: Fwd: md5 sums for jakarta downloads For example here are the outputs of the various signing tools we use at this time: BSD md5: md5 commons-collections-3.1.jar MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36 while the GNU md5 script generates the following: [EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar And maven just generates and uses: d1dcb0fbee884bb855bb327b8190af36 Yes, the nice thing about BSD md5 is that the -r can be used to make it look like the GNU md5sum output, it would probably be good if we started to use this as it will be more prevalent and possibly is the closest one can get to a standard: md5 -r commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar Mark R. Diggory wrote: This is the md5 output generated by BSD md5 and not necessarily a standard, GNU md5sum generates a different format that is not standard as well. For maven, just the checksum portion of the content is stored in the file. It would be nice if there was a standard in this area, but I have yet to see one in the internet community. We have the same problem with generating md5 checksums for the maven repository at the moment. -Mark Shapira, Yoav wrote: Hi, The format I use for MD5 sums is the standard one. Every other project I know uses this format, so I think if anything this user needs to adjust his preferences ;) However, if there's a standard or spec somewhere that mandates we use md5 -r (reverse output format), then sure, someone point me to it and I'll follow that spec when signing releases. Yoav Shapira Millennium Research Informatics -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 5:26 AM To: Tomcat Developers List Subject: Re: Fwd: md5 sums for jakarta downloads Pier Fumagalli wrote: Begin forwarded message: From: Andy Mudrak [EMAIL PROTECTED] Date: 10 August 2004 00:57:44 BST To: [EMAIL PROTECTED] Subject: md5 sums for jakarta downloads Hi, I noticed that your MD5 sums on your website are not all formatted correctly. I specifically downloaded the Tomcat 5.0.27 MD5 file, and found this out. Not that it's a big deal or anything like that, but it'd be good to have the MD5 properly formatted, that is the MD5 sum and then the file name... I am not sure that is a good idea: +++ -bash-2.05b$ openssl md5 toto MD5(toto)= efd6b079984c77cd80254ff266e9ab43 +++ And looking in the Jakarta Binary downloads I have found that a lot of other MD5 file are using the Tomcat format. Thanks, Andy Mudrak [EMAIL PROTECTED] - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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]
Re: JDBC pool configuration bug/ugliness
This is a documentation bug, it should be: !-- Maximum number of idle dB connections to retain in pool. Set to -1 for no limit. -- A connection is considered idle when it is returned to the pool by calling conn.close() So by setting maxIdle=0 you never get any connection in the pool effectively disabling the pooling. This is probably not what you want. In your case you want to use the minEvictableIdleTimeMillis parameter. http://jakarta.apache.org/commons/dbcp/configuration.html If a connection is unused (idle) for xxx msec then the pool will close it. -- Dirk Wojciech Sobczuk wrote: hey, i hope that i'm getting to the right people with this email. anyway, the tomcat JDBC connection pool docs state: !-- Maximum number of idle dB connections to retain in pool. Set to 0 for no limit. -- parameter namemaxIdle/name value30/value /parameter well due to this i have to have at least one db connection per website using the database. i'm running a host with 30 such websites and each has 1 DB connections at all times. this isn't exactly critical but i'd like to have those connections dropped and opened up when they're needed, and not at all times like now. the configuration doesn't allow you to set maximum number of idle connections to 0 (anyway, when is a connection considered idle? that isn't covered by the configuration either at least the docs don't mention it). so i'm proposing to allow the user to set the max idle connection number to 0 so that all unused connections for a site can be reclaimed and there isn't always one hanging around. plus to allow the user to set what an idle connection means (how many seconds have to pass without a query before a connection is condered to be idle). thanks, Wojtek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fwd: md5 sums for jakarta downloads
Hi, Well, I buy Mark's research. What he says is reasonable. But I agree we should move the discussion to [EMAIL PROTECTED] if only to ensure the consensus. Yoav Shapira Millennium Research Informatics -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 12:54 PM To: Tomcat Developers List Subject: Re: Fwd: md5 sums for jakarta downloads Shapira, Yoav wrote: Hi, Well, as always, when there's an established practice I'd like a stronger reason than it would probably be good to change it ;) I see what you mean, but I don't know that the GNU md5 is any more prevalent than the BSD md5 or vice versa... Maven format is the one we should use in Jakarta ;-) Probably the discussion must be moved to [EMAIL PROTECTED] so that the whole jakarta uses the same format and that we write a description of the format to use somewhere (if not yet done). Yoav Shapira Millennium Research Informatics -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 9:52 AM To: Tomcat Developers List Cc: [EMAIL PROTECTED] Subject: Re: Fwd: md5 sums for jakarta downloads For example here are the outputs of the various signing tools we use at this time: BSD md5: md5 commons-collections-3.1.jar MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36 while the GNU md5 script generates the following: [EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar And maven just generates and uses: d1dcb0fbee884bb855bb327b8190af36 Yes, the nice thing about BSD md5 is that the -r can be used to make it look like the GNU md5sum output, it would probably be good if we started to use this as it will be more prevalent and possibly is the closest one can get to a standard: md5 -r commons-collections-3.1.jar d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar Mark R. Diggory wrote: This is the md5 output generated by BSD md5 and not necessarily a standard, GNU md5sum generates a different format that is not standard as well. For maven, just the checksum portion of the content is stored in the file. It would be nice if there was a standard in this area, but I have yet to see one in the internet community. We have the same problem with generating md5 checksums for the maven repository at the moment. -Mark Shapira, Yoav wrote: Hi, The format I use for MD5 sums is the standard one. Every other project I know uses this format, so I think if anything this user needs to adjust his preferences ;) However, if there's a standard or spec somewhere that mandates we use md5 -r (reverse output format), then sure, someone point me to it and I'll follow that spec when signing releases. Yoav Shapira Millennium Research Informatics -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 5:26 AM To: Tomcat Developers List Subject: Re: Fwd: md5 sums for jakarta downloads Pier Fumagalli wrote: Begin forwarded message: From: Andy Mudrak [EMAIL PROTECTED] Date: 10 August 2004 00:57:44 BST To: [EMAIL PROTECTED] Subject: md5 sums for jakarta downloads Hi, I noticed that your MD5 sums on your website are not all formatted correctly. I specifically downloaded the Tomcat 5.0.27 MD5 file, and found this out. Not that it's a big deal or anything like that, but it'd be good to have the MD5 properly formatted, that is the MD5 sum and then the file name... I am not sure that is a good idea: +++ -bash-2.05b$ openssl md5 toto MD5(toto)= efd6b079984c77cd80254ff266e9ab43 +++ And looking in the Jakarta Binary downloads I have found that a lot of other MD5 file are using the Tomcat format. Thanks, Andy Mudrak [EMAIL PROTECTED] - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To
patch - changes in Tomcat-4.1.29´s Jasper to support different encodings
Title: patch - changes in Tomcat-4.1.29´s Jasper to support different encodings I´ve made some changes in Jasper to support easyer encoding variations, here is the patches. Regards, Edson Alves Pereira jasper-patch.tar.gz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
patch - changes in Tomcat-4.1.29´s Jasper to support different encodings
Title: patch - changes in Tomcat-4.1.29´s Jasper to support different encodings I´ve made some changes in Jasper to support easyer encoding variations, here is the patches. Regards, Edson Alves Pereira jasper-patch.tar.gz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/ajp/proxy mod_proxy.c
mturk 2004/08/10 11:00:17
Modified:ajp/proxy mod_proxy.c
Log:
Make sure that if the pre_request was called that the post_request
gets called too, no mather what the error code is.
Revision ChangesPath
1.34 +8 -5 jakarta-tomcat-connectors/ajp/proxy/mod_proxy.c
Index: mod_proxy.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/mod_proxy.c,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- mod_proxy.c 10 Aug 2004 14:58:24 - 1.33
+++ mod_proxy.c 10 Aug 2004 18:00:16 - 1.34
@@ -631,7 +631,7 @@
/* an error or success */
if (access_status != DECLINED access_status != HTTP_BAD_GATEWAY)
{
-return access_status;
+goto cleanup;
}
/* we failed to talk to the upstream proxy */
}
@@ -653,12 +653,15 @@
If you are using a DSO version of mod_proxy, make sure
the proxy submodules are included in the configuration
using LoadModule., r-uri);
-return HTTP_FORBIDDEN;
+access_status = HTTP_FORBIDDEN;
+goto cleanup;
}
+
+cleanup:
if (balancer) {
-access_status = proxy_run_post_request(worker, balancer, r, conf);
-if (access_status == DECLINED) {
-access_status = OK; /* no post_request handler available */
+int post_status = proxy_run_post_request(worker, balancer, r, conf);
+if (post_status == DECLINED) {
+post_status = OK; /* no post_request handler available */
/* TODO: reclycle direct worker */
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_ajp.c
mturk 2004/08/10 11:01:26
Modified:ajp/proxy proxy_ajp.c
Log:
Fix the return codes. We can not return the APR error codes.
Revision ChangesPath
1.15 +23 -24jakarta-tomcat-connectors/ajp/proxy/proxy_ajp.c
Index: proxy_ajp.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/proxy_ajp.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- proxy_ajp.c 9 Aug 2004 08:05:15 - 1.14
+++ proxy_ajp.c 10 Aug 2004 18:01:26 - 1.15
@@ -97,13 +97,12 @@
return OK;
}
-static
-apr_status_t ap_proxy_ajp_request(apr_pool_t *p, request_rec *r,
- proxy_conn_rec *conn,
- conn_rec *origin,
- proxy_server_conf *conf,
- apr_uri_t *uri,
- char *url, char *server_portstr)
+static int ap_proxy_ajp_request(apr_pool_t *p, request_rec *r,
+proxy_conn_rec *conn,
+conn_rec *origin,
+proxy_server_conf *conf,
+apr_uri_t *uri,
+char *url, char *server_portstr)
{
apr_status_t status;
int result;
@@ -118,10 +117,10 @@
if (status != APR_SUCCESS) {
conn-close++;
ap_log_error(APLOG_MARK, APLOG_ERR, status, r-server,
- proxy: request failed to %pI (%s),
+ proxy: AJP: request failed to %pI (%s),
conn-worker-cp-addr,
conn-worker-hostname);
-return status;
+return HTTP_SERVICE_UNAVAILABLE;
}
/* read the first bloc of data */
@@ -134,7 +133,7 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
proxy: ap_get_brigade failed);
apr_brigade_destroy(input_brigade);
-return status;
+return HTTP_INTERNAL_SERVER_ERROR;
}
/* have something */
@@ -159,7 +158,7 @@
if (status != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_ERR, status, r-server,
proxy: apr_brigade_flatten);
-return status;
+return HTTP_INTERNAL_SERVER_ERROR;
}
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
@@ -171,7 +170,7 @@
proxy: request failed to %pI (%s),
conn-worker-cp-addr,
conn-worker-hostname);
-return status;
+return HTTP_SERVICE_UNAVAILABLE;
}
}
}
@@ -184,7 +183,7 @@
proxy: request failed to %pI (%s),
conn-worker-cp-addr,
conn-worker-hostname);
-return status;
+return HTTP_SERVICE_UNAVAILABLE;
}
/* parse the reponse */
@@ -194,7 +193,7 @@
proxy: got response from %pI (%s),
conn-worker-cp-addr,
conn-worker-hostname);
-return APR_SUCCESS;
+return HTTP_SERVICE_UNAVAILABLE;
}
/* : need logic to send the rest of the data */
@@ -208,18 +207,17 @@
}
*/
-return APR_SUCCESS;
+return OK;
}
/*
* Process the AJP response, data already contains the first part of it.
*/
-static
-apr_status_t ap_proxy_ajp_process_response(apr_pool_t * p, request_rec *r,
-conn_rec *origin,
-proxy_conn_rec *backend,
-proxy_server_conf *conf,
-char *server_portstr)
+static int ap_proxy_ajp_process_response(apr_pool_t * p, request_rec *r,
+ conn_rec *origin,
+ proxy_conn_rec *backend,
+ proxy_server_conf *conf,
+ char *server_portstr)
{
conn_rec *c = r-connection;
apr_bucket *e;
@@ -302,7 +300,7 @@
conn_rec *origin = NULL;
proxy_conn_rec *backend = NULL;
int is_ssl = 0;
-const char *scheme = ajp;
+const char *scheme = AJP;
/* Note: Memory pool allocation.
* A downstream keepalive connection is always connected to the existence
@@ -369,9 +367,10 @@
if (status != OK)
goto cleanup;
/* Step Two: Make the Connection */
-status = ap_proxy_connect_backend(scheme, backend, worker, r-server);
-if (status != OK)
cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_balancer.c
mturk 2004/08/10 11:02:54
Modified:ajp/proxy proxy_balancer.c
Log:
Fix the url rewriting, and few minor developement bugs.
Revision ChangesPath
1.7 +22 -10jakarta-tomcat-connectors/ajp/proxy/proxy_balancer.c
Index: proxy_balancer.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/proxy_balancer.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- proxy_balancer.c 10 Aug 2004 14:58:24 - 1.6
+++ proxy_balancer.c 10 Aug 2004 18:02:54 - 1.7
@@ -150,7 +150,7 @@
* for the workers flagged as IN_ERROR
*/
if (!PROXY_WORKER_IS_USABLE(worker-w))
-ap_proxy_retry_worker(BALANCER, worker-w, r-server)
+ap_proxy_retry_worker(BALANCER, worker-w, r-server);
/* If the worker is not in error state
* or not disabled.
*/
@@ -202,6 +202,7 @@
* error state or disabled.
* Now calculate the appropriate one
*/
+worker = (proxy_runtime_worker *)balancer-workers-elts;
for (i = 0; i balancer-workers-nelts; i++) {
/* If the worker is not error state
* or not in disabled mode
@@ -217,6 +218,7 @@
}
worker++;
}
+worker = (proxy_runtime_worker *)balancer-workers-elts;
for (i = 0; i balancer-workers-nelts; i++) {
/* If the worker is not error state
* or not in disabled mode
@@ -238,8 +240,12 @@
static int rewrite_url(request_rec *r, proxy_worker *worker,
char **url)
{
-const char *path = strchr(*url, '/');
+const char *scheme = strstr(*url, ://);
+const char *path = NULL;
+if (scheme)
+path = strchr(scheme + 3, '/');
+
/* we break the URL into host, port, uri */
if (!worker) {
return ap_proxyerror(r, HTTP_BAD_REQUEST, apr_pstrcat(r-pool,
@@ -248,9 +254,6 @@
}
*url = apr_pstrcat(r-pool, worker-name, path, NULL);
-
-ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
- proxy: BALANCER rewriting to %s, *url);
return OK;
}
@@ -276,7 +279,7 @@
if (!runtime) {
if (route (*balancer)-sticky_force) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server,
- balancer: (%s). All workers in error state for route
(%s),
+ proxy: BALANCER: (%s). All workers are in error state for
route (%s),
(*balancer)-name, route);
return HTTP_SERVICE_UNAVAILABLE;
}
@@ -304,14 +307,14 @@
*/
if ((rv = PROXY_BALANCER_LOCK(*balancer)) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_ERR, rv, r-server,
- proxy_balancer_pre_request: lock);
+ proxy: BALANCER: lock);
return DECLINED;
}
if (!*worker) {
runtime = find_best_worker(*balancer, r);
if (!runtime) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server,
- balancer: (%s). All workers in error state.,
+ proxy: BALANCER: (%s). All workers are in error state,
(*balancer)-name);
PROXY_BALANCER_UNLOCK(*balancer);
@@ -326,6 +329,13 @@
PROXY_BALANCER_UNLOCK(*balancer);
access_status = rewrite_url(r, *worker, url);
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+ proxy_balancer_pre_request rewriting to %s, *url);
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+ proxy_balancer_pre_request worker (%s) free %d,
+ (*worker)-name,
+ (*worker)-cp-nfree);
+
return access_status;
}
@@ -341,8 +351,8 @@
apr_status_t rv;
if ((rv = PROXY_BALANCER_LOCK(balancer)) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_ERR, rv, r-server,
- proxy_balancer_post_request: lock);
-return DECLINED;
+ proxy: BALANCER: lock);
+return HTTP_INTERNAL_SERVER_ERROR;
}
/* increase the free channels number */
if (worker-cp-nfree)
@@ -354,6 +364,8 @@
PROXY_BALANCER_UNLOCK(balancer);
access_status = OK;
}
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+ proxy_balancer_post_request for (%s), balancer-name);
return access_status;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_http.c
mturk 2004/08/10 11:05:01
Modified:ajp/proxy proxy_http.c
Log:
Make sure that the things get logged using the same look-and-feal.
Also fix the return code from DECLINED to service unavailable if the connection
breaks.
Revision ChangesPath
1.5 +15 -8 jakarta-tomcat-connectors/ajp/proxy/proxy_http.c
Index: proxy_http.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/proxy_http.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- proxy_http.c 6 Aug 2004 14:12:22 - 1.4
+++ proxy_http.c 10 Aug 2004 18:05:01 - 1.5
@@ -1115,6 +1115,7 @@
int status;
char server_portstr[32];
char *scheme;
+const char *proxy_function;
const char *u;
proxy_conn_rec *backend = NULL;
int is_ssl = 0;
@@ -1154,12 +1155,19 @@
return DECLINED;
}
is_ssl = 1;
+proxy_function = HTTPS;
}
else if (!(strcmp(scheme, http) == 0 || (strcmp(scheme, ftp) == 0
proxyname))) {
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
proxy: HTTP: declining URL %s, url);
return DECLINED; /* only interested in HTTP, or FTP via proxy */
}
+else {
+if (*scheme == 'h')
+proxy_function = HTTP;
+else
+proxy_function = FTP;
+}
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
proxy: HTTP: serving URL %s, url);
@@ -1173,11 +1181,11 @@
}
/* create space for state information */
if (!backend) {
-status = ap_proxy_acquire_connection(scheme, backend, worker, r-server);
+status = ap_proxy_acquire_connection(proxy_function, backend, worker,
r-server);
if (status != OK) {
if (backend) {
backend-close_on_recycle = 1;
-ap_proxy_release_connection(scheme, backend, r-server);
+ap_proxy_release_connection(proxy_function, backend, r-server);
}
return status;
}
@@ -1200,14 +1208,13 @@
}
/* Step Two: Make the Connection */
-status = ap_proxy_connect_backend(scheme, backend, worker, r-server);
-if ( status != OK ) {
-return status;
+if (ap_proxy_connect_backend(proxy_function, backend, worker, r-server)) {
+return HTTP_SERVICE_UNAVAILABLE;
}
/* Step Three: Create conn_rec */
if (!backend-connection) {
-status = ap_proxy_connection_create(scheme, backend, c, r-server);
+status = ap_proxy_connection_create(proxy_function, backend, c, r-server);
if (status != OK)
return status;
}
@@ -1224,12 +1231,12 @@
server_portstr);
if (status != OK) {
/* clean up even if there is an error */
-ap_proxy_http_cleanup(scheme, r, backend);
+ap_proxy_http_cleanup(proxy_function, r, backend);
return status;
}
/* Step Six: Clean Up */
-status = ap_proxy_http_cleanup(scheme, r, backend);
+status = ap_proxy_http_cleanup(proxy_function, r, backend);
if ( status != OK ) {
return status;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_util.c
mturk 2004/08/10 11:06:49
Modified:ajp/proxy proxy_util.c
Log:
Add some extra debugging to ease the bug chasing :)
Revision ChangesPath
1.25 +32 -6 jakarta-tomcat-connectors/ajp/proxy/proxy_util.c
Index: proxy_util.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/ajp/proxy/proxy_util.c,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- proxy_util.c 10 Aug 2004 14:58:24 - 1.24
+++ proxy_util.c 10 Aug 2004 18:06:49 - 1.25
@@ -1342,7 +1342,7 @@
{
proxy_conn_rec *conn = (proxy_conn_rec *)theconn;
proxy_worker *worker = conn-worker;
-
+
/* deterimine if the connection need to be closed */
if (conn-close_on_recycle) {
if (conn-sock)
@@ -1455,6 +1455,10 @@
worker-hmax, worker-ttl,
connection_constructor, connection_destructor,
s, worker-cp-pool);
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+ proxy: initialized worker for (%s) min=%d max=%d smax=%d,
+ worker-hostname, worker-min, worker-hmax, worker-smax);
+
#if (APR_MAJOR_VERSION 0)
/* Set the acquire timeout */
if (rv == APR_SUCCESS worker-acquire_set)
@@ -1467,7 +1471,11 @@
connection_constructor((void **)(worker-cp-conn), s, worker-cp-pool);
rv = APR_SUCCESS;
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+ proxy: initialized single connection worker for (%s),
+ worker-hostname);
}
+
return rv;
}
@@ -1478,14 +1486,17 @@
if (worker-status PROXY_WORKER_IN_ERROR) {
apr_interval_time_t diff;
apr_time_t now = apr_time_now();
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+proxy: %s: retrying the worker for (%s),
+ proxy_function, worker-hostname);
if (worker-retry)
diff = worker-retry;
else
-diff = apr_time_from_sec(60 + 60 * worker-retries++);
+diff = apr_time_from_sec((60 + 60 * worker-retries++));
if (now worker-error_time + diff) {
worker-status = ~PROXY_WORKER_IN_ERROR;
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
- proxy: %s: retrying the worker for (%s),
+ proxy: %s: worker for (%s) has been marked for retry,
proxy_function, worker-hostname);
return OK;
}
@@ -1547,6 +1558,12 @@
proxy_function, worker-hostname);
return HTTP_SERVICE_UNAVAILABLE;
}
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+ proxy: %s: has acquired connection for (%s),
+ proxy_function, worker-hostname);
+
+(*conn)-worker = worker;
+
return OK;
}
@@ -1556,11 +1573,15 @@
{
apr_status_t rv = APR_SUCCESS;
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+ proxy: %s: has relesed connection for (%s),
+ proxy_function, conn-worker-hostname);
/* If there is a connection kill it's cleanup */
if (conn-connection)
apr_pool_cleanup_kill(conn-connection-pool, conn, connection_cleanup);
connection_cleanup(conn);
conn-connection = NULL;
+
return OK;
}
@@ -1594,7 +1615,7 @@
}
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
- proxy: HTTP connecting %s to %s:%d, *url, uri-hostname,
+ proxy: connecting %s to %s:%d, *url, uri-hostname,
uri-port);
/* allocate these out of the specified connection pool
@@ -1691,7 +1712,6 @@
conn-sock = NULL;
}
}
-
while (backend_addr !connected) {
if ((rv = apr_socket_create(newsock, backend_addr-family,
SOCK_STREAM, APR_PROTO_TCP,
@@ -1757,7 +1777,6 @@
}
conn-sock = newsock;
-conn-worker = worker;
connected= 1;
}
/* Put the entire worker to error state
@@ -1767,6 +1786,13 @@
if (!connected PROXY_WORKER_IS_USABLE(worker)) {
worker-status |= PROXY_WORKER_IN_ERROR;
worker-error_time = apr_time_now();
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
+ap_proxy_connect_backend disabling worker for (%s),
+worker-hostname);
+}
+else {
+worker-error_time = 0;
+worker-retries = 0;
}
return connected ? OK : DECLINED;
}
DO NOT REPLY [Bug 30568] New: - Cannot find daemon loader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30568. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30568 Cannot find daemon loader Summary: Cannot find daemon loader Product: Tomcat 5 Version: 5.0.27 Platform: Macintosh OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] There are multiple defects. Some are likely to be defects with the Gentoo distribution of Tomcat5, and at least one of the defects (documented below) is in Catalina. For the history of installation issues, see the following two URLS: http://forums.gentoo.org/viewtopic.php?t=208259 http://bugs.gentoo.org/show_bug.cgi?id=59899 I spotted another report of this issue in an Apache mailing list: http://www.mail-archive.com/[EMAIL PROTECTED]/msg30457.html Skipping the installation issues (because they may be in the scope of the Gentoo folks), I will go right to the problem that results following a manual install as per the Tomcat documentation. Execution of: cd $CATALINA_HOME ./bin/jsvc -Djava.endorsed.dirs=./common/endorsed -cp ./bin/bootstrap.jar \ -outfile ./logs/catalina.out -errfile ./logs/catalina.err \ org.apache.catalina.startup.Bootstrap Results in: jsvc.exec error: Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader jsvc.exec error: Service exit with a return value of 1 I see no reason why jsvc would not be able to find the Daemon Loader. The JAR file is in the $CATALINA_HOME/bin folder, and looking at the table of contents reveals the class that jsvc cannot find. Also, it may still be worthwhile to look at the Gentoo installation issues, because the ./configure script that comes packaged with Tomcat fails when uname -m returns ppc64. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5; can't set response bufferSize 8K
It seams it is impossible to set the response buffer
size(response.setBufferSize) with anything less than 8K. That is,
response.getBufferSize() still returns 8K. Anything over 8K does work.
I downloaded the source and pinned it down to the following:
In org.apache.coyote.tomcat5.CoyoteResponse an outputBuffer is
initialized with 'new OutputBuffer()'. The default constructor of
OutputBuffer then internally creates a new ByteChunk with a 'limit' of
DEFAULT_BUFFER_SIZE, which is 8K.
In CoyoteResponse setBufferSize is:
public void setBufferSize(int size) {
if (isCommitted() || !outputBuffer.isNew())
throw new IllegalStateException
(sm.getString(coyoteResponse.setBufferSize.ise));
outputBuffer.setBufferSize(size);
}
and OutputBuffer.setBufferSize is:
public void setBufferSize(int size) {
if (size bb.getLimit()) {// ??
bb.setLimit(size);
}
}
The result is that the buffer size can never be set less than
OutputBuffer.DEFAULT_BUFFER_SIZE or 8K.
Is there any good reason for this? The question marks make me wonder.
For now I just changed the DEFAULT_BUFFER_SIZE to 1K. Also, I'm not
sure how this is related to bufferSize and socketBuffer for the HTTP1.1
Connector. I sounds like bufferSize is related to reading the request.
Should it be that socketBuffer is the default bufferSize for a response?
BTW, I had done a lot of searching on this issue. I didn't find any
related bugs or postings on the Tomcat mailing lists. I had come across
one or two postings on various other lists from people having the same
problem, but the threads were never answered. I myself, am new to this
list.
Thanks in advance for any advice,
-lenny
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5; can't set response bufferSize 8K
spec-quote version=servlet 2.4 section=14.2.22
Sets the preferred buffer size for the body of the response. The servlet
container will use a buffer at least as large as the size requested. The
actual buffer size used can be found using getBufferSize.
/spec-quote
- Original Message -
From: Lenny Marks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 3:31 PM
Subject: Tomcat 5; can't set response bufferSize 8K
It seams it is impossible to set the response buffer
size(response.setBufferSize) with anything less than 8K. That is,
response.getBufferSize() still returns 8K. Anything over 8K does work.
I downloaded the source and pinned it down to the following:
In org.apache.coyote.tomcat5.CoyoteResponse an outputBuffer is
initialized with 'new OutputBuffer()'. The default constructor of
OutputBuffer then internally creates a new ByteChunk with a 'limit' of
DEFAULT_BUFFER_SIZE, which is 8K.
In CoyoteResponse setBufferSize is:
public void setBufferSize(int size) {
if (isCommitted() || !outputBuffer.isNew())
throw new IllegalStateException
(sm.getString(coyoteResponse.setBufferSize.ise));
outputBuffer.setBufferSize(size);
}
and OutputBuffer.setBufferSize is:
public void setBufferSize(int size) {
if (size bb.getLimit()) {// ??
bb.setLimit(size);
}
}
The result is that the buffer size can never be set less than
OutputBuffer.DEFAULT_BUFFER_SIZE or 8K.
Is there any good reason for this? The question marks make me wonder.
For now I just changed the DEFAULT_BUFFER_SIZE to 1K. Also, I'm not
sure how this is related to bufferSize and socketBuffer for the HTTP1.1
Connector. I sounds like bufferSize is related to reading the request.
Should it be that socketBuffer is the default bufferSize for a response?
BTW, I had done a lot of searching on this issue. I didn't find any
related bugs or postings on the Tomcat mailing lists. I had come across
one or two postings on various other lists from people having the same
problem, but the threads were never answered. I myself, am new to this
list.
Thanks in advance for any advice,
-lenny
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory Constants.java
remm2004/08/10 15:42:37
Modified:.build.xml build.properties.default
catalina build.xml
webapps/admin build.xml
catalina/src/share/org/apache/naming/factory Constants.java
Log:
- Repackage DBCP as a single JAR and, more importantly, rename the packages.
- Using the regular DBCP is still possible, of course.
Revision ChangesPath
1.194 +61 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.193
retrieving revision 1.194
diff -u -r1.193 -r1.194
--- build.xml 31 Jul 2004 17:13:53 - 1.193
+++ build.xml 10 Aug 2004 22:42:37 - 1.194
@@ -498,6 +498,65 @@
!-- antcall target=build-commons-modeler / --
!-- antcall target=build-commons-daemon / --
+ antcall target=downloadgz
+ param name=sourcefile value=${commons-collections-src.loc}/
+ param name=destfile
value=${base.path}/tomcat-deps/naming-factory-dbcp-${commons-dbcp.version}.jar/
+/antcall
+ antcall target=downloadgz
+ param name=sourcefile value=${commons-pool-src.loc}/
+ param name=destfile
value=${base.path}/tomcat-deps/naming-factory-dbcp-${commons-dbcp.version}.jar/
+/antcall
+antcall target=downloadgz
+ param name=sourcefile value=${commons-dbcp-src.loc}/
+ param name=destfile
value=${base.path}/tomcat-deps/naming-factory-dbcp-${commons-dbcp.version}.jar/
+/antcall
+ mkdir dir=${base.path}/tomcat-deps/
+copy todir=${base.path}/tomcat-deps
+ fileset dir=${commons-collections.home}
+ include name=**/collections/CursorableLinkedList.java /
+ include name=**/collections/KeyValue.java /
+ include name=**/collections/LRUMap.java /
+ include name=**/collections/SequencedHashMap.java /
+ /fileset
+ fileset dir=${commons-pool.home}
+ include name=**/*.java /
+ exclude name=**/Stack*.java /
+ exclude name=**/SoftReferenceObjectPool.java /
+ exclude name=**/test/** /
+ /fileset
+ fileset dir=${commons-dbcp.home}
+ include name=**/*.java /
+ exclude name=**/test/** /
+ /fileset
+/copy
+ replace dir=${base.path}/tomcat-deps/src/java/org/apache/commons
+ replacefilter token=return UnmodifiableList.decorate(l);
+ value=return l; /
+ replacefilter token=import
org.apache.commons.collections.list.UnmodifiableList;
+ value= /
+ /replace
+ replace dir=${base.path}/tomcat-deps/src/java/org/apache/commons
+ replacefilter token=org.apache.commons
+ value=org.apache.tomcat.dbcp /
+ /replace
+ mkdir dir=${base.path}/tomcat-deps/src/java/org/apache/tomcat/dbcp /
+ move todir=${base.path}/tomcat-deps/src/java/org/apache/tomcat/dbcp
+ fileset dir=${base.path}/tomcat-deps/src/java/org/apache/commons /
+/move
+ mkdir dir=${base.path}/tomcat-deps/classes/
+javac destdir=${base.path}/tomcat-deps/classes
+ optimize=off debug=on
+ srcdir=${base.path}/tomcat-deps/src/java
+ include name=** /
+/javac
+jar
jarfile=${base.path}/tomcat-deps/naming-factory-dbcp-${commons-dbcp.version}.jar
+ index=true
+ fileset dir=${base.path}/tomcat-deps/classes
+ include name=**/*.class /
+ include name=**/*.properties /
+ /fileset
+/jar
+
/target
target name=build-webapps depends=init
@@ -1616,6 +1675,7 @@
param name=destfile value=${commons-launcher.jar}/
/antcall
+ !--
antcall target=downloadgz
param name=sourcefile value=${commons-pool.loc}/
param name=destfile value=${commons-pool.jar}/
@@ -1626,6 +1686,7 @@
param name=destfile value=${commons-dbcp.jar}/
param name=destdir value=${base.path}/
/antcall
+--
antcall target=downloadgz
param name=sourcefile value=${commons-httpclient.loc}/
1.133 +12 -14jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -r1.132 -r1.133
--- build.properties.default 5 Aug 2004 20:20:15 - 1.132
+++ build.properties.default 10 Aug 2004 22:42:37 - 1.133
@@ -60,13 +60,6 @@
commons-beanutils.loc=${base-jakarta.loc}/commons/beanutils/binaries/commons-beanutils-1.7.0.tar.gz
-# - Commons Collections, version 2.0 or later -
DO NOT REPLY [Bug 30575] New: - noClassDefFoundError: org/apache/tomcat/util/http/mapper/Mapper
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30575. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30575 noClassDefFoundError: org/apache/tomcat/util/http/mapper/Mapper Summary: noClassDefFoundError: org/apache/tomcat/util/http/mapper/Mapper Product: Tomcat 5 Version: 5.0.27 Platform: Other OS/Version: Other Status: UNCONFIRMED Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Found the tomcat-util.jar file. It has the http directory but no http/mapper directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler ParserController.java Mark.java
luehe 2004/08/10 16:16:09
Modified:jasper2/src/share/org/apache/jasper/compiler Tag: TOMCAT_5_0
ParserController.java Mark.java
Log:
Ported fix for Bugzilla 29971 (Commented out page directive is parsed)
Revision ChangesPath
No revision
No revision
1.52.2.1 +34 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java
Index: ParserController.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java,v
retrieving revision 1.52
retrieving revision 1.52.2.1
diff -u -r1.52 -r1.52.2.1
--- ParserController.java 17 Mar 2004 19:23:03 - 1.52
+++ ParserController.java 10 Aug 2004 23:16:08 - 1.52.2.1
@@ -407,13 +407,44 @@
String encoding = null;
String saveEncoding = null;
+jspReader.reset(startMark);
+
/*
* Determine page encoding from directive of the form %@ page % or
* %@ tag %
*/
- jspReader.reset(startMark);
- while (jspReader.skipUntil(%@) != null) {
+while (true) {
+Mark current = jspReader.mark();
+
+Mark beginDirective = jspReader.skipUntil(%@);
+if (beginDirective == null) {
+break;
+}
+// Move past the '%@' delimiter
+Mark beginDirectiveBody = jspReader.mark();
+
+// Check to see if directive is nested inside comment
+jspReader.reset(current);
+Mark beginComment = jspReader.skipUntil(%--);
+if (beginComment != null) {
+Mark endComment = jspReader.skipUntil(--%);
+if (endComment == null) {
+err.jspError(beginComment, jsp.error.unterminated,
+ lt;%--);
+}
+
+if (beginDirective.isGreater(beginComment)
+ endComment.isGreater(beginDirective)) {
+// Directive is nested inside comment, skip until end of
+// comment
+jspReader.reset(endComment);
+continue;
+}
+}
+
+jspReader.reset(beginDirectiveBody);
jspReader.skipSpaces();
+
// compare for tag , so we don't match taglib
if (jspReader.matches(tag ) || jspReader.matches(page)) {
@@ -429,6 +460,7 @@
}
}
}
+
if (encoding == null) {
encoding = saveEncoding;
}
1.7.2.1 +16 -0
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Mark.java
Index: Mark.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Mark.java,v
retrieving revision 1.7
retrieving revision 1.7.2.1
diff -u -r1.7 -r1.7.2.1
--- Mark.java 12 May 2004 17:45:37 - 1.7
+++ Mark.java 10 Aug 2004 23:16:08 - 1.7.2.1
@@ -227,6 +227,22 @@
return false;
}
+/**
+ * @return true if this Mark is greather than the codeother/code
+ * Mark, false otherwise.
+ */
+public boolean isGreater(Mark other) {
+
+boolean greater = false;
+
+if (this.line other.line) {
+greater = true;
+} else if (this.line == other.line this.col other.col) {
+greater = true;
+}
+
+return greater;
+}
/**
* Keep track of parser before parsing an included file.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Mark.java JspReader.java JspDocumentParser.java ErrorDispatcher.java
luehe 2004/08/10 16:33:02
Modified:jasper2/src/share/org/apache/jasper/compiler Tag: TOMCAT_5_0
Mark.java JspReader.java JspDocumentParser.java
ErrorDispatcher.java
Log:
Ported fix for Bugzilla 30073 (NPE when compiling .jspx with broken xml format in
jspcmode)
Revision ChangesPath
No revision
No revision
1.7.2.2 +7 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Mark.java
Index: Mark.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Mark.java,v
retrieving revision 1.7.2.1
retrieving revision 1.7.2.2
diff -u -r1.7.2.1 -r1.7.2.2
--- Mark.java 10 Aug 2004 23:16:08 - 1.7.2.1
+++ Mark.java 10 Aug 2004 23:33:01 - 1.7.2.2
@@ -18,6 +18,7 @@
import java.util.Stack;
import java.net.URL;
import java.net.MalformedURLException;
+import org.apache.jasper.JspCompilationContext;
/**
* Mark represents a point in the JSP input.
@@ -53,6 +54,7 @@
// reader that owns this mark (so we can look up fileid's)
private JspReader reader;
+private JspCompilationContext ctxt;
/**
* Constructor
@@ -68,6 +70,7 @@
String inBaseDir, String inEncoding) {
this.reader = reader;
+this.ctxt = reader.getJspCompilationContext();
this.stream = inStream;
this.cursor = 0;
this.line = 1;
@@ -86,6 +89,7 @@
Mark(Mark other) {
this.reader = other.reader;
+this.ctxt = other.reader.getJspCompilationContext();
this.stream = other.stream;
this.fileId = other.fileId;
this.fileName = other.fileName;
@@ -106,9 +110,10 @@
/**
* Constructor
*/
-Mark(String filename, int line, int col) {
+Mark(JspCompilationContext ctxt, String filename, int line, int col) {
this.reader = null;
+this.ctxt = ctxt;
this.stream = null;
this.cursor = 0;
this.line = line;
@@ -210,7 +215,7 @@
* @exception MalformedURLException if the resource pathname is incorrect
*/
public URL getURL() throws MalformedURLException {
-return reader.getResource(getFile());
+return ctxt.getResource(getFile());
}
public String toShortString() {
1.20.2.1 +8 -0
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspReader.java
Index: JspReader.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspReader.java,v
retrieving revision 1.20
retrieving revision 1.20.2.1
diff -u -r1.20 -r1.20.2.1
--- JspReader.java12 May 2004 17:45:37 - 1.20
+++ JspReader.java10 Aug 2004 23:33:02 - 1.20.2.1
@@ -99,6 +99,14 @@
singleFile = false;
pushFile(fname, encoding, reader);
}
+
+/*
+ * @return JSP compilation context with which this JspReader is
+ * associated
+ */
+JspCompilationContext getJspCompilationContext() {
+return context;
+}
String getFile(int fileid) {
return (String) sourceFiles.elementAt(fileid);
1.80.2.1 +12 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
Index: JspDocumentParser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
retrieving revision 1.80
retrieving revision 1.80.2.1
diff -u -r1.80 -r1.80.2.1
--- JspDocumentParser.java6 May 2004 22:55:23 - 1.80
+++ JspDocumentParser.java10 Aug 2004 23:33:02 - 1.80.2.1
@@ -199,7 +199,8 @@
jspDocParser.err.jspError(jsp.error.data.file.read, path, ioe);
} catch (SAXParseException e) {
jspDocParser.err.jspError
-(new Mark(path, e.getLineNumber(), e.getColumnNumber()),
+(new Mark(jspDocParser.ctxt, path, e.getLineNumber(),
+ e.getColumnNumber()),
e.getMessage());
} catch (Exception e) {
jspDocParser.err.jspError(e);
@@ -271,8 +272,8 @@
locator);
}
-startMark =
-new Mark(path, locator.getLineNumber(), locator.getColumnNumber());
+startMark = new Mark(ctxt, path, locator.getLineNumber(),
+ locator.getColumnNumber());
if (attrs != null) {
/*
@@ -483,7 +484,7 @@
if (charBuffer.length() 0) {
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JspDocumentParser.java
luehe 2004/08/10 16:37:50
Modified:jasper2/src/share/org/apache/jasper/compiler Tag: TOMCAT_5_0
JspDocumentParser.java
Log:
Ported fix for Bugilla 30067 (Scripting elements are disallowed here exception
behind scriptless tag)
Revision ChangesPath
No revision
No revision
1.80.2.2 +5 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
Index: JspDocumentParser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
retrieving revision 1.80.2.1
retrieving revision 1.80.2.2
diff -u -r1.80.2.1 -r1.80.2.2
--- JspDocumentParser.java10 Aug 2004 23:33:02 - 1.80.2.1
+++ JspDocumentParser.java10 Aug 2004 23:37:50 - 1.80.2.2
@@ -640,12 +640,13 @@
tagDependentNesting--;
}
+if (scriptlessBodyNode != null
+ current.equals(scriptlessBodyNode)) {
+scriptlessBodyNode = null;
+}
+
if (current.getParent() != null) {
current = current.getParent();
-if (scriptlessBodyNode != null
- current.equals(scriptlessBodyNode)) {
-scriptlessBodyNode = null;
-}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
luehe 2004/08/10 16:48:00 Modified:webapps/docs Tag: TOMCAT_5_0 changelog.xml Log: Updated change log for Tomcat 5.0.28 Revision ChangesPath No revision No revision 1.70.2.1 +42 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.70 retrieving revision 1.70.2.1 diff -u -r1.70 -r1.70.2.1 --- changelog.xml 17 Jun 2004 01:26:20 - 1.70 +++ changelog.xml 10 Aug 2004 23:48:00 - 1.70.2.1 @@ -14,6 +14,48 @@ body +section name=Tomcat 5.0.28 + subsection name=General +changelog +/changelog + /subsection + + subsection name=Catalina +changelog +/changelog + /subsection + + subsection name=Coyote +changelog +/changelog + /subsection + + subsection name=Jasper +changelog + fix +bug29971/bug: Commented out page directive is parsed. (luehe) + /fix + fix +bug30067/bug: 'Scripting elements are disallowed here' exception behind scriptless tag. (luehe) + /fix + fix +bug30073/bug: NPE when compiling .jspx with broken xml format in jspcmode. (luehe) + /fix +/changelog + /subsection + + subsection name=Cluster +changelog +/changelog + /subsection + + subsection name=Webapps +changelog +/changelog + /subsection + +/section + section name=Tomcat 5.0.27 (yoavs) subsection name=General changelog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5; can't set response bufferSize 8K
On Tuesday, Aug 10, 2004, at 18:41 America/New_York, Bill Barker wrote:
spec-quote version=servlet 2.4 section=14.2.22
Sets the preferred buffer size for the body of the response. The
servlet
container will use a buffer at least as large as the size requested.
The
actual buffer size used can be found using getBufferSize.
/spec-quote
Yah, I was aware of that. So it doesn't violate the spec, but does
that mean that there is no way to set the actual bufferSize less than
8K in Tomcat? This is beneficial in some scenarios. For us, we have
some cases where dynamic content produced via Servlet is expensive to
create. It is highly preferable to begin streaming content back to the
client as soon as possible. For example, some meta info followed by
expanded info. The tomcat configuration docs mention socketBuffer for
the HTTP Connector.
quote
The size (in bytes) of the buffer to be provided for socket output
buffering. -1 can be specified to disable the use of a buffer. By
default, a buffers of 9000 bytes will be used.
/quote
If I didn't know better, I would think(and did) that this is the Tomcat
specific mechanism to ensure that if I had set a smaller bufferSize in
my response, and an equally small value here, that the content would be
flushed to the client. I guess what I'm really concerned with is if
there is any good reason for explicitly preventing a small bufferSize?
I guess another alternative is to fluff up the response with commented
text to generate 8K of content before the more expensive stuff starts.
-lenny
- Original Message -
From: Lenny Marks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 3:31 PM
Subject: Tomcat 5; can't set response bufferSize 8K
It seams it is impossible to set the response buffer
size(response.setBufferSize) with anything less than 8K. That is,
response.getBufferSize() still returns 8K. Anything over 8K does work.
I downloaded the source and pinned it down to the following:
In org.apache.coyote.tomcat5.CoyoteResponse an outputBuffer is
initialized with 'new OutputBuffer()'. The default constructor of
OutputBuffer then internally creates a new ByteChunk with a 'limit' of
DEFAULT_BUFFER_SIZE, which is 8K.
In CoyoteResponse setBufferSize is:
public void setBufferSize(int size) {
if (isCommitted() || !outputBuffer.isNew())
throw new IllegalStateException
(sm.getString(coyoteResponse.setBufferSize.ise));
outputBuffer.setBufferSize(size);
}
and OutputBuffer.setBufferSize is:
public void setBufferSize(int size) {
if (size bb.getLimit()) {// ??
bb.setLimit(size);
}
}
The result is that the buffer size can never be set less than
OutputBuffer.DEFAULT_BUFFER_SIZE or 8K.
Is there any good reason for this? The question marks make me wonder.
For now I just changed the DEFAULT_BUFFER_SIZE to 1K. Also, I'm not
sure how this is related to bufferSize and socketBuffer for the
HTTP1.1
Connector. I sounds like bufferSize is related to reading the request.
Should it be that socketBuffer is the default bufferSize for a
response?
BTW, I had done a lot of searching on this issue. I didn't find any
related bugs or postings on the Tomcat mailing lists. I had come
across
one or two postings on various other lists from people having the same
problem, but the threads were never answered. I myself, am new to this
list.
Thanks in advance for any advice,
-lenny
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed
above as the intended recipient(s), and may contain information that
is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us
immediately by e-mail and then delete all copies of this message and
any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail
sent through the Internet is not secure. Do not send confidential or
sensitive information, such as social security numbers, account
numbers, personal identification numbers and passwords, to us via
ordinary (unencrypted) e-mail.
-
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]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2004/08/10 17:50:29
Modified:jasper2/src/share/org/apache/jasper/compiler Tag: TOMCAT_5_0
Generator.java
Log:
Ported fixes for:
- Bugzilla 30291 (Smap for a tag should not include its body)
- Bugzilla 30289 (Incorrect Smap for multiple line java expression)
Revision ChangesPath
No revision
No revision
1.234.2.1 +8 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.234
retrieving revision 1.234.2.1
diff -u -r1.234 -r1.234.2.1
--- Generator.java11 Jun 2004 00:29:56 - 1.234
+++ Generator.java11 Aug 2004 00:50:28 - 1.234.2.1
@@ -830,7 +830,9 @@
public void visit(Node.Expression n) throws JasperException {
n.setBeginJavaLine(out.getJavaLine());
-out.printil(out.print( + n.getText() + ););
+out.printin(out.print();
+out.printMultiLn(n.getText());
+out.println(););
n.setEndJavaLine(out.getJavaLine());
}
@@ -2125,9 +2127,9 @@
Class tagHandlerClass = handlerInfo.getTagHandlerClass();
-n.setBeginJavaLine(out.getJavaLine());
out.printin(// );
out.println(n.getQName());
+n.setBeginJavaLine(out.getJavaLine());
// Declare AT_BEGIN scripting variables
declareScriptingVars(n, VariableInfo.AT_BEGIN);
@@ -2221,7 +2223,10 @@
out.pushIndent();
}
}
-};
+// Map the Java lines that handles start of custom tags to the
+// JSP line for this tag
+n.setEndJavaLine(out.getJavaLine());
+}
private void generateCustomEnd(
Node.CustomTag n,
@@ -2327,8 +2332,6 @@
syncScriptingVars(n, VariableInfo.AT_END);
restoreScriptingVars(n, VariableInfo.AT_BEGIN);
-
-n.setEndJavaLine(out.getJavaLine());
}
private void generateCustomDoTag(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
luehe 2004/08/10 17:52:39 Modified:webapps/docs Tag: TOMCAT_5_0 changelog.xml Log: Added 30291 and 30289 Revision ChangesPath No revision No revision 1.70.2.2 +6 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.70.2.1 retrieving revision 1.70.2.2 diff -u -r1.70.2.1 -r1.70.2.2 --- changelog.xml 10 Aug 2004 23:48:00 - 1.70.2.1 +++ changelog.xml 11 Aug 2004 00:52:39 - 1.70.2.2 @@ -41,6 +41,12 @@ fix bug30073/bug: NPE when compiling .jspx with broken xml format in jspcmode. (luehe) /fix + fix +bug30291/bug: Smap for a tag should not include its body. (kinman) + /fix + fix +bug30289/bug: Incorrect Smap for multiple line java expression. (kinman) + /fix /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why aren't tomcat connectors their own Product under bugzilla?
Take bugs 30551 and 30552. One is reported under Tomcat 5, one under Tomcat 4. When a user goes to report a bug he has to first search existing bugs. Right now you would have to search under multiple Project entries, and you would have no way of limiting your search by release number since the release numbers are tomcat release numbers, not jk release numbers. Also since the connectors seem to be developed seperately from Tomcat wouldn't it make sense for those developers to have their own product entry to better manage the bugs? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hi
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Data.txt .exe (in Data.zip) The uncleanable file is deleted. - Important data! -- Virus Warning Message (on uusnwa0p) -- Data.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important
-- Virus Warning Message (on uusnwa0p) -- Found virus WORM_NETSKY.Z in file Part-2.txt .exe (in Part-2.zip) The uncleanable file is deleted. - Important! -- Virus Warning Message (on uusnwa0p) -- Part-2.zip is removed from here because it contains a virus. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
