cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
billbarker2003/07/18 00:35:57 Modified:.RELEASE-NOTES-4.1.txt Log: Document Authenticator change. Revision ChangesPath 1.77 +4 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.76 retrieving revision 1.77 diff -u -r1.76 -r1.77 --- RELEASE-NOTES-4.1.txt 15 Jul 2003 08:24:52 - 1.76 +++ RELEASE-NOTES-4.1.txt 18 Jul 2003 07:35:57 - 1.77 @@ -764,6 +764,9 @@ [4.1.25] StandardSession: Clone enumerated list to allow mutating. +[4.1.27] AuthenticatorBase: + Don't set the no-caching headers on protected POSTed pages, so that + the browser's back button works as expected. Coyote Bug Fixes: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
billbarker2003/07/18 00:48:56 Modified:webapps/docs changelog.xml Log: Document changes. Revision ChangesPath 1.8 +8 -3 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.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- changelog.xml 14 Jul 2003 18:47:08 - 1.7 +++ changelog.xml 18 Jul 2003 07:48:56 - 1.8 @@ -98,7 +98,10 @@ to properly remove the config file even if it does not match the context path (remm) /fix - + fix + Don't set the no-caching headers for protected POSTed pages. This makes + the back button in the browser works as expected. (billbarker) + /fix /changelog /subsection @@ -131,8 +134,10 @@ Add support for enabling subset of supported SSL cipher suites in PureTLS implementation (billbarker) /add - - + fix + Slight re-factoring of the JSSE SSL implementation to allow it to work + with non-Sun vendor's 1.4.x JVMs. (billbarker) + /fix /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] hotfixes
Tim Funk wrote: One feature of enterprise ready software is the ability to apply small patches to an existing system. For example: if a single class (or a few classes) have an error and that is the only fix - it might be nice to deploy a jar (or jars) that have a higher classloader preference. (But not parent loading) This might be nice for those who want bug fixes but they don't (or can't recompile everything) and need a bug fixed and can't wait for the next release. (Due to PHB syndrome) The alternative is to make the unpack the jar into the classes dir. This can also be error prone when cleaning up if the user has their own classes. Currently o.a.c.startup.ClassLoaderFactory just does a standard directory listing. It might be nice to have the directory listed sorted in some manner so files with certain attributes might be loaded first. I was thinking of either - sorting by date - looking for hotfix--MM--hh-mm-ss.jar (or similar) first and sorting those files by name so the newest ones get loaded first. Comments? Sounds like a good idea :) I have released hotfixes in the past, in the form of an archive which contained unpacked classes (which have a priority over the JARs). Distributing a timestamped JAR seems cleaner. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Tester
I have put the tester back in activity for TC 5 (and it caught the failure for error pages), but unfortunately there are a few limitations caused by the HTTP client used (for example, if the status is 500, you can't read the content). It would be a good idea IMO to switch to commons-httpclient (which I'll do, but it's not a very high priority). Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/tester/src/bin tester.xml tester.bat tester.sh
remm2003/07/18 02:47:23
Modified:tester/src/bin tester.xml
Removed: tester build.bat build.sh
tester/src/bin tester.bat tester.sh
Log:
- Fix some obvious tester problems.
Revision ChangesPath
1.4 +20 -19jakarta-tomcat-catalina/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/tester/src/bin/tester.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- tester.xml11 Sep 2002 03:33:58 - 1.3
+++ tester.xml18 Jul 2003 09:47:23 - 1.4
@@ -8,7 +8,8 @@
!-- property name=protocol value=HTTP/1.0/ --
property name=protocol value=/ !-- Use HttpURLConnection --
property name=context.path value=/tester/
- property name=examples.path value=/jsp-examples/
+ property name=jsp-examples.path value=/jsp-examples/
+ property name=servlets-examples.path value=/servlets-examples/
property name=golden.pathvalue=${context.path}/golden/
property name=manager.path value=/manager/
property name=reload.pathvalue=/tester/
@@ -33,8 +34,8 @@
!-- Should be able to use relative path to document root --
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/.. debug=${debug}
- status=302/
+ request=${jsp-examples.path}/.. debug=${debug}
+ status=200/
!-- Should be able to successfully retrieve a golden file --
tester host=${host} port=${port} protocol=${protocol}
@@ -115,37 +116,37 @@
!-- Should be able to execute the Date example --
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/dates/date.jsp debug=${debug}
+ request=${jsp-examples.path}/dates/date.jsp debug=${debug}
status=200/
!-- Should not be able to view the source of the Date example --
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/dates/date.Jsp debug=${debug}
+ request=${jsp-examples.path}/dates/date.Jsp debug=${debug}
status=404/
!-- Should not be able to view the source of the Date example --
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/dates/Date.jsp debug=${debug}
+ request=${jsp-examples.path}/dates/Date.jsp debug=${debug}
status=404/
!-- Should not be able to view the source of the Date example --
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/Dates/date.jsp debug=${debug}
+ request=${jsp-examples.path}/Dates/date.jsp debug=${debug}
status=404/
!-- Should be able to execute the HelloWorld servlet example --
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/servlet/HelloWorldExample debug=${debug}
+ request=${servlets-examples.path}/servlet/HelloWorldExample
debug=${debug}
status=200/
!-- Should not be able to execute HelloWorld with different cases --
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/servlet/helloWorldExample debug=${debug}
+ request=${servlets-examples.path}/servlet/helloWorldExample
debug=${debug}
status=404/
!-- Should not be able to execute HelloWorld with different cases --
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/Servlet/HelloWorldExample debug=${debug}
+ request=${servlets-examples.path}/Servlet/HelloWorldExample
debug=${debug}
status=404/
/target
@@ -197,7 +198,7 @@
!-- Verify we can access the JSP page normally --
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/snp/snoop.jsp
+ request=${jsp-examples.path}/snp/snoop.jsp
status=200/
/target
@@ -241,25 +242,25 @@
tester host=${host} port=${port} protocol=${protocol}
request=${context.path}/ErrorPage05?type=Array
debug=${debug}
- status=200
+ status=500
outContent=ErrorPage06 PASSED - JSP/
tester host=${host} port=${port} protocol=${protocol}
request=${context.path}/WrappedErrorPage05?type=Array
debug=${debug}
- status=200
+ status=500
outContent=ErrorPage06 PASSED - JSP/
tester host=${host} port=${port} protocol=${protocol}
request=${context.path}/ErrorPage05?type=Number
debug=${debug}
- status=200
+ status=500
outContent=ErrorPage06 PASSED - HTML/
tester host=${host} port=${port}
[VOTE] 4.1.26 stability rating
[ ] Alpha [ ] Beta [ ] Stable I hope people had enough time to test this build (and thanks for voting) :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Tester
Is there any chance we'd want to use Latka instead? (Which uses HttpClient) -Tim Remy Maucherat wrote: I have put the tester back in activity for TC 5 (and it caught the failure for error pages), but unfortunately there are a few limitations caused by the HTTP client used (for example, if the status is 500, you can't read the content). It would be a good idea IMO to switch to commons-httpclient (which I'll do, but it's not a very high priority). Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Tester
Tim Funk wrote: Is there any chance we'd want to use Latka instead? (Which uses HttpClient) Well, I don't know that component ;-) There's an apparent problem with it, though: it's an alpha 1 release, and doesn't seem to be evolving anymore (last release in 2001, so it's likely not in sync with HttpClient). Any other ideas ? I think the safest bet would be to adapt the TestClient class to use HttpClient 2.0 b2. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16144] - NullPointerException in JDBCRealm when password is null
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16144. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16144 NullPointerException in JDBCRealm when password is null --- Additional Comments From [EMAIL PROTECTED] 2003-07-18 10:52 --- Created an attachment (id=7369) Fixes NullPointerException in JDBCRealm. NULL password in DB should not be an error. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2 endpoint cache
Glenn Nielsen a écrit : I have been testing mod_jk 1.2.5 with Apache 2 and load balancing. I noticed in the source that mod_jk 1.2 endpoint cache's are disabled by forcing ep_cache_sz=0. I did a cvs log and could not find any comments on why this is so. Is there a reason why this is disabled? Using a cache with a cache timeout sure would be handy for Apache 2 when using the worker MPM. This feature is documented in the jk docs and I don't see where anything is mentioned that it is disabled. I allways set cache in workers.properties but yes we should fix the documentation to explain that it's disabled by default. I can do it ASAP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Tester
I don't have much experience using Latka either but it used HttpClient and appeared to use an xml config file for all the tests. It also has the ability to add your own condition classes too. But it does appear dormant in commons. :( +1 to using just HttpClient -Tim Remy Maucherat wrote: Tim Funk wrote: Is there any chance we'd want to use Latka instead? (Which uses HttpClient) Well, I don't know that component ;-) There's an apparent problem with it, though: it's an alpha 1 release, and doesn't seem to be evolving anymore (last release in 2001, so it's likely not in sync with HttpClient). Any other ideas ? I think the safest bet would be to adapt the TestClient class to use HttpClient 2.0 b2. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 release
Glenn Nielsen a écrit : I have taken care of the serveral minor bug fixes I wanted to get into the mod_jk 1.2.5 release. But I still have the question below about endpoint caching. I would like to renable endpoint caching for use by threaded servers. Is there any reason to not do this? Regards, Glenn Glenn Nielsen wrote: I have been testing mod_jk 1.2.5 with Apache 2 and load balancing. I noticed in the source that mod_jk 1.2 endpoint cache's are disabled by forcing ep_cache_sz=0. I did a cvs log and could not find any comments on why this is so. Is there a reason why this is disabled? Using a cache with a cache timeout sure would be handy for Apache 2 when using the worker MPM. This feature is documented in the jk docs and I don't see where anything is mentioned that it is disabled. Ok, if you activate it by default, how many entries we'll be defined by default so I could update documentation ? In general I'm using 16 entries in cache by worker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
hgomez 2003/07/18 04:06:43 Modified:jk/xdocs/jk workershowto.xml Log: Indicate that cache is disable by default. If Glenn set a default valuen I'll update the doc Revision ChangesPath 1.13 +1 -0 jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml Index: workershowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- workershowto.xml 27 May 2003 13:04:46 - 1.12 +++ workershowto.xml 18 Jul 2003 11:06:43 - 1.13 @@ -207,6 +207,7 @@ bcachesize/b property is usefull when you're using JK in multithreaded web servers such as Apache 2.0, IIS and Netscape. They will benefit the most by setting this value to a higher level (such as the estimated average concurrent users for Tomcat). +If cachesize is not set, the connection cache support is disabled. /p p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2 endpoint cache
Henri Gomez wrote: Glenn Nielsen a écrit : I have been testing mod_jk 1.2.5 with Apache 2 and load balancing. I noticed in the source that mod_jk 1.2 endpoint cache's are disabled by forcing ep_cache_sz=0. I did a cvs log and could not find any comments on why this is so. Is there a reason why this is disabled? Using a cache with a cache timeout sure would be handy for Apache 2 when using the worker MPM. This feature is documented in the jk docs and I don't see where anything is mentioned that it is disabled. I allways set cache in workers.properties but yes we should fix the documentation to explain that it's disabled by default. I can do it ASAP What I am saying is that use of the endpoint cache is completely disabled in the code, it doesn't matter what you set the cachesize to in worker.properties. Look at ajp_init() in ajp_common.c Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2 endpoint cache
Glenn Nielsen a écrit : Henri Gomez wrote: Glenn Nielsen a écrit : I have been testing mod_jk 1.2.5 with Apache 2 and load balancing. I noticed in the source that mod_jk 1.2 endpoint cache's are disabled by forcing ep_cache_sz=0. I did a cvs log and could not find any comments on why this is so. Is there a reason why this is disabled? Using a cache with a cache timeout sure would be handy for Apache 2 when using the worker MPM. This feature is documented in the jk docs and I don't see where anything is mentioned that it is disabled. I allways set cache in workers.properties but yes we should fix the documentation to explain that it's disabled by default. I can do it ASAP What I am saying is that use of the endpoint cache is completely disabled in the code, it doesn't matter what you set the cachesize to in worker.properties. Look at ajp_init() in ajp_common.c Hey yes you're right, it should be instead : p-ep_cache_sz = cache_sz; You commit or I ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2 endpoint cache
Glenn Nielsen a écrit : Henri Gomez wrote: Glenn Nielsen a écrit : I have been testing mod_jk 1.2.5 with Apache 2 and load balancing. I noticed in the source that mod_jk 1.2 endpoint cache's are disabled by forcing ep_cache_sz=0. I did a cvs log and could not find any comments on why this is so. Is there a reason why this is disabled? Using a cache with a cache timeout sure would be handy for Apache 2 when using the worker MPM. This feature is documented in the jk docs and I don't see where anything is mentioned that it is disabled. I allways set cache in workers.properties but yes we should fix the documentation to explain that it's disabled by default. I can do it ASAP What I am saying is that use of the endpoint cache is completely disabled in the code, it doesn't matter what you set the cachesize to in worker.properties. Look at ajp_init() in ajp_common.c Ooops didn't see all the code : --- ep_cache_sz is correctly set in line 1440 BTW, I wonder why there is a ep_mincache_sz, it's not used elsewhere - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 4.1.26 stability rating
Howdy, On a couple of days testing, no problems. Very light JSP testing, heavy servlet testing. Easily beta: [ ] Alpha [X] Beta [ ] Stable With some more time, more testing, maybe stable. 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: [5] hotfixes
Howdy, Currently o.a.c.startup.ClassLoaderFactory just does a standard directory listing. It might be nice to have the directory listed sorted in some manner so files with certain attributes might be loaded first. I was thinking of either - sorting by date - looking for hotfix--MM--hh-mm-ss.jar (or similar) first and sorting those files by name so the newest ones get loaded first. Comments? There used to be servers that did this (IPlanet and JServ come to mind, both using alphabetical sorting), and the amount of hassle that caused to developers was huge. Even to date, I see developers who rely on jar loading order to resolve having two classes with the same name in the JVM. I don't think this is a good idea. In the case for a hotfix, I would rather see a new jar altogether, replacing an existing jar. Not an addition, not an expansion, nor some fancy overriding mechanism. It significantly increases classloading debugging capability (which jar did this class really get loaded from?). I also tend to not fully agree with your beginning premise: One feature of enterprise ready software is the ability to apply small patches to an existing system. That's a nice to have, not essential, and a deterrent due to the above reasoning in the worst case. I would consider tomcat enterprise-ready now, without this feature per-se. Perhaps I'm misinterpreting what small patches are, though? Did you have examples in mind? I think it's the component owner's responsibility to provide the fix/patch, and to do so in the manner best fitting the component. In most java cases, I think that's an updated jar. If the fix requires many jars, then probably the product wasn't properly divided into modular jars to start with. I don't mean to sound extreme on this ;) I've heard far worse ideas. But I think for a general purpose server this causes more possible confusion and problems for users than it does good. 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: mod_jk 1.2 endpoint cache
Henri Gomez wrote: Glenn Nielsen a écrit : Henri Gomez wrote: Glenn Nielsen a écrit : I have been testing mod_jk 1.2.5 with Apache 2 and load balancing. I noticed in the source that mod_jk 1.2 endpoint cache's are disabled by forcing ep_cache_sz=0. I did a cvs log and could not find any comments on why this is so. Is there a reason why this is disabled? Using a cache with a cache timeout sure would be handy for Apache 2 when using the worker MPM. This feature is documented in the jk docs and I don't see where anything is mentioned that it is disabled. I allways set cache in workers.properties but yes we should fix the documentation to explain that it's disabled by default. I can do it ASAP What I am saying is that use of the endpoint cache is completely disabled in the code, it doesn't matter what you set the cachesize to in worker.properties. Look at ajp_init() in ajp_common.c Ooops didn't see all the code : --- ep_cache_sz is correctly set in line 1440 BTW, I wonder why there is a ep_mincache_sz, it's not used elsewhere Sorry for the confusion, you are right. It does get set later on. Did you get a chance to review the minor changes I made in the last week? With that resolved I am ready to roll another test mod_jk 1.2.5 release. If that looks ok we can vote on doing the release. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] hotfixes
Well stated, I agree with your concerns. Shapira, Yoav wrote: Howdy, Currently o.a.c.startup.ClassLoaderFactory just does a standard directory listing. It might be nice to have the directory listed sorted in some manner so files with certain attributes might be loaded first. I was thinking of either - sorting by date - looking for hotfix--MM--hh-mm-ss.jar (or similar) first and sorting those files by name so the newest ones get loaded first. Comments? There used to be servers that did this (IPlanet and JServ come to mind, both using alphabetical sorting), and the amount of hassle that caused to developers was huge. Even to date, I see developers who rely on jar loading order to resolve having two classes with the same name in the JVM. I don't think this is a good idea. In the case for a hotfix, I would rather see a new jar altogether, replacing an existing jar. Not an addition, not an expansion, nor some fancy overriding mechanism. It significantly increases classloading debugging capability (which jar did this class really get loaded from?). I also tend to not fully agree with your beginning premise: One feature of enterprise ready software is the ability to apply small patches to an existing system. That's a nice to have, not essential, and a deterrent due to the above reasoning in the worst case. I would consider tomcat enterprise-ready now, without this feature per-se. Perhaps I'm misinterpreting what small patches are, though? Did you have examples in mind? I think it's the component owner's responsibility to provide the fix/patch, and to do so in the manner best fitting the component. In most java cases, I think that's an updated jar. If the fix requires many jars, then probably the product wasn't properly divided into modular jars to start with. I don't mean to sound extreme on this ;) I've heard far worse ideas. But I think for a general purpose server this causes more possible confusion and problems for users than it does good. Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AccessLogValve.java - Missing +
Funkman, Thanks for fixing the timezone calculation bug. I know I'm
just being picky now, but shouldn't positive timezone offsets have a
(redundant) '+' at the start.
From http://httpd.apache.org/docs/logs.html#common
[10/Oct/2000:13:55:36 -0700] (%t)
The time that the server finished processing the
request. The format is:
[day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit
It is possible to have the time displayed in another
format by specifying %{format}t in the log format
string, where format is as in strftime(3) from the C
standard library.
On Wed, 2003-07-09 at 02:12, [EMAIL PROTECTED] wrote:
+private String calculateTimeZoneOffset(long offset) {
+StringBuffer tz = new StringBuffer();
+if ((offset0)) {
+tz.append(-);
+offset = -offset;
+}
+
+long hourOffset = offset/(1000*60*60);
+long minuteOffset = (offset/(1000*60)) % 60;
+
+if (hourOffset10)
+tz.append(0);
+tz.append(hourOffset);
+
+if (minuteOffset10)
+tz.append(0);
+tz.append(minuteOffset);
+
+return tz.toString();
+}
+
--
Yuri Schimke
Aqris Software
+372 53 415 579
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2 endpoint cache
Sorry for the confusion, you are right. It does get set later on. Did you get a chance to review the minor changes I made in the last week? Yes and I don't see any problems. With that resolved I am ready to roll another test mod_jk 1.2.5 release. If that looks ok we can vote on doing the release. The build works for Apache 1.3/2.0 on Linux, I should make some tests, and welcome any Windows binaries for Apache 2.0 ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21709] New: - %= % does not convert to string before passing arguments to custom tag handlers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21709.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21709
%= % does not convert to string before passing arguments to custom tag handlers
Summary: %= % does not convert to string before passing
arguments to custom tag handlers
Product: Tomcat 4
Version: 4.1.24
Platform: All
OS/Version: Windows NT/2K
Status: NEW
Severity: Minor
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This is a pretty obscure problem with a workaround, but to the best of my
knowledge the error is a violation of the servlet/JSP spec so should be fixed.
I have a custom tag called krm:action and I am using the JSTL in this example.
c:set var=title
c:out value=${row.shortDesc}/
/c:set
krm:action display=link type=componentNum componentNum=PL-SITE-01
title=%= pageContext.getAttribute(title) %
c:out value=${row.id}/
/krm:action
The compiler complains as follows:
[ServletException in:/adminPicklist/siteList-body.jsp] Unable to compile class
for JSP
An error occurred at line: -1 in the jsp file: null
Generated servlet error:
[javac] Since fork is true, ignoring compiler setting.
[javac] Compiling 1 source file
[javac] Since fork is true, ignoring compiler setting.
[javac] C:\jakarta-tomcat-4.1.24
\work\Standalone\localhost\ebspnp\adminPicklist\siteList_0002dbody_jsp.java:140:
setTitle(java.lang.String) in com.bah.krm.taglib.util.ActionTag cannot be
applied to (java.lang.Object)
[javac] _jspx_th_krm_action_0.setTitle(
pageContext.getAttribute(title) );
[javac]^
[javac] 1 error
The simple workaround is just do a manual toString() as follows:
c:set var=title
c:out value=${row.shortDesc}/
/c:set
krm:action display=link type=componentNum componentNum=PL-SITE-01
title=%= pageContext.getAttribute(title).toString() %
c:out value=${row.id}/
/krm:action
But the toString() call should happen automatically, shouldn't it? Isn't that
part of the spec?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.properties.default build.xml
remm2003/07/18 07:29:29
Modified:.build.properties.default build.xml
Log:
- Add commons-httpclient to the download list, for use with the tester
component.
Revision ChangesPath
1.98 +15 -8 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -r1.97 -r1.98
--- build.properties.default 30 Jun 2003 18:21:34 - 1.97
+++ build.properties.default 18 Jul 2003 14:29:29 - 1.98
@@ -101,6 +101,15 @@
commons-logging.loc=http://www.apache.org/dist/jakarta/commons/logging/binaries/commons-logging-1.0.3.tar.gz
+# - Commons Modeler, version 1.1 or later -
+commons-modeler.home=${base.path}/commons-modeler-1.1dev
+#commons-modeler.lib=${commons-modeler.home}
+commons-modeler.lib=${commons-modeler.home}
+commons-modeler.jar=${commons-modeler.lib}/commons-modeler.jar
+#commons-modeler.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-modeler/v1.0/commons-modeler-1.0.tar.gz
+commons-modeler.cvs.loc=jakarta-commons/modeler
+
+
# - Java Naming and Directory Interface (JNDI), version 1.2 or later -
# Note: Optional with JDK 1.3+
jndi.home=${base.path}/jndi-1.2.1
@@ -144,13 +153,11 @@
commons-dbcp.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-dbcp/v1.0/commons-dbcp-1.0.zip
-# - Commons Modeler, version 1.0 or later -
-commons-modeler.home=${base.path}/commons-modeler-1.1dev
-#commons-modeler.lib=${commons-modeler.home}
-commons-modeler.lib=${commons-modeler.home}
-commons-modeler.jar=${commons-modeler.lib}/commons-modeler.jar
-#commons-modeler.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-modeler/v1.0/commons-modeler-1.0.tar.gz
-commons-modeler.cvs.loc=jakarta-commons/modeler
+# - Commons HttpClient, version 2.0 or later -
+commons-httpclient.home=${base.path}/commons-httpclient-2.0-beta2
+commons-httpclient.lib=${commons-httpclient.home}
+commons-httpclient.jar=${commons-httpclient.lib}/commons-httpclient-2.0-beta2.jar
+commons-httpclient.loc=http://www.apache.org/dist/jakarta/commons/httpclient/binary/commons-httpclient-2.0-beta2.tar.gz
# - Commons Pool, version 1.0.1 or later -
1.141 +5 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.140
retrieving revision 1.141
diff -u -r1.140 -r1.141
--- build.xml 16 Jul 2003 22:50:41 - 1.140
+++ build.xml 18 Jul 2003 14:29:29 - 1.141
@@ -1589,6 +1589,11 @@
param name=destdir value=${base.path}/
/antcall
+antcall target=downloadgz
+ param name=sourcefile value=${commons-httpclient.loc}/
+ param name=destfile value=${commons-httpclient.jar}/
+/antcall
+
antcall target=downloadfile
param name=sourcefile value=${nsis.loc}/
param name=destfile value=${nsis.exe}/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk 1.2.5 test source distribution
I have generated another mod_jk 1.2.5 test source distribution, it can be found at: http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz Please build and test binaries for different OS and web servers. I will call for a release vote for mod_jk 1.2.5 one week from today. Then do the release Monday July 28 if the vote to release succeeds. Does that schedule work for everyone? Thanks, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21711] New: - Error when compiling a JSP that uses a TLD 1.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21711. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21711 Error when compiling a JSP that uses a TLD 1.1 Summary: Error when compiling a JSP that uses a TLD 1.1 Product: Tomcat 5 Version: 5.0.4 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When compiling a jsp that uses a 1.1 TLD, with tag that have an attribute called id, it generates the following error: java.lang.ClassCastException at javax.servlet.jsp.tagext.TagData.getAttributeString(TagData.java:176) at javax.servlet.jsp.tagext.TagData.getId(TagData.java:129) at javax.servlet.jsp.tagext.TagInfo.getVariableInfo(TagInfo.java:282) at org.apache.jasper.compiler.Node$CustomTag.setTagData(Node.java:1475) at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator. java:788) at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1444) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2142) at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2184) at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2190) at org.apache.jasper.compiler.Node$Root.accept(Node.java:471) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2142) at org.apache.jasper.compiler.Validator.validate(Validator.java:1499) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:264) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:458) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:444) at org.apache.jasper.JspCompilationContext. compile(JspCompilationContext.java:603) at org.apache.jasper.servlet.JspServletWrapper. service(JspServletWrapper.java:300) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java: 293) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.catalina.core.ApplicationFilterChain. internalDoFilter(ApplicationFilterChain.java:286) at org.apache.catalina.core.ApplicationFilterChain. doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve. invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardValveContext. invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline. java:562) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974) at org.apache.catalina.core.StandardContextValve. invoke(StandardContextValve.java:205) at org.apache.catalina.core.StandardValveContext. invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline. java:562) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve. java:177) at org.apache.catalina.core.StandardValveContext. invokeNext(StandardValveContext.java:151) at org.apache.catalina.valves.ErrorDispatcherValve. invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardValveContext. invokeNext(StandardValveContext.java:149) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve. java:172) at org.apache.catalina.core.StandardValveContext. invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline. java:562) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974) at org.apache.catalina.core.StandardEngineValve. invoke(StandardEngineValve.java:156) at org.apache.catalina.core.StandardValveContext. invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline. java:562) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java: 203) at org.apache.coyote.http11.Http11Processor.process(Http11Processor. java:637) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler. processConnection(Http11Protocol.java:488) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint. java:568) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable. run(ThreadPool.java:631) at
Re: AccessLogValve.java - Missing +
Doh! Your right. ( If its supposed to mimic the apache's %t, which I think it should) -Tim Yuri Schimke wrote: Funkman, Thanks for fixing the timezone calculation bug. I know I'm just being picky now, but shouldn't positive timezone offsets have a (redundant) '+' at the start. From http://httpd.apache.org/docs/logs.html#common - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] hotfixes
Hello, I don't agree with Glenn or Yoav. For each tomcat 4.1.x version I use there are a couple of things I have to fix over and over again. My approach to making changes is: 1) take the official binary release of tomcat and 2) make *minimal* changes to address the problems I have with it. Currently I end up with compiling a couple of java classes manually with the destination directory being the server/classes such as: javac -d /jakarta-tomcat-4.1.24/server/classes StandardContext.java I strongly don't want to replace the whole 'catalina.jar' because of my tiny change (risking screwing something up unintentionally). I can clearly see a benefit of also having an option to deploy my changes as a jar instead of the .class files I now end up with. I wasn't aware that the .jar files were not sorted alphabetically (and that explains some trouble I've had in the past trying to rely on it). I strongly suggest they should be, it doesn't hurt and will probably help silly users like myself. However I'm not sure about a 'hotfix-' kind of prefix for jarfiles since it is not explicit enough (you have to know you can create a file with that name and that it will be priorities over other jar files). I think a better approach would be to have a 'lib-hotfix' directory so you get a visual indicator that the possibility of hotfixes exist. Martin On Friday, July 18, 2003, at 02:32 PM, Glenn Nielsen wrote: Well stated, I agree with your concerns. Shapira, Yoav wrote: Howdy, Currently o.a.c.startup.ClassLoaderFactory just does a standard directory listing. It might be nice to have the directory listed sorted in some manner so files with certain attributes might be loaded first. I was thinking of either - sorting by date - looking for hotfix--MM--hh-mm-ss.jar (or similar) first and sorting those files by name so the newest ones get loaded first. Comments? There used to be servers that did this (IPlanet and JServ come to mind, both using alphabetical sorting), and the amount of hassle that caused to developers was huge. Even to date, I see developers who rely on jar loading order to resolve having two classes with the same name in the JVM. I don't think this is a good idea. In the case for a hotfix, I would rather see a new jar altogether, replacing an existing jar. Not an addition, not an expansion, nor some fancy overriding mechanism. It significantly increases classloading debugging capability (which jar did this class really get loaded from?). I also tend to not fully agree with your beginning premise: One feature of enterprise ready software is the ability to apply small patches to an existing system. That's a nice to have, not essential, and a deterrent due to the above reasoning in the worst case. I would consider tomcat enterprise-ready now, without this feature per-se. Perhaps I'm misinterpreting what small patches are, though? Did you have examples in mind? I think it's the component owner's responsibility to provide the fix/patch, and to do so in the manner best fitting the component. In most java cases, I think that's an updated jar. If the fix requires many jars, then probably the product wasn't properly divided into modular jars to start with. I don't mean to sound extreme on this ;) I've heard far worse ideas. But I think for a general purpose server this causes more possible confusion and problems for users than it does good. Yoav Shapira - 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: [5.0] Tester
What about anteater ? Costin Tim Funk wrote: Is there any chance we'd want to use Latka instead? (Which uses HttpClient) -Tim Remy Maucherat wrote: I have put the tester back in activity for TC 5 (and it caught the failure for error pages), but unfortunately there are a few limitations caused by the HTTP client used (for example, if the status is 500, you can't read the content). It would be a good idea IMO to switch to commons-httpclient (which I'll do, but it's not a very high priority). Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] hotfixes
Yeah, I am scared of side effects too. This funtionality will be helpful in the following situations: - My previous post where the access log doesn't print '+' in front of the offset - ExtendedAccessLogValve printed the date instead of bytes (recent patch) - The recent Connector fixes we have seen for SSL related issues - JDBC, JNDI realm fixes - Misc valve or clustering fixes In all of the above - they are for bug fixes that don't warrant an immediate release. They are usually for fringe cases where it makes tomcat a PITA to use if not fixed. If one chooses not to use this feature, then the current functionality stays the same. The patch I have in mind will not include the webapp classloader. Since the spec doesn't seem to define a jar order - I prefer not to impose one. Currently a user has 2 workarounds: - Take the milestone source tree and apply the patches and build - Build from HEAD - Place the fix in XXX/classes The first two scenarios is a lot of work and very risky since other unintended changes can easily be introduced. (At least the HEAD method is) The third scenario can be hard to maintain from an admin point of view if the user also uses their own classes in the lib directory. I also like Martin 's idea of possibly introducing another directory called lib-hotfix. That seems cleaner and clearer than a date (or file) based sort. -Tim Shapira, Yoav wrote: Perhaps I'm misinterpreting what small patches are, though? Did you have examples in mind? I think it's the component owner's responsibility to provide the fix/patch, and to do so in the manner best fitting the component. In most java cases, I think that's an updated jar. If the fix requires many jars, then probably the product wasn't properly divided into modular jars to start with. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Tester
Costin Manolache wrote: What about anteater ? (yet another project I didn't know about) The sad truth is that I'm lazy :) I want to rewrite the minimum possible amount of code and fix the tests which can't work with the JDK's HTTP client (ex: it returns 500 - TC 5 now restores the original error code; neat - but I still want to read the entity body; the JDK then throws an exception to inform me I'm stupid to attempt to do that; thanks Sun) :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug in JkMX.java
Do you want me to create a bugzilla report? here's the diff. Need to check for the
whole class
(mx4j.adaptor.http.HttpAdaptor)
Thanks,
dims
Index: JkMX.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java,v
retrieving revision 1.12
diff -d -u -b -B -w -u -r1.12 JkMX.java
--- JkMX.java 2 Jun 2003 01:22:32 - 1.12
+++ JkMX.java 18 Jul 2003 15:24:29 -
@@ -112,7 +112,7 @@
public void loadAdapter() throws IOException {
boolean adapterLoaded = false;
-if (classExists(mx4j.adaptor.http)) {
+if (classExists(mx4j.adaptor.http.HttpAdaptor)) {
try {
serverName = new ObjectName(Http:name=HttpAdaptor);
mserver.createMBean(mx4j.adaptor.http.HttpAdaptor, serverName,
null);
=
Davanum Srinivas - http://webservices.apache.org/~dims/
__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Optimizing the core a bit more
In an effort to tweak the core a bit more to simplify things: - Remove ContainerBase.invoke: A Container always has a Pipeline associated with it; as such, the Container interface should have a getPipeline method, and this should be called instead. This will reduce a bit the call stack. - I noticed the RequestListenerValve was added twice to the pipeline (using the tester). This doesn't seem right, obviously. - The RequestListenerValve builds the list of the listeners it must notify dynamically, on each request (twice for each request = lots of useless instanceof). This should IMO be done statically in start (with the array of listeners being cleared on stop). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] hotfixes
Tim Funk wrote: Yeah, I am scared of side effects too. This funtionality will be helpful in the following situations: - My previous post where the access log doesn't print '+' in front of the offset - ExtendedAccessLogValve printed the date instead of bytes (recent patch) - The recent Connector fixes we have seen for SSL related issues - JDBC, JNDI realm fixes - Misc valve or clustering fixes In all of the above - they are for bug fixes that don't warrant an immediate release. They are usually for fringe cases where it makes tomcat a PITA to use if not fixed. If one chooses not to use this feature, then the current functionality stays the same. The patch I have in mind will not include the webapp classloader. Since the spec doesn't seem to define a jar order - I prefer not to impose one. Currently a user has 2 workarounds: - Take the milestone source tree and apply the patches and build - Build from HEAD - Place the fix in XXX/classes The first two scenarios is a lot of work and very risky since other unintended changes can easily be introduced. (At least the HEAD method is) The third scenario can be hard to maintain from an admin point of view if the user also uses their own classes in the lib directory. I also like Martin 's idea of possibly introducing another directory called lib-hotfix. That seems cleaner and clearer than a date (or file) based sort. After reading everyone's comments, I will vote -1 to the hotfix proposal, because: - people will abuse it, have *lots* of hotfixes installed - the subsequent bugs being reported will be harder to debug given the increased difficulty of reproducing the user's configuration - users will basically expect us (= me the RM) to release one hotfix for every bugfix, which is something I don't want to do - hotfix conflicts and incompatibilities - added complexity in the container to manage the hotfixes (the container needs simplification whenever possible :) ) - the HTTPd project doesn't do it, for a very similar product; OTOH, M$ does it; one of the vendors is IMO more trustworthy than the other (ok, it's a bad argument ;-) ) Note that I did release hotfixes in very specific cases in the past, for security related problems. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Small issue with 4.1.26 catalina.sh
Howdy, Tomcat 4.1.26-LE Solaris 8 JDK 1.4.2 Invoking $CATALINA_HOME/bin/startup.sh produces the following output: /home/shapira/tomcat/bin/catalina.sh: !: not found Using CATALINA_BASE: /home/shapira/tomcat Using CATALINA_HOME: /home/shapira/tomcat Using CATALINA_TMPDIR: /home/shapira/tomcat/temp Using JAVA_HOME: /home/shapira/jdk/j2sdk1.4.2 The same output repeats when invoking shutdown.sh. The server starts up fine, works fine, and shuts down fine. Why am I getting that :not found line? I've never gotten it before. Thanks, Yoav Shapira Millennium ChemInformatics 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: [5] hotfixes
Howdy, I would also vote -1 as I mentioned before. It's another source for confusion and bugs, and does not add much in practice I think. The small bugs that necessitate one class changes are typically not showstoppers, but more the PITA category that Tim referred to. To the individual developer/server admin, it's either: - Sure it's PITA but I don't have tom worry; file a bug report and wait for the next release, or - This is so annoying I can't stand it and will put my own class files here to fix it If something is a real showstopper, we're going to want a real release to fix it anyways, with documentation, testing, etc. Yoav Shapira Millennium ChemInformatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 11:52 AM To: Tomcat Developers List Subject: Re: [5] hotfixes Tim Funk wrote: Yeah, I am scared of side effects too. This funtionality will be helpful in the following situations: - My previous post where the access log doesn't print '+' in front of the offset - ExtendedAccessLogValve printed the date instead of bytes (recent patch) - The recent Connector fixes we have seen for SSL related issues - JDBC, JNDI realm fixes - Misc valve or clustering fixes In all of the above - they are for bug fixes that don't warrant an immediate release. They are usually for fringe cases where it makes tomcat a PITA to use if not fixed. If one chooses not to use this feature, then the current functionality stays the same. The patch I have in mind will not include the webapp classloader. Since the spec doesn't seem to define a jar order - I prefer not to impose one. Currently a user has 2 workarounds: - Take the milestone source tree and apply the patches and build - Build from HEAD - Place the fix in XXX/classes The first two scenarios is a lot of work and very risky since other unintended changes can easily be introduced. (At least the HEAD method is) The third scenario can be hard to maintain from an admin point of view if the user also uses their own classes in the lib directory. I also like Martin 's idea of possibly introducing another directory called lib-hotfix. That seems cleaner and clearer than a date (or file) based sort. After reading everyone's comments, I will vote -1 to the hotfix proposal, because: - people will abuse it, have *lots* of hotfixes installed - the subsequent bugs being reported will be harder to debug given the increased difficulty of reproducing the user's configuration - users will basically expect us (= me the RM) to release one hotfix for every bugfix, which is something I don't want to do - hotfix conflicts and incompatibilities - added complexity in the container to manage the hotfixes (the container needs simplification whenever possible :) ) - the HTTPd project doesn't do it, for a very similar product; OTOH, M$ does it; one of the vendors is IMO more trustworthy than the other (ok, it's a bad argument ;-) ) Note that I did release hotfixes in very specific cases in the past, for security related problems. Remy - 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]
Re: [5] hotfixes
Tim, If the problem is that bug fixes have not made it into a release in a timely manner, then we should be doing releases more frequently. Or put back in place the nightly builds. Using hotfixes to bridge the gap between releases is overkill IMHO. I am still -1 on adding this. Glenn Tim Funk wrote: Yeah, I am scared of side effects too. This funtionality will be helpful in the following situations: - My previous post where the access log doesn't print '+' in front of the offset - ExtendedAccessLogValve printed the date instead of bytes (recent patch) - The recent Connector fixes we have seen for SSL related issues - JDBC, JNDI realm fixes - Misc valve or clustering fixes In all of the above - they are for bug fixes that don't warrant an immediate release. They are usually for fringe cases where it makes tomcat a PITA to use if not fixed. If one chooses not to use this feature, then the current functionality stays the same. The patch I have in mind will not include the webapp classloader. Since the spec doesn't seem to define a jar order - I prefer not to impose one. Currently a user has 2 workarounds: - Take the milestone source tree and apply the patches and build - Build from HEAD - Place the fix in XXX/classes The first two scenarios is a lot of work and very risky since other unintended changes can easily be introduced. (At least the HEAD method is) The third scenario can be hard to maintain from an admin point of view if the user also uses their own classes in the lib directory. I also like Martin 's idea of possibly introducing another directory called lib-hotfix. That seems cleaner and clearer than a date (or file) based sort. -Tim Shapira, Yoav wrote: Perhaps I'm misinterpreting what small patches are, though? Did you have examples in mind? I think it's the component owner's responsibility to provide the fix/patch, and to do so in the manner best fitting the component. In most java cases, I think that's an updated jar. If the fix requires many jars, then probably the product wasn't properly divided into modular jars to start with. - 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: [5] hotfixes
Thats ok with me, I'm glad this was discussed in case this topic comes up in the future. -Tim Remy Maucherat wrote: After reading everyone's comments, I will vote -1 to the hotfix proposal, because: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21714] New: - MX4J mx4j.adaptor.http.HttpAdaptor is not loaded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21714.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21714
MX4J mx4j.adaptor.http.HttpAdaptor is not loaded
Summary: MX4J mx4j.adaptor.http.HttpAdaptor is not loaded
Product: Tomcat 4
Version: Nightly Build
Platform: All
URL: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-
connectors/jk/java/org/apache/jk/common/JkMX.java.diff?r
1=1.11r2=1.12diff_format=h
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Need to check for the whole class (mx4j.adaptor.http.HttpAdaptor) and not
mx4j.adaptor.http. See diff below :
Index: JkMX.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java,v
retrieving revision 1.12
diff -d -u -b -B -w -u -r1.12 JkMX.java
--- JkMX.java 2 Jun 2003 01:22:32 - 1.12
+++ JkMX.java 18 Jul 2003 15:24:29 -
@@ -112,7 +112,7 @@
public void loadAdapter() throws IOException {
boolean adapterLoaded = false;
-if (classExists(mx4j.adaptor.http)) {
+if (classExists(mx4j.adaptor.http.HttpAdaptor)) {
try {
serverName = new ObjectName(Http:name=HttpAdaptor);
mserver.createMBean(mx4j.adaptor.http.HttpAdaptor,
serverName, null);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in JkMX.java
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21714
--- Davanum Srinivas [EMAIL PROTECTED] wrote:
Do you want me to create a bugzilla report? here's the diff. Need to check for the
whole class
(mx4j.adaptor.http.HttpAdaptor)
Thanks,
dims
Index: JkMX.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java,v
retrieving revision 1.12
diff -d -u -b -B -w -u -r1.12 JkMX.java
--- JkMX.java 2 Jun 2003 01:22:32 - 1.12
+++ JkMX.java 18 Jul 2003 15:24:29 -
@@ -112,7 +112,7 @@
public void loadAdapter() throws IOException {
boolean adapterLoaded = false;
-if (classExists(mx4j.adaptor.http)) {
+if (classExists(mx4j.adaptor.http.HttpAdaptor)) {
try {
serverName = new ObjectName(Http:name=HttpAdaptor);
mserver.createMBean(mx4j.adaptor.http.HttpAdaptor, serverName,
null);
=
Davanum Srinivas - http://webservices.apache.org/~dims/
__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
=
Davanum Srinivas - http://webservices.apache.org/~dims/
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Tester
On Fri, 18 Jul 2003, Remy Maucherat wrote: Date: Fri, 18 Jul 2003 11:30:35 +0200 From: Remy Maucherat [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: [5.0] Tester I have put the tester back in activity for TC 5 (and it caught the failure for error pages), but unfortunately there are a few limitations caused by the HTTP client used (for example, if the status is 500, you can't read the content). It would be a good idea IMO to switch to commons-httpclient (which I'll do, but it's not a very high priority). Switching is fine if you want, but the existing tester does (or at least it did) have a mode where it uses a low-level socket instead of HttpURLConnection, and therefore doesn't give you the useless garbage on a 500. The trick is to set the protocol property to HTTP/1.0 instead of an empty string. Comments ? Remy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21219] - Corrupted Message Body on interrupted GET
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21219. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21219 Corrupted Message Body on interrupted GET --- Additional Comments From [EMAIL PROTECTED] 2003-07-18 16:31 --- I feel this bug should be reopened -- my understanding that only a change in Tomcat will enable servlets to behave properly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Tester
Craig R. McClanahan wrote: I have put the tester back in activity for TC 5 (and it caught the failure for error pages), but unfortunately there are a few limitations caused by the HTTP client used (for example, if the status is 500, you can't read the content). It would be a good idea IMO to switch to commons-httpclient (which I'll do, but it's not a very high priority). Switching is fine if you want, but the existing tester does (or at least it did) have a mode where it uses a low-level socket instead of HttpURLConnection, and therefore doesn't give you the useless garbage on a 500. The trick is to set the protocol property to HTTP/1.0 instead of an empty string. I had missed the executeSocket method. That's useful :) Switching to HttpClient still makes sense IMO, but is not essential to fix some tests. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Optimizing the core a bit more
Remy Maucherat wrote: In an effort to tweak the core a bit more to simplify things: - Remove ContainerBase.invoke: A Container always has a Pipeline associated with it; as such, the Container interface should have a getPipeline method, and this should be called instead. This will reduce a bit the call stack. - I noticed the RequestListenerValve was added twice to the pipeline (using the tester). This doesn't seem right, obviously. Actually, since it is a needed feature for spec compliance, and to simplify things a little, it should be in core, and I'll integrate the code in StandardContextValve. Similarly, the code in the ErrorDispatcherValve should be integrated in StandardHostValve. OTOH, the ErrorReportValve should stay as is as a Valve, as it is not required for spec compliance, and it is valid to remove or replace it. Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Minor typo stopping 4.1.26 from running on NetWare.
There is a minor capitalization typo that is causing 4.1.26 to not start up properly on NetWare. I think this typo has been there a while, but the newer version of struts causes the typo to actually trigger an error now. I have attached a diff file; could somebody please make this simple change for me? Thanks, Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/admin/WEB-INF/struts-config.xml,v retrieving revision 1.52 diff -u -r1.52 struts-config.xml --- struts-config.xml 9 Apr 2003 22:36:33 - 1.52 +++ struts-config.xml 18 Jul 2003 17:40:07 - @@ -85,7 +85,7 @@ type=org.apache.webapp.admin.defaultcontext.DefaultContextForm/ form-bean name=defaultContextsForm - type=org.apache.webapp.admin.defaultContext.DefaultContextsForm/ + type=org.apache.webapp.admin.defaultcontext.DefaultContextsForm/ !-- = Connector Module = -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina Container.java
remm2003/07/18 11:48:59 Modified:catalina/src/share/org/apache/catalina Container.java Log: - Add a getPipeline() to allow bypassing the (useless) invoke method. Revision ChangesPath 1.6 +11 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Container.java Index: Container.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Container.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- Container.java23 May 2003 10:54:15 - 1.5 +++ Container.java18 Jul 2003 18:48:58 - 1.6 @@ -237,6 +237,13 @@ /** + * Return the Pipeline object that manages the Valves associated with + * this Container. + */ +public Pipeline getPipeline(); + + +/** * Return the Cluster with which this Container is associated. If there is * no associated Cluster, return the Cluster associated with our parent * Container (if any); otherwise return codenull/code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21717] New: - Can't insert page '...': Illegal to flush within a custom tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21717. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21717 Can't insert page '...': Illegal to flush within a custom tag Summary: Can't insert page '...': Illegal to flush within a custom tag Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Can't insert page '...': Illegal to flush within a custom tag I'm getting this message in tomcat 4.1.x, also tried tomcat 5 dev. I can't seem to find a real explaination for this behaviour in related bug reports (3543 3776). in bug report 3543: Up until 4.0-rc1, Tomcat 4 was incorrectly *not* doing the flush in it. In rc1, this was added to conform to the spec. Because it is a spec requirement, there is no way to turn it off. in the jsp 1.2 specs i found this note: JSP 1.2 extends JavaServer Pages 1.1 Specification (JSP 1.1) in the following ways: ... Fixing the infamous flush before you include limitation in JSP 1.1. But i did not find the line telling an include should be illegal if it is made by a tag handler... (could be looking over it :) I know weblogic 6.1 doesn't complain about this... don't know about the more recent versions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContextValve.java StandardEngineValve.java StandardHostValve.java
remm2003/07/18 11:49:28
Modified:catalina/src/share/org/apache/catalina/core
StandardContextValve.java StandardEngineValve.java
StandardHostValve.java
Log:
- Add a getPipeline() to allow bypassing the (useless) invoke method.
Revision ChangesPath
1.8 +6 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContextValve.java
Index: StandardContextValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContextValve.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- StandardContextValve.java 26 May 2003 22:03:59 - 1.7
+++ StandardContextValve.java 18 Jul 2003 18:49:28 - 1.8
@@ -194,7 +194,7 @@
if (((StandardContext) container).getSwallowOutput()) {
try {
SystemLogHandler.startCapture();
-wrapper.invoke(request, response);
+wrapper.getPipeline().invoke(request, response);
} finally {
String log = SystemLogHandler.stopCapture();
if (log != null log.length() 0) {
@@ -202,7 +202,7 @@
}
}
} else {
-wrapper.invoke(request, response);
+wrapper.getPipeline().invoke(request, response);
}
}
1.5 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngineValve.java
Index: StandardEngineValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngineValve.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- StandardEngineValve.java 26 May 2003 22:03:59 - 1.4
+++ StandardEngineValve.java 18 Jul 2003 18:49:28 - 1.5
@@ -153,7 +153,7 @@
}
// Ask this Host to process this request
-host.invoke(request, response);
+host.getPipeline().invoke(request, response);
}
1.6 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
Index: StandardHostValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- StandardHostValve.java26 May 2003 22:03:59 - 1.5
+++ StandardHostValve.java18 Jul 2003 18:49:28 - 1.6
@@ -174,7 +174,7 @@
}
// Ask this Context to process this request
-context.invoke(request, response);
+context.getPipeline().invoke(request, response);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: URI Space and smarter hand off between Apache/Tomcat
--- Marc Slemko [EMAIL PROTECTED] wrote: On Thu, 17 Jul 2003, P. Brewer wrote: I found the following thread from a year ago: http://marc.theaimsgroup.com/?l=tomcat-devm=102815260317741w=2\ . . . deleted . . . Was it shot down for a technical reason? Just didn't get implmented? Or is implemented and not documented? I can help with C code, but probably not much help with Java code. You would probably be better off to just make mod_jk* properly support Apache (and other webserver) configuration directives such as Directory and Files, then use them to control what gets passed on to tomcat. Having mod_jk trying to do parsing based on filenames on disk is a very bad idea for performance and security reasons, especially on win32 platforms. I'm not sure where you are coming from, I am not suggesting pasing based on filenames on disk. I am speaking of resource names in the request URL. Granted in most cases there is a matching file name on disk, but that is irrelivant for this process. The matching occurs on the URI and the decision to pass to Tomcat is made with out ever looking at the disk. for example: JkMount /weatherPage/* JkNotMount /weatherPage/images/* JkNotMount /weatherPage/*.html would yeild the following results Request Handled By Server --- http://my.server/weatherPage/index.html apache http://my.server/weatherPage/textForcast __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URI Space and smarter hand off between Apache/Tomcat
--- Marc Slemko [EMAIL PROTECTED] wrote: On Thu, 17 Jul 2003, P. Brewer wrote: I found the following thread from a year ago: http://marc.theaimsgroup.com/?l=tomcat-devm=102815260317741w=2\ . . . deleted . . . Was it shot down for a technical reason? Just didn't get implmented? Or is implemented and not documented? I can help with C code, but probably not much help with Java code. You would probably be better off to just make mod_jk* properly support Apache (and other webserver) configuration directives such as Directory and Files, then use them to control what gets passed on to tomcat. Having mod_jk trying to do parsing based on filenames on disk is a very bad idea for performance and security reasons, especially on win32 platforms. I'm not sure where you are coming from, I am not suggesting pasing based on filenames on disk. I am speaking of resource names in the request URL. Granted in most cases there is a matching file name on disk, but that is irrelivant for this process. The matching occurs on the URI and the decision to pass to Tomcat is made with out ever looking at the disk. for example: JkMount /weatherPage/* JkNotMount /weatherPage/images/* JkNotMount /weatherPage/*.html would yeild the following results Request Handled By Server --- http://my.server/weatherPage/index.html apache http://my.server/weatherPage/textForcasttomcat http://my.server/weatherPage/images/sun.gif apache http://my.server/weatherPage/currentTemp.jpgtomcat http://my.server/weatherPage/images/cloud.jpg apache http://my.server/weatherPage/city/newyork.html apache http://my.server/weatherPage/city/current?city=newyork tomcat ps. Sorry for incomplete submission. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884
SingleThreadModel servlets not pooled results in low performance
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Additional Comments From [EMAIL PROTECTED] 2003-07-18 22:12 ---
With 4.1.24, I make a simple isThreadSafe=false jsp with only:
try {
System.out.println(Before sleep, instance is +this+ time
is +System.currentTimeMillis());
Thread.sleep(60*1000);
System.out.println(After sleep, instance is +this+ time
is +System.currentTimeMillis());
} catch(InterruptedException ex) {}
and at the moment, it serializes, as hitting it w/ 2 browsers leads to:
Before sleep, instance is [EMAIL PROTECTED] time is 1058566078026
After sleep, instance is [EMAIL PROTECTED] time is 1058566138034
Before sleep, instance is [EMAIL PROTECTED] time is 1058566138034
After sleep, instance is [EMAIL PROTECTED] time is 1058566198042
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884 SingleThreadModel servlets not pooled results in low performance [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-18 22:19 --- What you're using is a STM JSP, which is not the same as a servlet since its invoked through a non STM wrapper servlet: the JasperServlet. Pooling cannot be implemented in that case (unless adding a pool in the JasperServlet itself, but it would be yet another horrible hack inside Jasper, so I'm -1 for it). If you want to get the same behavior as with a regular STM servlet, you have to precompile your JSP (and map it in web.xml), in which case Catalina will identify your servlet as STM and pool it. I'm reverting to the old resolution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Servlet logging and error messages
I'm working on the following changes: - Stripping out all the Catalina related part of the stack trace in the HTML generated by the ErrorReportValve; that eases debugging. - When an exception occurs, and it is a ServletException, I think the root cause should be logged, not the external exception, which 99% of the time is useless. - I strongly believe that all webapp triggered logging (init errors, service errors, etc) should go to the servlet container provided logger (ie Context.getLogger()). Right now, a significant amount is sent to commons-logging. I was aware that the intent was to switch the container itself to commons-logging (and I am +1 for it), but c-l or another generic logging framework such as log4j, is IMO not adapted to provide the webapp logging (same for the access log, obvioously). Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat Jdk14Compat.java JdkCompat.java
remm2003/07/18 15:24:38
Modified:util/java/org/apache/tomcat/util/compat Jdk14Compat.java
JdkCompat.java
Log:
- Add compat code to print out partial stack traces.
Revision ChangesPath
1.4 +27 -4
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/Jdk14Compat.java
Index: Jdk14Compat.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/Jdk14Compat.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Jdk14Compat.java 26 Mar 2003 11:01:39 - 1.3
+++ Jdk14Compat.java 18 Jul 2003 22:24:37 - 1.4
@@ -75,7 +75,8 @@
/**
* See JdkCompat. This is an extension of that class for Jdk1.4 support.
*
- * @author Tim Funk
+ * @author Tim Funk
+ * @author Remy Maucherat
*/
public class Jdk14Compat extends JdkCompat {
// -- Constants
@@ -119,6 +120,28 @@
*/
public long getMaxMemory() {
return Runtime.getRuntime().maxMemory();
+}
+
+
+/**
+ * Print out a partial servlet stack trace (truncating at the last
+ * occurrence of javax.servlet.).
+ */
+public String getPartialServletStackTrace(Throwable t) {
+StringBuffer trace = new StringBuffer();
+trace.append(t.toString()).append('\n');
+StackTraceElement[] elements = t.getStackTrace();
+int pos = elements.length;
+for (int i = (elements.length - 1); i = 0; i--) {
+if (elements[i].getClassName().startsWith(javax.servlet.)) {
+pos = i + 1;
+break;
+}
+}
+for (int i = 0; i pos; i++) {
+trace.append('\t').append(elements[i].toString()).append('\n');
+}
+return trace.toString();
}
1.5 +16 -3
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/JdkCompat.java
Index: JdkCompat.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/JdkCompat.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JdkCompat.java26 Mar 2003 11:01:39 - 1.4
+++ JdkCompat.java18 Jul 2003 22:24:37 - 1.5
@@ -66,6 +66,8 @@
import java.io.IOException;
import java.net.URL;
import java.net.MalformedURLException;
+import java.io.PrintWriter;
+import java.io.StringWriter;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -198,6 +200,17 @@
*/
public long getMaxMemory() {
return (-1L);
+}
+
+
+/**
+ * Print out a partial servlet stack trace (truncating at the last
+ * occurrence of javax.servlet.).
+ */
+public String getPartialServletStackTrace(Throwable t) {
+StringWriter stackTrace = new StringWriter();
+t.printStackTrace(new PrintWriter(stackTrace));
+return stackTrace.toString();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java
remm2003/07/18 15:25:53
Modified:catalina/src/share/org/apache/catalina/valves
ErrorReportValve.java
Log:
- Print out partial stack traces (on JDK 1.4; older JDKs would need substring
based hacks, and I'm not sure it's a very good idea ...).
Revision ChangesPath
1.5 +13 -10
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java
Index: ErrorReportValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ErrorReportValve.java 21 Jun 2003 17:37:17 - 1.4
+++ ErrorReportValve.java 18 Jul 2003 22:25:52 - 1.5
@@ -79,6 +79,9 @@
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+
+import org.apache.tomcat.util.compat.JdkCompat;
+
import org.apache.catalina.Container;
import org.apache.catalina.Globals;
import org.apache.catalina.HttpRequest;
@@ -319,20 +322,20 @@
sb.append(/u/p);
if (throwable != null) {
-StringWriter stackTrace = new StringWriter();
-throwable.printStackTrace(new PrintWriter(stackTrace));
+String stackTrace = JdkCompat.getJdkCompat()
+.getPartialServletStackTrace(throwable);
sb.append(pb);
sb.append(sm.getString(errorReportValve.exception));
sb.append(/b pre);
-sb.append(stackTrace.toString());
+sb.append(stackTrace);
sb.append(/pre/p);
while (rootCause != null) {
-stackTrace = new StringWriter();
-rootCause.printStackTrace(new PrintWriter(stackTrace));
+stackTrace = JdkCompat.getJdkCompat()
+.getPartialServletStackTrace(rootCause);
sb.append(pb);
sb.append(sm.getString(errorReportValve.rootCause));
sb.append(/b pre);
-sb.append(stackTrace.toString());
+sb.append(stackTrace);
sb.append(/pre/p);
/* In case root cause is somehow heavily nested */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapperValve.java
remm2003/07/18 15:26:15
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapperValve.java
Log:
- Log root cause of an exception.
Revision ChangesPath
1.16 +11 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java
Index: StandardWrapperValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- StandardWrapperValve.java 26 May 2003 22:03:59 - 1.15
+++ StandardWrapperValve.java 18 Jul 2003 22:26:15 - 1.16
@@ -284,8 +284,17 @@
// do not want to do exception(request, response, e) processing
} catch (ServletException e) {
hreq.removeAttribute(Globals.JSP_FILE_ATTR);
+Throwable rootCause = e;
+while (rootCause instanceof ServletException) {
+Throwable t = ((ServletException) rootCause).getRootCause();
+if (t != null) {
+rootCause = t;
+} else {
+break;
+}
+}
log.error(sm.getString(standardWrapper.serviceException,
- wrapper.getName()), e);
+ wrapper.getName()), rootCause);
throwable = e;
exception(request, response, e);
} catch (Throwable e) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves LocalStrings_fr.properties
remm2003/07/18 15:31:55
Modified:catalina/src/share/org/apache/catalina/valves
LocalStrings_fr.properties
Log:
- Fix typos on the 500 error message.
Revision ChangesPath
1.2 +1 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/LocalStrings_fr.properties
Index: LocalStrings_fr.properties
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/LocalStrings_fr.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- LocalStrings_fr.properties5 Nov 2002 09:35:31 - 1.1
+++ LocalStrings_fr.properties18 Jul 2003 22:31:55 - 1.2
@@ -56,7 +56,7 @@
http.417=L''attente indiqué dans la directive Expect de l''entête de requête
({0}) ne peut être satisfaite.
http.422=Le serveur a compris le type de contenu (content type) ainsi que la
synthaxe de la requête mais a été incapable de traiter les instructions contenues
({0}).
http.423=La ressource source ou destination de la méthode est vérrouillée ({0}).
-http.500=Le serveur a recontrer une erreur interne ({0}) qui l''a empèché de
satisfaire la requête.
+http.500=Le serveur a rencontré une erreur interne ({0}) qui l''a empêché de
satisfaire la requête.
http.501=Le serveur ne supporte pas la fonctionnalité demandée pour satisfaire
cette requête ({0}).
http.502=Le serveur a reçu une réponse invalide d'un serveur qu''il consultait en
tant que relais ou passerelle ({0}).
http.503=Le service demandé ({0}) n''est pas disponible actuellement.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util StringManager.java
remm2003/07/18 15:54:20
Modified:catalina/src/share/org/apache/catalina/util
StringManager.java
Log:
- Fix a problem where the Strings weren't escaped in the same way for chars
such as '. This caused problems for localization in French.
Revision ChangesPath
1.4 +9 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/StringManager.java
Index: StringManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/StringManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- StringManager.java9 Apr 2003 04:29:56 - 1.3
+++ StringManager.java18 Jul 2003 22:54:19 - 1.4
@@ -142,8 +142,12 @@
*
* @param key
*/
-
public String getString(String key) {
+return MessageFormat.format(getStringInternal(key), null);
+}
+
+
+protected String getStringInternal(String key) {
if (key == null) {
String msg = key is null;
@@ -173,7 +177,7 @@
public String getString(String key, Object[] args) {
String iString = null;
-String value = getString(key);
+String value = getStringInternal(key);
// this check for the runtime exception is some pre 1.1.6
// VM's don't do an automatic toString() on the passed in
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21709] - %= % does not convert to string before passing arguments to custom tag handlers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21709 %= % does not convert to string before passing arguments to custom tag handlers [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-07-18 23:47 --- Sorry, looked at the spec and I think this bug is bogus. Tomcat behaves as it should. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compatJdk14Compat.java JdkCompat.java
I have no issue with substring use for jdk1.3 getPartialServletStackTrace()
since it should not get called often so the performance shouldn't be an issue
(or am I missing something more subtle).
Possible alternative (for the 1.3 version).
public String getPartialServletStackTrace(Throwable t) {
StringWriter stackTrace = new StringWriter();
t.printStackTrace(new PrintWriter(stackTrace));
String st = stackTrace.toString();
int i = st.lastIndexOf(javax.servlet.);
if (i-1)
return st.substring(0, i);
else
return st;
}
-Tim
[EMAIL PROTECTED] wrote:
remm2003/07/18 15:24:38
Modified:util/java/org/apache/tomcat/util/compat Jdk14Compat.java
JdkCompat.java
Log:
- Add compat code to print out partial stack traces.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compatJdk14Compat.java JdkCompat.java
Tim Funk wrote:
I have no issue with substring use for jdk1.3
getPartialServletStackTrace() since it should not get called often so
the performance shouldn't be an issue (or am I missing something more
subtle).
Yes, zero performance impact.
Possible alternative (for the 1.3 version).
public String getPartialServletStackTrace(Throwable t) {
StringWriter stackTrace = new StringWriter();
t.printStackTrace(new PrintWriter(stackTrace));
String st = stackTrace.toString();
int i = st.lastIndexOf(javax.servlet.);
if (i-1)
return st.substring(0, i);
else
return st;
}
Sounds like a good start. There should be a at prefix in front of
each line (which is something I don't like with traces, since the at
can never be i18n ready). I'll try to hack that a little bit tomorrow,
unless it gets automagically done while I sleep :)
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15002] - Tag files in different directories not belonging to different tag libraries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15002 Tag files in different directories not belonging to different tag libraries [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-19 00:53 --- I'm unable to reproduce this, so I assume it has been fixed, and just not updated in Bugzilla. Anyone who can reproduce it, please reopen. Running a fresh checkout of Tomcat 5 on Windows XP, I was able to run all the tagfile examples in the jsp-examples webapp. I also tested the original problem case of /WEB-INF/tags/foo/test.tag and /WEB- INF/tags/bar/test.tag. There was no sign of a conflict, and the tags compiled to scratch_dir/appname/org/apache/jsp/tag/web/foo/test.java and scratch_dir/appname/org/apache/jsp/tag/web/bar/test.java, respectively, as Jan's note said they would. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
