Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
Jean-Francois Arcand a écrit :
Henri Gomez wrote:
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie :
!ENTITY appset1 SYSTEM appset1.xml
!ENTITY appset2 SYSTEM appset2.xml
In Digester.java, at least in the 1.5 release, resolveEntity return
null if publicId is null even if systemId is set.
To make it works, I just replaced :
--
if (entityURL == null){
return (null);
by ---
if (entityURL == null){
if (systemId == null)
return (null);
else
entityURL = systemId;
}
FYI, in resolveEntity we got as parms for previous app1app2 entities
declaration:
systemid=jndi:/localhost/myapp/WEB-INF/appset1.xml and publicid=null
systemid=jndi:/localhost/myapp/WEB-INF/appset2.xml and publicid=null
This hack will solve the resolution of entities presents in WEB-INF.
That's strange since in Tomcat 5, the resolver is under
o.a.c.u.SchemaResolver. Have you change something there? You should
customize that class instead of the Digester one (will be easier and
doesn't require commons-dev folks).
Nope, I'm using a standard TC 5.0.12 from inside my Eclipse IDE.
I double check another time today...
BTW, my webapp is not in c:/jakarta-tomcat-5.0.12/webapps but in
c:\eclipse\workspace\customer\webapp.
So in server.xml I've got :
Context path=/myapp docBase=c:\eclipse\workspace\customer\webapp
debug=99
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] IndexOutOfBoundsException from CharChunk
Kin-Man Chung wrote: I don't know much about the test; it is one of stress test we have, but it should not affect CharChunk this way, right, even if it has something weird? Like I said, this happens only in this test, and not always reproducible, so I am not surprised that nobody noticed it in 4.1. I thought it might be thread related, but each thread should have its own CharChunk instance, so I can't see how. I look into this more and report back. Bug 23805 could be related to this, and I'm awaiting more details. At least, the offset numbers do match, which is too big a coincidence ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
As described above, you're trying to use an illegal URL, which goes above the top of the webapp's namespace. You'll need to use absolute file: or http: type URLs, or provide your own EntityResolver that does whatever you want it to do. The only way to developpers and admins to have it works in both case is to set the current directory when web.xml is parsed to WEB-INF/. Ok, it seems to works for external entities inside the webapp, I wonder what was damaged in my previous tests ? BTW, I think I could use the multiples configuration offered by TC 5 : $CATALINA_HOME/conf/[enginename]/[hostname]/ directory Context ... Parameter name=companyName value=My Company, Incorporated override=false/ /Context Did the server.xml could use external entities using the relative tweak and if so what the currentDir at server.xml parsing time ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation
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=23805. 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=23805 Possible error in response wrapper implementation --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 09:26 --- Created an attachment (id=8582) OutputStream of the ResponseWrapper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation
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=23805. 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=23805 Possible error in response wrapper implementation --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 09:27 --- Yes, Jasper calls my output stream with bad parameters, it calls the write(byte[] b, int offset, int len) method with an array width 8192 bytes and an offset=8192. A stacktrace: java.lang.StringIndexOutOfBoundsException: String index out of range: 8192 at java.lang.String.getChars(String.java:484) at java.io.CharArrayWriter.write(CharArrayWriter.java:107) at com.tissat.isum.presentation.ISUMServletOutputStream.write(Unknown Source) at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336) at sun.nio.cs.StreamEncoder$CharsetSE.implWrite(StreamEncoder.java:395) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:136) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:191) at java.io.BufferedWriter.write(BufferedWriter.java:170) at java.io.PrintWriter.write(PrintWriter.java:200) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:306) at java.io.PrintWriter.write(PrintWriter.java:200) at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:159) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:355) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:366) at org.apache.jasper.runtime.JspWriterImpl.print(JspWriterImpl.java:491) at com.tissat.isum.presentation.taglib.ChildrenServicesTag.m1(Unknown Source) at com.tissat.isum.presentation.taglib.ChildrenServicesTag.doAfterBody(Unknown Source) at org.apache.jsp.interfaces.inttissat.LeftG_jsp._jspService(LeftG_jsp.java:302) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) ... ... ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21763] - Tomcat 4.1.24 hangs under heavy load using http connector.
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=21763. 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=21763 Tomcat 4.1.24 hangs under heavy load using http connector. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 09:28 --- Seeing what you describe, I doubt this is caused by this problem (this report was about much higher load factors, 10 req/s is very low). If you have contention or deadlocks elsewhere, the symptoms will be the same (more processors will be created to handle the incoming requests). Get a thread dump, which could indicate where the contention is. You should discuss this in tomcat-user, since the cause of your problem is not likely this particular flaw of the thread pool. Allowing unlimited processors to get around this kind of issue could bring your whole server to its knees, and is a bad idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation
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=23805. 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=23805 Possible error in response wrapper implementation --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 09:40 --- Thanks. This is indeed the same issue that was reported a few days ago by Kin-Man. About the JSP which causes this: what does it look like ? Is it caused by a static content block 8KB ? Can you submit a test JSP to reproduce the issue ? If you can't, the stack trace should be enough by itself to fix it, though. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation
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=23805. 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=23805 Possible error in response wrapper implementation --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 09:55 --- Sorry, I can't send you the JSP, I haven't permission :( The JSP that causes the problem generates its content dinamically and it fails when generates over 8kb. Thanks a lot and sorry, my english is not good :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation
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=23805. 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=23805 Possible error in response wrapper implementation --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 10:11 --- Well, judging from the stack trace, you (com.tissat.isum.presentation.ISUMServletOutputStream) are calling the CharArrayWriter with the wrong parameters. I suspect the bug is there, not in Jasper. Please submit both * what ISUMServletOutputStream gets called with (offset=8192 AND length) * what ISUMServletOutputStream passes to the CharArrayWriter (String, offset and length) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JAVA_ENDORSED_DIRS in catalina
Hi, Should we set JAVA_ENDORSED_DIRS to a default value of $CATALINA_HOME/common/endorsed in the startup scripts? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23831] New: - problem using mod_jk2 connector with Apache and Tomcat
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=23831. 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=23831 problem using mod_jk2 connector with Apache and Tomcat Summary: problem using mod_jk2 connector with Apache and Tomcat Product: Tomcat 4 Version: 4.1.27 Platform: PC OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've a problem with mod_jk2 connector (2.0.2) with Apache 2.0.43 and Tomcat 4.1.27. After a bit, log file (error_log) writes this lines: [Wed Oct 15 12:08:32 2003] [error] Error ajp_process_callback - write failed [Wed Oct 15 12:08:32 2003] [error] ajp13.service() ajpGetReply recoverable error 3 [Wed Oct 15 12:08:32 2003] [error] Error ajp_process_callback - write failed [Wed Oct 15 12:08:32 2003] [error] ajp13.service() ajpGetReply recoverable error 3 [Wed Oct 15 12:08:32 2003] [error] ajp13.service() Error forwarding ajp13:localhost:8009 1 0 [Wed Oct 15 12:08:32 2003] [error] mod_jk.handler() Error connecting to tomcat 3 This's my configuration files: * BEGIN jk2.properties handler.list=apr,channelSocket,request channelSocket.port=8009 serverRoot=/usr/local/apache apr.NativeSo = /usr/local/apache/modules/jkjni.so * ENDjk2.properties * BEGIN workers2.properties # Shared memory handling. [shm:] file=/usr/local/apache/conf/shm.file size=1048576 [config] file=/usr/local/apache/conf/workers2.properties debug=10 debugEnv=10 [channel.socket:localhost:8009] port=8009 host=127.0.0.1 tomcatId=localhost:8009 [ajp13:localhost:8009] channel=channel.socket:localhost:8009 # Uri mapping. [uri:/*] worker=ajp13:localhost:8009 * END workers2.properties * BEGIN server.xml Server port=8005 shutdown=SHUTDOWN debug=0 Service name=Tomcat-Apache Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 minProcessors=20 maxProcessors=200 acceptCount=10 debug=0 address=127.0.0.1/ Engine name=Server defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.log timestamp=true/ Realm className=org.apache.catalina.realm.MemoryRealm / Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_log. suffix=.log timestamp=true/ Context path= docBase= debug=0/ /Host /Engine /Service /Server * END server.xml The strange think is that until a few day ago this server isn't problems. Please help me Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation
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=23805. 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=23805 Possible error in response wrapper implementation --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 13:22 --- ISUMServletOutputStream is submited. Enter to bugzilla to access it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk/jk2 - time for apr
Hi to all, Now that jk seems stabilized a bit, should we focalize on jk2 ? For instance I added some features to jk (ping/pong) which should be ported to jk2. Also I wonder if APR is mandatory for jk2. I'd like to use APR as a facade to all Operating System calls. The goal is to hide all the complexity of Windows, iSeries, differents Unix implementations behind APR which is now stable and well diffused. As such it will be +1 to make APR mandatory and start modifying jk2, to make it use only APR call. But I'd like to have your opinion first. PS: For those of you who was here 2 or 3 years ago, the requirement of APR for mod_webapp got my total -1 at this time since it wasn't really available, but today that's completly different. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation
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=23805. 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=23805 Possible error in response wrapper implementation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 13:56 --- The exception says: String index out of range: 8192 According to String.java, this is because the end index is larger than the string length. So the String you make from the bytes is shorter than 8192 chars. Your messing up bytes and chars here. Your outputstream converts the bytes to chars (e.g. does new String(bytes)) and assumes that the indices are still correct. I suspect that you * use UTF-8 encoding, where you typically have more bytes than chars * new String(bytes).length 8192 * you call writer.write(string, 8192, 0) and bang. In ISO-encoding, calling your stream with write(new byte[8192], 8192, 0) works perfectly fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk/jk2 - time for apr
+1 to have a version of mod_jk rewritten to use APR for all OS stuff It would be best to use the version of APR which is distributed with the current Apache 2 release so that there are no conflicts when using mod_jk with Apache 2. Requiring APR would allow using a global connection pool for the socket connections to Tomcat. And allow more sophisticated load balancing when you can have access to global information about how each pool of connectors to Tomcat is performing. If this involves significant changes to the code we might want to bump the major version to jk3. We will still need at least one more release of mod_jk 1.2 for the minor changes committed since the 1.2.5 release. Regards, Glenn Henri Gomez wrote: Hi to all, Now that jk seems stabilized a bit, should we focalize on jk2 ? For instance I added some features to jk (ping/pong) which should be ported to jk2. Also I wonder if APR is mandatory for jk2. I'd like to use APR as a facade to all Operating System calls. The goal is to hide all the complexity of Windows, iSeries, differents Unix implementations behind APR which is now stable and well diffused. As such it will be +1 to make APR mandatory and start modifying jk2, to make it use only APR call. But I'd like to have your opinion first. PS: For those of you who was here 2 or 3 years ago, the requirement of APR for mod_webapp got my total -1 at this time since it wasn't really available, but today that's completly different. - 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: Re: TOMCAT-fix for os/390??
Bill, thank you so much (so far :-) 4.1.28 starts up nicely and answers me - even if I only get half of the start page (index.jsp), and even if I cannot execute the XML example ... and so on. But at least this damned ebcdic-line-separator-problem is done away with Anna PS: I submitted a mail about a functioning (?) tomcat on os/390 in marist's open-mvs mailing list where a lot of people ask about tomcat; I suppose I may forward this 4.1.28-link to them? - Original Message - From: Bill Barker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 10, 2003 10:06 AM Subject: Re: Re: TOMCAT-fix for os/390?? Try http://www.apache.org/dist/jakarta/tomcat-4/v4.1.28-alpha/. The 'alpha' is just because it is still in it's evaluation stage. It's likely to graduate to at least beta (if not 'stable'). However, your ability to test it on an os/390 system makes you particularly valuable to the developers, so I hope that you will try it out :). - Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 10, 2003 12:35 AM Subject: Re: Re: TOMCAT-fix for os/390?? Well well ... being a simpleton (=user) I don't quite manage to manage cvs ... I would love to install tomcat 4.1.28 (having 4.1.27), bit I cannot find such a distribution. So what it boils down to if I cannot get 4.1.28 is: install rls 6 BETA - does it go well with JDK 1.3? thank you very much for your help Anna Von: Dirk Verbeeck [EMAIL PROTECTED] Datum: 2003/10/09 Do PM 10:53:59 GMT+02:00 An: Tomcat Developers List [EMAIL PROTECTED] Betreff: Re: TOMCAT-fix for os/390?? Hi Anna I don't use tomcat on os390 but by reading you problem I suspect your problem is solved in cvs, you need at least revision 1.16.2.1 http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat-connectors/http 11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java?rev=1.16.2.1 or 1.18 http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat-connectors/http 11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java?rev=1.18 of the following file: http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java Releases including this fix are TOMCAT_5_0_13 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_5_0_13 , TOMCAT_5_0_12 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_5_0_12 , TOMCAT_4_1_28 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_4_1_28 Cheers Dirk Anna Fuhrmann wrote: Hi all, like a good girl I have been using the user-mailing-list up to now to search for user experience installing tomcat on os390. Most (if not all) contributions are in the form has anyone successfully installed tomcat on os390? From some other I got partly valuable ideas. I have been TRYING to get tomcat run on os390 in the last couple of days. Done everything I could - everything seems to be allright up to this pont: tomcat IS running at last without any serious signs of disbehaviour - no error messages at all, xml's behaving well. But if we connect to localhost:tomcatport/index.jsp (or wahtever else for that matter), the browser does not show anything. Doing the same with a perl script shows that the server is ansering and is supplying the requested page, BUT EACH LINE OF THE HTTP_HEADER CONTAINS AN INVALID (i.e.: ebcdic) LINE SEPARATOR. So thats the reason why. Today I tried to identify the .java-file giving us the header (looking for \r\n) . I thought I found it, by my hex.editor did not show me any 0x0d15 (which ought to be the suspect, i.e. Newline in ebcdic). What I would like to know: Is there any kind of patch for os/390? Do you have any suggestions? Is anybody working on it? What should I do? I want to have this beast running. PLEASE. We have os390 2.10 IBM-JDK 1.3 tomcat 4.1.27 Anna Fuhrmann - 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] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain
RE: jk/jk2 - time for apr
+1 to use the APR as mandatory for the mod_jk. You can rename it to the mod_jk2 after that easily :-) MT. -Original Message- From: Henri Gomez Hi to all, Now that jk seems stabilized a bit, should we focalize on jk2 ? For instance I added some features to jk (ping/pong) which should be ported to jk2. Also I wonder if APR is mandatory for jk2. I'd like to use APR as a facade to all Operating System calls. The goal is to hide all the complexity of Windows, iSeries, differents Unix implementations behind APR which is now stable and well diffused. As such it will be +1 to make APR mandatory and start modifying jk2, to make it use only APR call. But I'd like to have your opinion first. PS: For those of you who was here 2 or 3 years ago, the requirement of APR for mod_webapp got my total -1 at this time since it wasn't really available, but today that's completly different. - 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]
[5.0] System properties in server.xml (and elsewhere)
Hi, I think it would be possible, using a new rule, to allow system properties inside server.xml (and possibly elsewhere) for attribute values. This is the same as what is being done by Ant in its build scripts. This would add an additional degree of configurability to Tomcat. Actually, I wonder why this feature is not available in the digester itself (I really got used to that feature over the years by using Ant). Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation
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=23805. 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=23805 Possible error in response wrapper implementation [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 14:30 --- Wait a minute. I believe there's likely a real bug there. If the byte array is 8K long, and the offset is 8K, then there's a problem. I agree that converting to a String like that is bad, but this doesn't change the fact that the args seem bogus. As I said, this also looks very similar to Kin-Man's problem, so I think this bug should stay open a bit longer (I didn't really look into the issue yet). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] System properties in server.xml (and elsewhere)
+0 (I'd be +1 if I could actually be of help - but love the idea) -Tim Remy Maucherat wrote: Hi, I think it would be possible, using a new rule, to allow system properties inside server.xml (and possibly elsewhere) for attribute values. This is the same as what is being done by Ant in its build scripts. This would add an additional degree of configurability to Tomcat. Actually, I wonder why this feature is not available in the digester itself (I really got used to that feature over the years by using Ant). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] System properties in server.xml (and elsewhere)
Howdy, If it's easy, +1 ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 10:24 AM To: Tomcat Developers List Subject: [5.0] System properties in server.xml (and elsewhere) Hi, I think it would be possible, using a new rule, to allow system properties inside server.xml (and possibly elsewhere) for attribute values. This is the same as what is being done by Ant in its build scripts. This would add an additional degree of configurability to Tomcat. Actually, I wonder why this feature is not available in the digester itself (I really got used to that feature over the years by using Ant). Comments ? 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: jk/jk2 - time for apr
Mladen Turk a écrit : +1 to use the APR as mandatory for the mod_jk. You can rename it to the mod_jk2 after that easily :-) Heu, the idea is to make jk2 (native2) apr mandatory. We'll keep jk as it is today. * the plan - update jk2 (native2) to use APR only - port jk add-ons like ping/pong to jk2 - test, test and re-test - mark jk as deprecated The rule will be to use the latest APR release, ie the one which goes with the latest Apache 2.0 release. We could handle more recent APR via : /* deprecated with apr 0.9.3 */ #include apr_version.h #if (APR_MAJOR_VERSION == 0) \ (APR_MINOR_VERSION = 9) \ (APR_PATCH_VERSION 3) #define apr_filepath_name_get apr_filename_of_pathname #endif It will make jk2 ideally suited for Apache 2, and since we could find apr.dll for Windows Box, it should be usable with IIS (Domino ?). I'd like to have comments from Nacho, JF Clere and Mike Anderson who are working of jk on others platforms/webservers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] System properties in server.xml (and elsewhere)
Remy Maucherat a écrit :
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its build
scripts. This would add an additional degree of configurability to Tomcat.
Actually, I wonder why this feature is not available in the digester
itself (I really got used to that feature over the years by using Ant).
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
A big +1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp AsyncSocketSender.java IDataSender.java ReplicationTransmitter.java SocketSender.java
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 5:21 AM
Subject: cvs commit:
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/tcp AsyncSocketSender.java IDataSender.java ReplicationTransmitter.java
SocketSender.java
fhanik 2003/10/14 20:21:04
Modified:modules/cluster/src/share/org/apache/catalina/cluster/tcp
AsyncSocketSender.java IDataSender.java
ReplicationTransmitter.java SocketSender.java
Log:
added in the suspect feature to avoid to much error printing
Revision ChangesPath
1.2 +15 -3
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/tcp/AsyncSocketSender.java
Index: AsyncSocketSender.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catal
ina/cluster/tcp/AsyncSocketSender.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AsyncSocketSender.java 18 Apr 2003 02:51:24 - 1.1
+++ AsyncSocketSender.java 15 Oct 2003 03:21:04 - 1.2
@@ -73,6 +73,7 @@
private Socket sc = null;
private boolean isSocketConnected = false;
private SmartQueue queue = new SmartQueue();
+private boolean suspect;
public AsyncSocketSender(InetAddress host, int port) {
this.address = host;
@@ -137,6 +138,17 @@
StringBuffer buf = new StringBuffer(SocketSender[);
buf.append(getAddress()).append(:).append(getPort()).append(]);
return buf.toString();
+}
+public boolean isSuspect() {
+return suspect;
+}
+
+public boolean getSuspect() {
+return suspect;
+}
+
+public void setSuspect(boolean suspect) {
+this.suspect = suspect;
}
private class QueueThread extends Thread {
1.3 +5 -3
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/tcp/IDataSender.java
Index: IDataSender.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catal
ina/cluster/tcp/IDataSender.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- IDataSender.java 18 Apr 2003 02:51:24 - 1.2
+++ IDataSender.java 15 Oct 2003 03:21:04 - 1.3
@@ -80,4 +80,6 @@
public void disconnect();
public void sendMessage(String sessionId, byte[] data) throws
java.io.IOException;
public boolean isConnected();
+public void setSuspect(boolean suspect);
+public boolean getSuspect();
}
1.6 +11 -8
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/tcp/ReplicationTransmitter.java
Index: ReplicationTransmitter.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catal
ina/cluster/tcp/ReplicationTransmitter.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ReplicationTransmitter.java 18 Apr 2003 02:51:24 - 1.5
+++ ReplicationTransmitter.java 15 Oct 2003 03:21:04 - 1.6
@@ -147,18 +147,21 @@
public void sendMessage(String sessionId, byte[] indata) throws
java.io.IOException
{
-java.util.Iterator i = map.entrySet().iterator();
-java.util.Vector v = new java.util.Vector();
+ IDataSender[] senders = getSenders();
byte[] data = XByteBuffer.createDataPackage(indata);
-while ( i.hasNext() )
+for ( int i=0; isenders.length; i++ )
{
-IDataSender sender =
(IDataSender)((java.util.Map.Entry)i.next()).getValue();
+
+IDataSender sender = senders[i];
try
{
sendMessageData(sessionId,data,sender);
+sender.setSuspect(false);
}catch ( Exception x)
{
-log.warn(Unable to send replicated message to
+sender+, is server down?,x);
+
+if ( !sender.getSuspect()) log.warn(Unable to send
replicated message to +sender+, is server down?,x);
+sender.setSuspect(true);
}
}//while
}
1.3 +15 -3
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/tcp/SocketSender.java
Index: SocketSender.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catal
ina/cluster/tcp/SocketSender.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SocketSender.java 18 Apr
DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation
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=23805.
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=23805
Possible error in response wrapper implementation
--- Additional Comments From [EMAIL PROTECTED] 2003-10-15 14:48 ---
As long as 'len==0' this would be ok. And the exception seems to indicate
exactly that. String.java#getChars, line 484, barfs about the end index (8192)
being larger than the string size.
I would propose the following change to rijmenez's class:
write(byte[] b, int off, int len) {
- writer.write(new String(b), off, len);
+ writer.write(new String(b, off, len));
}
If that doesn't solve the issue, I'm wrong.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] System properties in server.xml (and elsewhere)
Henri Gomez wrote:
Remy Maucherat a écrit :
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its build
scripts. This would add an additional degree of configurability to
Tomcat.
Actually, I wonder why this feature is not available in the digester
itself (I really got used to that feature over the years by using Ant).
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can put
${foo.bar} in server.xml, and it will be replaced with the property
value (like in Ant). I didn't know this was present in 3.3.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation
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=23805. 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=23805 Possible error in response wrapper implementation --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 15:01 --- Well. I believe that Matthias has reason, my code has this bug. The other problem commented by Remy, I believe that this problem does not causes an exception, simply that we can not change the JSP buffer (by default 8kb). Thanks for all - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] System properties in server.xml (and elsewhere)
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can put
${foo.bar} in server.xml, and it will be replaced with the property
value (like in Ant). I didn't know this was present in 3.3.
Yes it was in TC 3.3.1 and you could also set the properties in the
command line if I recall well ;)
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_tomcat
...
In Tomcat 3.3.1, each attribute value may use the ant-style variable
substitution by using ${variable} in the attribute string, i.e.
attribute=text${variable}text.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23841] New: - More specific error message to org.apache.jasper.JasperException: Exception thrown by getter for property ...
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=23841. 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=23841 More specific error message to org.apache.jasper.JasperException: Exception thrown by getter for property ... Summary: More specific error message to org.apache.jasper.JasperException: Exception thrown by getter for property ... Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] org.apache.jasper.JasperException: Exception thrown by getter for property expireDate of bean MSGVIEW at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:254) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) ... root cause javax.servlet.ServletException: Exception thrown by getter for property expireDate of bean MSGVIEW at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:533) at org.apache.jsp.outboxmessage_en_jsp._jspService(outboxmessage_en_jsp.java:646) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:210) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) what was wrong with that getter method? Since an exception was thrown, it is certainly possible to tell why! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] System properties in server.xml (and elsewhere)
Henri Gomez wrote:
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can put
${foo.bar} in server.xml, and it will be replaced with the property
value (like in Ant). I didn't know this was present in 3.3.
Yes it was in TC 3.3.1 and you could also set the properties in the
command line if I recall well ;)
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_tomcat
...
In Tomcat 3.3.1, each attribute value may use the ant-style variable
substitution by using ${variable} in the attribute string, i.e.
attribute=text${variable}text.
Let me guess. James did code all that stuff aeons ago, right ? :-D
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] System properties in server.xml (and elsewhere)
Remy Maucherat a écrit :
Henri Gomez wrote:
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can
put ${foo.bar} in server.xml, and it will be replaced with the
property value (like in Ant). I didn't know this was present in 3.3.
Yes it was in TC 3.3.1 and you could also set the properties in the
command line if I recall well ;)
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_tomcat
...
In Tomcat 3.3.1, each attribute value may use the ant-style variable
substitution by using ${variable} in the attribute string, i.e.
attribute=text${variable}text.
Let me guess. James did code all that stuff aeons ago, right ? :-D
James ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk/jk2 - time for apr
Henri Gomez wrote: Mladen Turk a écrit : +1 to use the APR as mandatory for the mod_jk. You can rename it to the mod_jk2 after that easily :-) Heu, the idea is to make jk2 (native2) apr mandatory. We'll keep jk as it is today. * the plan - update jk2 (native2) to use APR only - port jk add-ons like ping/pong to jk2 - test, test and re-test - mark jk as deprecated The rule will be to use the latest APR release, ie the one which goes with the latest Apache 2.0 release. We could handle more recent APR via : /* deprecated with apr 0.9.3 */ #include apr_version.h #if (APR_MAJOR_VERSION == 0) \ (APR_MINOR_VERSION = 9) \ (APR_PATCH_VERSION 3) #define apr_filepath_name_get apr_filename_of_pathname #endif It will make jk2 ideally suited for Apache 2, and since we could find apr.dll for Windows Box, it should be usable with IIS (Domino ?). I'd like to have comments from Nacho, JF Clere and Mike Anderson who are working of jk on others platforms/webservers. Using APR is a good idea but that is a lot of work. I have APR on all my strange platforms so no problem for me :-) I was quite unhappy with the -1 on APR/mod_webapp but all the problems of APR years ago have contribued to make mod_webapp deprecated... We have to be carefull with the threads... Specialy if we want to add the feature to (re)start Tomcat automaticly from httpd. - 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: jk/jk2 - time for apr
jean-frederic clere a écrit : Henri Gomez wrote: Mladen Turk a écrit : +1 to use the APR as mandatory for the mod_jk. You can rename it to the mod_jk2 after that easily :-) Heu, the idea is to make jk2 (native2) apr mandatory. We'll keep jk as it is today. * the plan - update jk2 (native2) to use APR only - port jk add-ons like ping/pong to jk2 - test, test and re-test - mark jk as deprecated The rule will be to use the latest APR release, ie the one which goes with the latest Apache 2.0 release. We could handle more recent APR via : /* deprecated with apr 0.9.3 */ #include apr_version.h #if (APR_MAJOR_VERSION == 0) \ (APR_MINOR_VERSION = 9) \ (APR_PATCH_VERSION 3) #define apr_filepath_name_get apr_filename_of_pathname #endif It will make jk2 ideally suited for Apache 2, and since we could find apr.dll for Windows Box, it should be usable with IIS (Domino ?). I'd like to have comments from Nacho, JF Clere and Mike Anderson who are working of jk on others platforms/webservers. Using APR is a good idea but that is a lot of work. I have APR on all my strange platforms so no problem for me :-) iSeries is another quite exotic platform even if Rochester friends does a great job on Apache 2.0 integration on OS/400 ;) I was quite unhappy with the -1 on APR/mod_webapp but all the problems of APR years ago have contribued to make mod_webapp deprecated... At this time there wasn't an official APR release or official Apache 2 release, and webapp was using APR from HEAD CVS (with frequent changes). Now the situation is stabilized since major Linux distributions have Apache 2.0 bundled by default, so APR is allready available. We have to be carefull with the threads... Specialy if we want to add the feature to (re)start Tomcat automaticly from httpd. We should, allways, be very carefull with threads ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk/jk2 - time for apr
I'm +1 on moving jk2 (native2) to APR. I haven't had a lot of time to play with jk2, but I have seen that there are some issues with it on NetWare (something about it allocating stuff when Apache 2 initializes it's 1st load and then expecting that stuff to still be around when it comes up for real.) If jk2 is going to be the direction moving forward (which I believe is appropriate) I (or someone here at Novell) will have to address that before we can fully support it. Hopefully, moving to APR will ease that somewhat. Mike Anderson [EMAIL PROTECTED] 10/15/2003 9:48:40 AM jean-frederic clere a écrit : Henri Gomez wrote: Mladen Turk a écrit : +1 to use the APR as mandatory for the mod_jk. You can rename it to the mod_jk2 after that easily :-) Heu, the idea is to make jk2 (native2) apr mandatory. We'll keep jk as it is today. * the plan - update jk2 (native2) to use APR only - port jk add-ons like ping/pong to jk2 - test, test and re-test - mark jk as deprecated The rule will be to use the latest APR release, ie the one which goes with the latest Apache 2.0 release. We could handle more recent APR via : /* deprecated with apr 0.9.3 */ #include apr_version.h #if (APR_MAJOR_VERSION == 0) \ (APR_MINOR_VERSION = 9) \ (APR_PATCH_VERSION 3) #define apr_filepath_name_get apr_filename_of_pathname #endif It will make jk2 ideally suited for Apache 2, and since we could find apr.dll for Windows Box, it should be usable with IIS (Domino ?). I'd like to have comments from Nacho, JF Clere and Mike Anderson who are working of jk on others platforms/webservers. Using APR is a good idea but that is a lot of work. I have APR on all my strange platforms so no problem for me :-) iSeries is another quite exotic platform even if Rochester friends does a great job on Apache 2.0 integration on OS/400 ;) I was quite unhappy with the -1 on APR/mod_webapp but all the problems of APR years ago have contribued to make mod_webapp deprecated... At this time there wasn't an official APR release or official Apache 2 release, and webapp was using APR from HEAD CVS (with frequent changes). Now the situation is stabilized since major Linux distributions have Apache 2.0 bundled by default, so APR is allready available. We have to be carefull with the threads... Specialy if we want to add the feature to (re)start Tomcat automaticly from httpd. We should, allways, be very carefull with threads ;) - 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]
DO NOT REPLY [Bug 23831] - problem using mod_jk2 connector with Apache and Tomcat
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=23831. 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=23831 problem using mod_jk2 connector with Apache and Tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 16:08 --- Some strange problems with Apache and Tomcat...After some time and server-stress, Apache doesn't response to requests which are routed to tomcat...Another ... There're much more java (35 processes) and apache (20 proc) processes running on my server ... and with netstat command I have almost 20 internet connection to 8009 port It's strange ... I think that tomcat not release connection after use...is it possible ??! Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk loadbalancer questions
I am using mod_jk 1.2.5 w/Apache 1.3.28, talking to JBoss w/integrated Tomcat 4.1.24. I am attempting to use the lb worker to load balance across two instances of Tomcat. I will eventually do this against as many as 5 Tomcat instances. I am having limited success getting an equal distribution of sessions. I know it will never be exactly equal, but one box is consistently receiving an inordinate amount of the the load. My workers.properties looks like: worker.list.loadbalancer, load1, load2 worker.load1.port=8009 worker.load1.host=load1 worker.load1.type=ajp13 worker.load1.lbfactor=10 worker.load1.cachesize=10 worker.load1.cache_timeout=600 worker.load1.socket_keepalive=1 worker.load1.socket_timeout=300 (load2 is the same, except for the .host) I load-balance the http requests via a hardware round-robin. Both hosts have identical workers.properties. First, I'd like to clear up some questions about mod_jk itself (these are source code related, hence not posting to -user). The array which holds the workers (and their lb_value, factor, etc) seems to be a per-apache-process structure created in validate() of jk_lb_worker.c. So each apache process independently increments the lb_value in get_most_suitable_worker? Also, the jk_get_lb_worker_list function seems cause the first worker listed in balanced_workers property to be the 0th element of the p-lb_workers array. These two things (if correct) would cause each Apache process to choose the first worker in balanced_workers to handle the first request received, resulting in the first n sessions to be sent to the same box (where n is the number of apache processes). I'm not sure if Apache round-robins it's children... Obviously, newly created apache children will have no history of requests to base their get_most_suitable_worker on, and, if my above statement about the first balanced worker is correct, then they will send the first request to the first worker. If my number of initial apache servers is low, and my load is spikey, this could cause a burst of children to be born and send their first request to the same box. They would then die when the load subsides. Now, after the session ID is established, mod_jk is doing a fantastic job of sending the request to the proper servlet container. My problem is getting the 'new' users to distribute evenly between my two boxes. This imbalance only seems to manifest itself under heavy load, hence my ideas about apache children. I appreciate any clarification on this issue ;) Cory 'G' Watson http://www.loggerithim.org The universal aptitude for ineptitude makes any human accomplishment an incredible miracle. - Dr. John Paul Stapp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23831] - problem using mod_jk2 connector with Apache and Tomcat
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=23831. 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=23831 problem using mod_jk2 connector with Apache and Tomcat [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |High --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 16:13 --- Some strange problems with Apache and Tomcat...After some time and server-stress, Apache doesn't response to requests which are routed to tomcat...Another ... There're much more java (35 processes) and apache (20 proc) processes running on my server ... and with netstat command I have almost 20 internet connection to 8009 port It's strange ... I think that tomcat not release connection after use...is it possible ??! Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] No sessions purged in Context with backgroundProcessorDelay 0?
I may be totally wrong here, but it seems that if the
backgroundProcessorDelay property on a StandardContext is set to
something greater than zero (default is -1, inherited from
ContainerBase), the context's sessions are never purged.
This is because in ContainerBase$ContainerBackgroundProcessor,
processChildren() is implemented as follows:
for (int i = 0; i children.length; i++) {
if (children[i].getBackgroundProcessorDelay() = 0) {
processChildren(children[i], cl);
}
}
So when invoked from the ContainerBackgroundProcessor of a
StandardHost, only the sessions of those StandardContexts with a
backgroundProcessorDelay =0 will get purged.
I think the assumption is that if a StandardContext has a
backgroundProcessorDelay 0, it would have its own
ContainerBackgroundProcessor spawn at startup. However, unlike
StandardEngine/Host/Wrapper, StandardContext.start() does not invoke
super.start(), and therefore a ContainerBackgroundProcessor is never
created for a StandardContext.
Am I missing something here?
Thanks,
Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] No sessions purged in Context with backgroundProcessorDelay 0?
Jan Luehe wrote:
I may be totally wrong here, but it seems that if the
backgroundProcessorDelay property on a StandardContext is set to
something greater than zero (default is -1, inherited from
ContainerBase), the context's sessions are never purged.
This is because in ContainerBase$ContainerBackgroundProcessor,
processChildren() is implemented as follows:
for (int i = 0; i children.length; i++) {
if (children[i].getBackgroundProcessorDelay() = 0) {
processChildren(children[i], cl);
}
}
So when invoked from the ContainerBackgroundProcessor of a
StandardHost, only the sessions of those StandardContexts with a
backgroundProcessorDelay =0 will get purged.
I think the assumption is that if a StandardContext has a
backgroundProcessorDelay 0, it would have its own
ContainerBackgroundProcessor spawn at startup. However, unlike
StandardEngine/Host/Wrapper, StandardContext.start() does not invoke
super.start(), and therefore a ContainerBackgroundProcessor is never
created for a StandardContext.
Arg, stupid me, I forgot about that. We need to add the code which
starts the backgroud thread in StandardContext.start.
So we need to call super.startThread() and super.stopThread. This
doesn't seem too hard.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19852] - When context reloaded the Parameters specified in server.xml for the Context are not availaple
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=19852. 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=19852 When context reloaded the Parameters specified in server.xml for the Context are not availaple [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Severity|Normal |Major --- Additional Comments From [EMAIL PROTECTED] 2003-10-15 16:42 --- This bug is causing me headaches and chronic disruption on a production server... As mentioned, the only way to get back to normal when it occurs is to restart Tomcat, which is pretty disruptive. I think Mikkel did a very good job on it, and nearly all information is available to fix it, IMHO. What about integrating his change ? TIA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] No sessions purged in Context with backgroundProcessorDelay 0?
Thanks for confirming, Remy!
I'll make these changes.
Jan
Remy Maucherat wrote:
Jan Luehe wrote:
I may be totally wrong here, but it seems that if the
backgroundProcessorDelay property on a StandardContext is set to
something greater than zero (default is -1, inherited from
ContainerBase), the context's sessions are never purged.
This is because in ContainerBase$ContainerBackgroundProcessor,
processChildren() is implemented as follows:
for (int i = 0; i children.length; i++) {
if (children[i].getBackgroundProcessorDelay() = 0) {
processChildren(children[i], cl);
}
}
So when invoked from the ContainerBackgroundProcessor of a
StandardHost, only the sessions of those StandardContexts with a
backgroundProcessorDelay =0 will get purged.
I think the assumption is that if a StandardContext has a
backgroundProcessorDelay 0, it would have its own
ContainerBackgroundProcessor spawn at startup. However, unlike
StandardEngine/Host/Wrapper, StandardContext.start() does not invoke
super.start(), and therefore a ContainerBackgroundProcessor is never
created for a StandardContext.
Arg, stupid me, I forgot about that. We need to add the code which
starts the backgroud thread in StandardContext.start.
So we need to call super.startThread() and super.stopThread. This
doesn't seem too hard.
Remy
-
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-catalina/catalina/src/share/org/apache/catalina/core ContainerBase.java StandardContext.java
luehe 2003/10/15 10:24:16
Modified:catalina/src/share/org/apache/catalina/core
ContainerBase.java StandardContext.java
Log:
Start/stop ContainerBackgroundProcessor thread as part of
StandardContext.start()/stop(), respectively.
Revision ChangesPath
1.29 +3 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java
Index: ContainerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- ContainerBase.java2 Sep 2003 21:22:04 - 1.28
+++ ContainerBase.java15 Oct 2003 17:24:16 - 1.29
@@ -1158,7 +1158,7 @@
// Notify our interested LifecycleListeners
lifecycle.fireLifecycleEvent(BEFORE_STOP_EVENT, null);
-// Stop out thread
+// Stop our thread
threadStop();
// Notify our interested LifecycleListeners
@@ -1583,7 +1583,7 @@
* Start the background thread that will periodically check for
* session timeouts.
*/
-private void threadStart() {
+protected void threadStart() {
if (thread != null)
return;
@@ -1603,7 +1603,7 @@
* Stop the background thread that is periodically checking for
* session timeouts.
*/
-private void threadStop() {
+protected void threadStop() {
if (thread == null)
return;
1.96 +7 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.95
retrieving revision 1.96
diff -u -r1.95 -r1.96
--- StandardContext.java 23 Sep 2003 09:07:37 - 1.95
+++ StandardContext.java 15 Oct 2003 17:24:16 - 1.96
@@ -4107,6 +4107,9 @@
((Lifecycle) getManager()).start();
}
+// Start ContainerBackgroundProcessor thread
+super.threadStart();
+
} finally {
// Unbinding thread
unbindThread(oldCCL);
@@ -4294,6 +4297,9 @@
// Finalize our character set mapper
setCharsetMapper(null);
+
+// Stop ContainerBackgroundProcessor thread
+super.threadStop();
if ((manager != null) (manager instanceof Lifecycle)) {
((Lifecycle) manager).stop();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session SimpleTcpReplicationManager.java
fhanik 2003/10/15 11:11:49
Modified:modules/cluster/src/share/org/apache/catalina/cluster/session
SimpleTcpReplicationManager.java
Log:
removed the session replication upon session creation, this happens at the end of
the request anyway
Revision ChangesPath
1.14 +26 -24
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/SimpleTcpReplicationManager.java
Index: SimpleTcpReplicationManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/SimpleTcpReplicationManager.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- SimpleTcpReplicationManager.java 14 Oct 2003 22:40:34 - 1.13
+++ SimpleTcpReplicationManager.java 15 Oct 2003 18:11:49 - 1.14
@@ -145,15 +145,15 @@
protected boolean distributable = true;
protected org.apache.catalina.cluster.tcp.SimpleTcpCluster cluster;
-
+
protected java.util.HashMap invalidatedSessions = new java.util.HashMap();
-
+
/**
* Flag to keep track if the state has been transferred or not
* Assumes false.
*/
protected boolean stateTransferred = false;
-
+
/**
* Constructor, just calls super()
*
@@ -206,12 +206,12 @@
*/
public void unload() throws IOException {
if ( !getDistributable() ) {
-super.unload();
+super.unload();
}
}
public void load() throws ClassNotFoundException, IOException {
if ( !getDistributable() ) {
-super.load();
+super.load();
}
}
public int getDebug()
@@ -270,11 +270,13 @@
if ( notify (cluster!=null) )
{
//notify javagroups
-SessionMessage msg = new SessionMessage(this.name,
-
SessionMessage.EVT_SESSION_CREATED,
-writeSession(session),
-session.getId());
-cluster.send(msg);
+
+//SessionMessage msg = new SessionMessage(this.name,
+//
SessionMessage.EVT_SESSION_CREATED,
+//writeSession(session),
+//session.getId());
+//cluster.send(msg);
+((ReplicatedSession)session).setIsDirty(true);
}
return (session);
}//createSession
@@ -300,22 +302,22 @@
add(session);
return session;
}
-
+
public void sessionInvalidated(String sessionId) {
synchronized ( invalidatedSessions ) {
invalidatedSessions.put(sessionId, sessionId);
}
}
-
+
public String[] getInvalidatedSessions() {
synchronized ( invalidatedSessions ) {
String[] result = new String[invalidatedSessions.size()];
invalidatedSessions.values().toArray(result);
return result;
}
-
+
}
-
+
public SessionMessage requestCompleted(String sessionId)
{
if ( !getDistributable() ) {
@@ -341,12 +343,12 @@
if (session != null) {
//return immediately if the session is not dirty
if (useDirtyFlag (!session.isDirty())) {
-//but before we return doing nothing,
+//but before we return doing nothing,
//see if we should send
//an updated last access message so that
//sessions across cluster dont expire
long interval = session.getMaxInactiveInterval();
-long lastaccdist = System.currentTimeMillis() -
+long lastaccdist = System.currentTimeMillis() -
session.getLastAccessWasDistributed();
if ( ((interval*1000) / lastaccdist) 3 ) {
SessionMessage accmsg = new SessionMessage(name,
@@ -358,7 +360,7 @@
}
return null;
}
-
+
session.setIsDirty(false);
if (getDebug() 5) {
try {
@@ -427,7 +429,7 @@
{
java.io.ByteArrayInputStream session_data = new
java.io.ByteArrayInputStream(data);
ReplicationStream session_in = new
Re: [5] IndexOutOfBoundsException from CharChunk
I believe 23805 is unrelated to my problem, and may even be invalid. Mine comes from CharChunk. To refresh the memory, the stack trace is Servlet.service() for servlet jsp threw exception java.lang.IndexOutOfBoundsException at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:132) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:191) at org.apache.tomcat.util.buf.WriteConvertor.write(C2BConverter.java:228 ) at org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:120 ) at org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.ja va:606) at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:463) at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:357) at org.apache.coyote.tomcat5.CoyoteWriter.flush(CoyoteWriter.java:117) at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:203) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary .java:990) ... In my case, it's not the offset, but end that is too big. It got the value of 16384 when limit is only 8192. I have looked into this more without getting more insight. I use jdb to catch IndexOutOfBoundsException but couldn't figure out what caused end to get this big. Since this happens randomly, I cannot stop a thread and follow its progress. Inserting prints in CharChunk was also not useful, since values for end in threads appear normal until the exception occurs, as if its value were clobbered by a strayed pointer (like in C). The print did show that in some cases, the value for end is 16384 after write(char[]) was invoked, though that didn't cause any exception for some reason. This turns out to be more elusive that it appears. I might have to give this up as another mystery of the universe. :-) -Kin-man Date: Wed, 15 Oct 2003 10:36:01 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: [5] IndexOutOfBoundsException from CharChunk To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: I don't know much about the test; it is one of stress test we have, but it should not affect CharChunk this way, right, even if it has something weird? Like I said, this happens only in this test, and not always reproducible, so I am not surprised that nobody noticed it in 4.1. I thought it might be thread related, but each thread should have its own CharChunk instance, so I can't see how. I look into this more and report back. Bug 23805 could be related to this, and I'm awaiting more details. At least, the offset numbers do match, which is too big a coincidence ;-) Remy - 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-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteResponse.java
jfarcand2003/10/15 11:47:49
Modified:catalina/src/share/org/apache/catalina Wrapper.java
catalina/src/share/org/apache/catalina/core
StandardWrapper.java StandardWrapperValve.java
catalina/src/share/org/apache/coyote/tomcat5
CoyoteResponse.java
Log:
Better increment the error count value by incrementing the count everytime sendError
is invoked
Revision ChangesPath
1.3 +10 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Wrapper.java
Index: Wrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Wrapper.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Wrapper.java 29 Jan 2003 12:41:47 - 1.2
+++ Wrapper.java 15 Oct 2003 18:47:49 - 1.3
@@ -290,6 +290,12 @@
/**
+ * Increment the error count value used when monitoring.
+ */
+public void incrementErrorCount();
+
+
+/**
* Load and initialize an instance of this servlet, if there is not already
* at least one initialized instance. This can be used, for example, to
* load servlets that are marked in the deployment descriptor to be loaded
1.34 +11 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- StandardWrapper.java 24 Sep 2003 06:56:21 - 1.33
+++ StandardWrapper.java 15 Oct 2003 18:47:49 - 1.34
@@ -1424,6 +1424,13 @@
swValve.setErrorCount(errorCount);
}
+/**
+ * Increment the error count used for monitoring.
+ */
+public void incrementErrorCount(){
+swValve.setErrorCount(swValve.getErrorCount() + 1);
+}
+
public long getLoadTime() {
return loadTime;
}
1.23 +1 -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.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- StandardWrapperValve.java 2 Sep 2003 21:22:04 - 1.22
+++ StandardWrapperValve.java 15 Oct 2003 18:47:49 - 1.23
@@ -442,7 +442,6 @@
*/
private void exception(Request request, Response response,
Throwable exception) {
-errorCount++;
ServletRequest sreq = request.getRequest();
sreq.setAttribute(Globals.EXCEPTION_ATTR, exception);
1.10 +10 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteResponse.java
Index: CoyoteResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteResponse.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- CoyoteResponse.java 19 Sep 2003 22:03:07 - 1.9
+++ CoyoteResponse.java 15 Oct 2003 18:47:49 - 1.10
@@ -90,6 +90,7 @@
import org.apache.catalina.Connector;
import org.apache.catalina.Context;
import org.apache.catalina.HttpResponse;
+import org.apache.catalina.Wrapper;
import org.apache.catalina.util.CharsetMapper;
import org.apache.catalina.util.DateTool;
import org.apache.catalina.util.StringManager;
@@ -1149,6 +1150,11 @@
// Ignore any call from an included servlet
if (included)
return;
+
+Wrapper wrapper = getRequest().getWrapper();
+if (wrapper != null) {
+wrapper.incrementErrorCount();
+}
setError();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] System properties in server.xml (and elsewhere)
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 8:31 AM
Subject: Re: [5.0] System properties in server.xml (and elsewhere)
Henri Gomez wrote:
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can put
${foo.bar} in server.xml, and it will be replaced with the property
value (like in Ant). I didn't know this was present in 3.3.
Yes it was in TC 3.3.1 and you could also set the properties in the
command line if I recall well ;)
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_t
omcat
...
In Tomcat 3.3.1, each attribute value may use the ant-style variable
substitution by using ${variable} in the attribute string, i.e.
attribute=text${variable}text.
Let me guess. James did code all that stuff aeons ago, right ? :-D
Well, the aeons ago part is right ;-). But it was the other ant person
(Costin).
The guts of the 3.3 replacement is
o.a.t.u.IntrospectionUtils.replaceProperties, so most of the code is already
in Tomcat 5.
Remy
-
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]
RE: jk/jk2 - time for apr
-Original Message- From: Henri Gomez Mladen Turk a écrit : +1 to use the APR as mandatory for the mod_jk. You can rename it to the mod_jk2 after that easily :-) Heu, the idea is to make jk2 (native2) apr mandatory. We'll keep jk as it is today. And I was thinking you have all the time in the world ;-). * the plan - update jk2 (native2) to use APR only Well, that's mostly delete all outside HAS_APR. Other would be to use the full APR/APR-UTILS api where ever possible, like for shm, get rid of apr_pool wrapper, etc... AND of course drop the all unsupported channels like (fast unix sockets). (What about JNI? This is very non-portable due to forked servers, but that's another story). IIS and Apache2 uses the APR by default, as well as Apache1.3x (WIN32), so no problem there. - port jk add-ons like ping/pong to jk2 OK. - test, test and re-test OK. - mark jk as deprecated OK. The rule will be to use the latest APR release, ie the one which goes with the latest Apache 2.0 release. We could handle more recent APR via : /* deprecated with apr 0.9.3 */ #include apr_version.h #if (APR_MAJOR_VERSION == 0) \ (APR_MINOR_VERSION = 9) \ (APR_PATCH_VERSION 3) #define apr_filepath_name_get apr_filename_of_pathname #endif Why would you do that? Just use the post 0.9.3 API. It will make jk2 ideally suited for Apache 2, and since we could find apr.dll for Windows Box, it should be usable with IIS (Domino ?). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] System properties in server.xml (and elsewhere)
Remy Maucherat wrote: Hi, I think it would be possible, using a new rule, to allow system properties inside server.xml (and possibly elsewhere) for attribute values. This is the same as what is being done by Ant in its build scripts. This would add an additional degree of configurability to Tomcat. Makes sense to me. Actually, I wonder why this feature is not available in the digester itself (I really got used to that feature over the years by using Ant). Because nobody ever asked, or contributed a patch to make it so :-). Comments ? Remy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Resources only working in a specific context.
I had an issue with 4.1.27 with having a DefaultContext define a JDBC Resource. If the resource is defined in a specific Context everything is fine, but move it into DefaultContext or GobalResources and you get NullPointer Exceptions and so on. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23634 I was thinking about getting Tomcat source and looking at this myself - but I'm not sure where to start looking? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to make CLIENT-CERT protection work?
Consider the following scenario: 1. Client sends POST request (with content type other than application/x-www-form-urlencoded) to SSL-enabled server (with client auth turned off). 2. Server parses request header, and determines that the resource identified by the request-URI is CLIENT-CERT protected. 3. Server's SSLAuthenticator valve reinitiates SSL handshake, w/ client auth turned on. 4. The server sends its HelloRequest, and expects to read the client's ClientHello. However, what it gets is the POST request's body which hadn't been read yet. 5. SSL handshake fails. In order to avoid this problem, SSLAuthenticator.authenticate() clears the socket in the case of a POST request by reading the POST request's body *before* reinitiating the handshake. To read the POST body, it calls CoyoteRequest.getParameterMap(), which reads and processes the POST body only if the content type equals application/x-www-form-urlencoded. Therefore, the SSL re-handshake works according to plan if the content type equals application/x-www-form-urlencoded, but fails for any other content type. Should we always read the POST body in getParameterMap(), and cache it in a byte[] if content type is different from application/x-www-form-urlencoded, and have CoyoteRequest.getInputStream()/getReader() return wrappers around this byte[]? Any better suggestions? Thanks, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18967] - NullPointerException instead of error message when running JspC
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=18967. 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=18967 NullPointerException instead of error message when running JspC --- Additional Comments From [EMAIL PROTECTED] 2003-10-16 01:43 --- Created an attachment (id=8590) Instantiate errDispatcher up front instead of lazily - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/xdocs-faq connectors.xml misc.xml security.xml
funkman 2003/10/15 18:42:04 Modified:docs/faq connectors.html misc.html security.html docs/faq/printer connectors.html misc.html security.html xdocs-faq connectors.xml misc.xml security.xml Log: Clarify error handling, system.out, new links for connector, configure ip address for connector, restrict connections by ip address. Revision ChangesPath 1.7 +31 -1 jakarta-tomcat-site/docs/faq/connectors.html Index: connectors.html === RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/connectors.html,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- connectors.html 9 Sep 2003 01:21:38 - 1.6 +++ connectors.html 16 Oct 2003 01:42:04 - 1.7 @@ -15,7 +15,11 @@ ul li[link] a href=http://www.johnturner.com/howto/apache-tomcat-howto.html; -John Turner's HOWTO +John Turner's HOWTO, +/a also there is + +a href=http://johnturner.com/howto/apache2-tomcat4127-jk-rh9-howto.html; + Apache 2.0.47 / Tomcat 4.1.27 / mod_jk for Red Hat 9.0 /a /li li[link] @@ -117,6 +121,13 @@ /a /li + +li + a href=#bind + How do I bind to a specific ip address? + /a +/li + /ul /p /blockquote/td/tr/tabletable cellpadding=2 cellspacing=0 border=0trtd bgcolor=#525D76font face=arial,helvetica.sanserif color=#ffa name=AnswersstrongAnswers/strong/a/font/td/trtrtdblockquote @@ -293,6 +304,25 @@ codemod_jk.conf-auto/code and edit it manually to your preference. None of production tomcat installations really use codemod_jk.conf-auto/code as it is. + /divbr + + b style=font-size: larger +a name=bind +How do I bind to a specific ip address? +/a + /b + div style=padding-left : 20px; +Each Connector element allows an address property. For example: +div align=lefttable border=0 cellpadding=0 cellspacing=4trtd height=1 width=1 bgcolor=#023264img border=0 hspace=0 vspace=0 height=1 width=1 src=../images/void.gif/tdtd height=1 bgcolor=#023264img border=0 hspace=0 vspace=0 height=1 width=1 src=../images/void.gif/tdtd height=1 width=1 bgcolor=#023264img border=0 hspace=0 vspace=0 height=1 width=1 src=../images/void.gif/td/trtrtd width=1 bgcolor=#023264img border=0 hspace=0 vspace=0 height=1 width=1 src=../images/void.gif/tdtd height=1 bgcolor=#ffpre +lt;Connector className=org.apache.coyote.tomcat4.CoyoteConnector + address=192.168.1.1 + port=8080 minProcessors=5 maxProcessors=75 + enableLookups=true redirectPort=8443 + acceptCount=100 debug=0 connectionTimeout=2 + useURIValidationHack=false disableUploadTimeout=true /gt; +/pre/tdtd width=1 bgcolor=#023264img border=0 hspace=0 vspace=0 height=1 width=1 src=../images/void.gif/td/trtrtd height=1 width=1 bgcolor=#023264img border=0 hspace=0 vspace=0 height=1 width=1 src=../images/void.gif/tdtd height=1 bgcolor=#023264img border=0 hspace=0 vspace=0 height=1 width=1 src=../images/void.gif/tdtd height=1 width=1 bgcolor=#023264img border=0 hspace=0 vspace=0 height=1 width=1 src=../images/void.gif/td/tr/table/div + + /divbr 1.9 +42 -0 jakarta-tomcat-site/docs/faq/misc.html Index: misc.html === RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/misc.html,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- misc.html 28 Aug 2003 00:20:56 - 1.8 +++ misc.html 16 Oct 2003 01:42:04 - 1.9 @@ -119,6 +119,17 @@ What is codeElement web-app does not allow servlet here/code? /a /li +li + a href=#catalina.out +Where does System.out go? br +How do I rotate catalina.out? + /a +/li +li + a href=#getResourceAsStream +How do open a file for reading in my webapp? + /a +/li /ul /p @@ -330,6 +341,9 @@ lt;/error-pagegt; /pre +You may also catch error 500's as well as other specific exceptions or +exceptions which extend ttThrowable/tt. +br For more information, see the Servlet Specification for all the gory details of how you can play with this. /divbr @@ -579,6 +593,34 @@ your web.xml file is ok. /divbr + + b style=font-size: larger + a name=catalina.out +Where does System.out go? br +How do I rotate catalina.out? + /a + /b + div style=padding-left : 20px; +codeSystem.out/code and codeSystem.err/code both print to +catalina.out. But you can suppress this via the swallowOutput property and +sent to different log files. +br +
DO NOT REPLY [Bug 23759] - allow web.xml security-constraint to restrict by request-origin-host or used-port
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=23759. 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=23759 allow web.xml security-constraint to restrict by request-origin-host or used-port [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-16 01:45 --- Its in the FAQ now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18967] - NullPointerException instead of error message when running JspC
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=18967. 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=18967 NullPointerException instead of error message when running JspC --- Additional Comments From [EMAIL PROTECTED] 2003-10-16 02:07 --- The problem is that Compiler.errDispatcher is null when the Validator encounters the syntax error in the tag. Compiler only instantiates its errDispatcher in Compiler.compile(), even though Compiler.generateJava() also needs errDispatcher. This triggers a NullPointerException, for example, if JspC.processFile() invokes Compiler.generateJava() directly, then the JSP fails to validate. I believe that the best fix would be for Compiler to instantiate errDispatcher in its constructor, instead of instantiating it lazily. Even if lazy instantiation were correctly implemented, it would hardly be worth the trouble -- creating an ErrorDispatcher involves a very simple constructor, and the two objects created have very few members. Here is the graph of references: ++ Compilerv| .errorDispatcher -- ErrorDispatcher | .bundle -- ResourceBundle* | .errHandler -- DefaultErrorHandler | .err + * the ResourceBundle would have been loaded already anyway Given that analysis, I have submitted a patch to ensure that Compiler.errorDispatcher is not null by instantiating it in the constructor. The patch should apply to both Tomcat 4.1.24 and 4.1.27, since Compiler.java did not change between the two versions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23852] New: - soft link at Tomcat 4.1.27 does not work
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=23852. 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=23852 soft link at Tomcat 4.1.27 does not work Summary: soft link at Tomcat 4.1.27 does not work Product: Tomcat 4 Version: 4.1.27 Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I tried to use soft links to point java classes files from WEB-INF/classes to other directories but failed. The following is an example: At WEB-INF/classes, I create a soft link ln -s /d1/test/abc.class abc.class I am using Tomcat 4.1.27 and I have added the following in the webapp context: Context path=/servlets docBase=esdtech debug=0 reloadable=true crossContext=true Resources className=org.apache.naming.resources.FileDirContext allowLinking=true/ Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_servlets_log. suffix=.txt timestamp=true/ Ejb name=ejb/EmplRecord type=Entity home=com.wombat.empl.EmployeeRecordHome remote=com.wombat.empl.EmployeeRecord/ /Context - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SESSION REPLICATION: RedHat 9 and Sun JDK 1.4.2 do not like to play
All, I have an announcement to make since myself and some colleagues found during some serious debugging on why session replication failed miserably on their systems. When running session replication for Tomcat 4.1.24 (http://cvs.apache.org/~fhanik/) on Redhat 9 using Sun JDK 1.4.2 nothing works for me at home during my regression testing. As soon as I switch to IBM JDK 1.4.1 everything goes back to normal. The problem is that with the Sun JDK the Socket.getOutputStream().write() hangs and locks forever. I will add this to the Cluster FAQ for Tomcat 5. If you have any questions Important Note: Although I switched to IBM JDK 1.4.1 I did experience one core dump with the JDK, so at this point, I would not recommend anyone using RedHat 9 when running tomcat and session replication. For those of you who have tried other platforms,versions OS:s, let us know your experience Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk/jk2 - time for apr
Henri Gomez wrote: Hi to all, Now that jk seems stabilized a bit, should we focalize on jk2 ? For instance I added some features to jk (ping/pong) which should be ported to jk2. Also I wonder if APR is mandatory for jk2. I'd like to use APR as a facade to all Operating System calls. The goal is to hide all the complexity of Windows, iSeries, differents Unix implementations behind APR which is now stable and well diffused. As such it will be +1 to make APR mandatory and start modifying jk2, to make it use only APR call. +1 APR is released and stable - no reason not to do that. Costin But I'd like to have your opinion first. PS: For those of you who was here 2 or 3 years ago, the requirement of APR for mod_webapp got my total -1 at this time since it wasn't really available, but today that's completly different. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] System properties in server.xml (and elsewhere)
Remy Maucherat wrote: Hi, I think it would be possible, using a new rule, to allow system properties inside server.xml (and possibly elsewhere) for attribute values. This is the same as what is being done by Ant in its build scripts. This would add an additional degree of configurability to Tomcat. Actually, I wonder why this feature is not available in the digester itself (I really got used to that feature over the years by using Ant). Comments ? +1, of course. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Benchmarking gcj-built Tomcat
Gary Benson wrote: Hi all, I've been working on building Tomcat and its dependencies to native code with gcj, and I'm interested to see how it compares against Tomcat running under a 'normal' JVM. Now, I'm well aware that benchmarks are not a real-world indicator of performance, but I don't have any particular web application to test and I was wondering if anyone has a benchmarking suite that they can point me at. My benchmarks ( 1 yr ago ) showed GCJ-based tomcat to be as fast as the IBM JDK1.3 ( the fastest VM at that time ). There were small differences under different loads - but the garbage collector seemed like the biggest factor ( GCJ performed worse on JSP pages where more objects were created if I remember correctly ). The amazing thing was the startup time - almost 0 ( it felt more like apache :-). BTW - GCJ is not a virtual machine and doesn't have a JIT - it is a ahead-of-time compiler, just like C and C++ compilers. My understanding is that it compiles Java code to the same intermediary-code as C++ - so you shouldn't see any major difference between C++ code and Java code compiled with GCJ. Except that GCJ programs use garbage collection and java libraries - with the good and the bads. The biggest problem at that time was dynamic class loading. GCJ has a small interpretor and could load servlets - but the difference in performance between precompiled code and interpretor was significant. Another problem was that not everything compiled, I had to do some tricks ( now it shouldn't be a problem ). Also the tests were made with tomcat 3.3 - I tried to compile 4.0 but there were more compile problems. Costin In case you are interested in the gcj-built packages, they are available at http://people.redhat.com/gbenson/naoko/ as source rpms and as binary rpms compiled for Red Hat Linux 9. Everything except the webapps is compiled to native code; the webapps are basically unmodified and are interpreted just as they would be with a normal JVM. Thanks, Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23853] New: - No MBean description for DatasourceRealm presented in org.apache.catalina.mbeans.mbeans-descriptor.xml.
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=23853. 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=23853 No MBean description for DatasourceRealm presented in org.apache.catalina.mbeans.mbeans-descriptor.xml. Summary: No MBean description for DatasourceRealm presented in org.apache.catalina.mbeans.mbeans-descriptor.xml. Product: Tomcat 4 Version: 4.1.27 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm using Tomcat 4.1.27. JDBCRealm works fine, but DatasourceRealm does not work. Unpacking jakarta-tomcat-4.1.27-src.tar.gz, in file mbeans- descriptors.xml, nothing about DatasourceRealm can be found. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
