Re: [OT] Dead laptop
Filip Hanik wrote: if you are getting a new laptop, at least get one with a 15 screen, I have had Sony before, and they are kick ass. IBM is not too bad either. Dell have been a little flaky on us * Maybe the Dells are flaky, but they seem to have a good warranty (3 years, international, onsite), unlike the Sony (which IMO are flaky too). * Maybe a big screen is nice, but it makes the laptop bigger and heavier. There are centrinos with bigger screens (but they are too expensive). * I read that the Banias (aka Pentium M) is very very fast for Java, so I'm shooting for the low end model for my laptop (1.3 GHz, should be roughly equivalent to a 1.8 - 2.0 GHz P4, without the heat). Anyone can confirm the Java performance ? IMO, if that's the case, manufacturers should start making very small servers with that chip (like that old cube from cobalt). On the positive side, I got my desktop up and running for TC development :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21175] New: - httproot and alias configuration into Coyote 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=21175. 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=21175 httproot and alias configuration into Coyote Connector Summary: httproot and alias configuration into Coyote Connector Product: Tomcat 5 Version: 5.0.3 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] For developer host we like tomcat with http connector on port 80, without IIS or Apache. Now we make one Servlet Context for each alias we need. Can Coyote connector support httproot and alias configuration? Example: Connector className=org.apache.coyote.tomcat5.CoyoteConnector ... root dir=C:\myroot alias path=/path dir=C:/dir Factory className=org.apache.catalina.net.DefaultServerSocketFactory/ /Connector Thank you for your patience and for your effort to build open source software. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Upcoming action items
* Release plan vote (early this week) * Interim releases: in order to make the end of the month deadline for a beta, new interim releases are needed more often than before (5.0.x has been roughlty on a 2 months interval between releases); therefore, I propose making a new release every two weeks (or more if there's a need to fix a showstopper) in order to achieve the milestone on time, starting with 5.0.4 at the end of this week * Fix bugs; I'll attempt to fix bugs 4690 (cross context sessions; I have the algorithm on a piece of paper), maybe 9351 (IPv6 support in Coyote HTTP/1.1, but I have no means to test that:-( ), 21169 (possibly) * Polish, polish, polish :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21175] - httproot and alias configuration into Coyote 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=21175. 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=21175 httproot and alias configuration into Coyote Connector [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 07:19 --- Well, no, the idea is that you need to declare the apps in Context elements (to be fair, I don't quite undestand what you mean; you can try to elaborate to see if it sounds better). -1 for moving that inside the connector, for obvious reasons. If you want to deploy hosts/contexts based on your environment, you can develop a custom listener, as the user home listener is doing (look in the docs, in the Host page). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Dead laptop
Remy Maucherat wrote: Snif, snif, my Sony Vaio GRX laptop is dead :-( I was using it for all my TC development, as well as my email. That means I'll waste some time reconfiguring stuff on my desktop (which I was using as a test machine) before I'm up and running again on TC development. As a replacement, I'm considering getting a Dell Centrino-based laptop (with the 14.1 hi res screen). Any opinion on these ? How's the battery life ? The trick for the battery is to remove the battery when the ldap top is connected to power for a long time (some hours). So look for a model that is able to work without the battery when it is connected to the grid. When I am not travelling I unload complety the battery, remove it and store it in a cool and dry place (the dining room!). I was not doing this with the first battery I had and after 6 mounths I had to buy a new one. The new is now 9 mounths old and it still gives a working time of 3-4 hours. Of course I have a FSC Lifebook (C Series)! Cheers Jean-frederic 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]
DO NOT REPLY [Bug 21176] New: - Continuous Memory Leaks
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=21176.
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=21176
Continuous Memory Leaks
Summary: Continuous Memory Leaks
Product: Tomcat 4
Version: 4.1.24
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I experiment frequent memory leaks using servlets with Tomcat.
As a simple test, i wrote this servlet:
import java.io.*;
import java.util.* ;
import javax.servlet.*;
import javax.servlet.http.*;
public class TestServlet extends HttpServlet {
int liCount = 0 ;
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException {
try {
Runtime lRuntime = Runtime.getRuntime();
StringBuffer lOut = new StringBuffer();
lOut.append(Loop,) ;
lOut.append((++liCount)) ;
lOut.append(,Total,) ;
lOut.append(lRuntime.totalMemory()) ;
lOut.append(,Used,) ;
lOut.append(lRuntime.totalMemory() - lRuntime.freeMemory()) ;
lOut.append(,Free,) ;
lOut.append(lRuntime.freeMemory()) ;
System.out.println(lOut.toString());
} catch (Exception ex) {
}
}
}
Examining the results, you can easily find out that memory usage keeps growing
constantly.
Memory usage starts from 18.528.360 and, after about 10.000 iterations reaches
32.509.816
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Dead laptop
jean-frederic clere wrote: Remy Maucherat wrote: Snif, snif, my Sony Vaio GRX laptop is dead :-( I was using it for all my TC development, as well as my email. That means I'll waste some time reconfiguring stuff on my desktop (which I was using as a test machine) before I'm up and running again on TC development. As a replacement, I'm considering getting a Dell Centrino-based laptop (with the 14.1 hi res screen). Any opinion on these ? How's the battery life ? For your information, I've got a DELL INSPIRON 8000 (PIII 1Ghz) with a 14' display and with a new battery I could use it for real works (edit/compile/run) for a Paris-Chambery TGV trip (3 hours). With to battery you could expect 5-6 hour autonomy. But of course, when the bats became older the autonomy drop quickly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21175] - httproot and alias configuration into Coyote 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=21175. 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=21175 httproot and alias configuration into Coyote Connector [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 07:55 --- Well, no, the idea is that you need to declare the apps in Context elements I'm looking for alias for static resources, html gif and js files: - Servlet and JSP = catalina apps; - *.html, *.js, *.gif and *.jpeg = not into apps. We don't need apps for static resource, can the web server coyote manage static resource? Actualy not, I believe. (In development environments, I prefer don't interface Tomcat with servers like Apache HTTPd, IIS) Sorry for my bad english. I don't reopen this bug anymore. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21175] - httproot and alias configuration into Coyote 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=21175. 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=21175 httproot and alias configuration into Coyote Connector [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 08:04 --- I agree with Remy on this one. These mappings should be in the Host or Context elements. They don't belong in the Connector (which should be agnostic as to where the files are served from). Yes, you can do all sorts of dirty tricks if you use a native connector (like mod_jk), but that is no reason for the stand-alone connector to support it as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21176] - Continuous Memory Leaks
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=21176. 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=21176 Continuous Memory Leaks [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 08:18 --- And after some time, GC will occur, freeing memory. Please do not file that kind of report, post on tomcat-user instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21175] - httproot and alias configuration into Coyote 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=21175. 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=21175 httproot and alias configuration into Coyote Connector --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 08:21 --- I don't see much incentive for implementing what you want (IMO, Coyote has no buisness behaving like a native connector, as Bill pointed out). OTOH, you can extend the Coyote adapter class to do that (relatively) easily. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21176] - Continuous Memory Leaks
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=21176. 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=21176 Continuous Memory Leaks [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 08:24 --- I know what GC is !!! If you examine the results, you see that GC occours about every 70-80 calls to the servlet. The problem is that even after every GC, the memory usage is higher than the one of the previous GC... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
decrease idle threads in the pool faster... (II)
Hi everybody I have been searching previous mails about killing idle threads, and I found lots of them describing the same problem (lots of requests carry out new threads that never are released, so, in a long-term, max number of proccesses is reached and Tomcat stops). Some surprising answers were such as: Yes, no attempt is being made at killing processing threads that werecreated. OTOH, they should be reused if some high load situation occurs again (no new threads will be created). Unless you're really short on OS resources, I don't see that being a huge problem. Remy (12/2001... about TC4.0.1) Do you keep thinking the same? It seems to be a serious problem from my point of view!! Burst of requests increase the number of threads used by Tomcat (I work nowadays with TC4.1.12), but I think they should be released later on. Must they grow until infinite? Must I set maxProcessors to 1 for avoiding Max number of processes reached??? :-P A very complex system relies on Tomcat and a lot of servlets, so I need a solution. Some mails, like mine, proposed to dive in the code to change the management of idle threads and kill them. If there isn't any scheduled action about this problem, could anybody give me a hint about where to look in the code? Thanks in advance and best regards, Carlos. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
Remy Maucherat wrote: Brian Olsen wrote: Hey Guys, I just made a proposed patch for the enhancement request I made regarding the SIP Servlet API http://issues.apache.org/bugzilla/show_bug.cgi?id=21169 It adds a new interface org.apache.catalina.ServletSession that contains the methods that HttpSession has in common with SipSession and SipApplicationSession. The interface changes are non-intrusive meaning that it changes or adds no functionality so if a class implements HttpSession it will also implement all the methods in ServletSession. To make catalina support the new interface have have made the following changes: org.apache.catalina.Session - changed to return a ServletSession in the getSession() method org.apache.catalina.session.StandardSession - makes it implement ServletSession and typecasts to HttpSession where needed. org.apache.catalina.session.StandardSessionFacade - makes it implement ServletSession org.apache.coyote.tomcat5.CoyoteRequest - typecasts from ServletSession to HttpSession in the getSession( boolean ) I'm not that thrilled by the patch, because we made the decision in TC 5 to work only with the HTTP protocol, for complexity reasons. Actually, it's merely the underlying protocol having to behave like HTTP (although the older TC 4.0 was supposedly protocol generic, it ended up being designed with HTTP in mind, so it wasn't much better). I know a bit the SIP spec, and that patch would sove the problem for sessions. How do you plan to solve it for the connector ? (the idea is that Coyote - supporting HTTP and JK - will remain the only supported connector in TC 5, the internal Catalina API being conserved for compatibility, or at least easy porting, of any old Catalina module) I don't see how there should be a problem with the connector, besides the fact that it has to also do outgoing connections. This only means that it gets a little more complex than the ordinary connector but not anything I have worries about. It is sad that you made that descision especially with the arrival of SIP Servlets that is the first real specification for using servlets for something other than HTTP. Before you could only guess as to how servlets otherwise could be used. But how will this decision affect the future of the internal Catalina API??? Will you deprecate all of it, just parts, redesign it all from scratch?? I also have another project further ahead in the process than this one (It actually has running code), where I have implemented my own RTSP Servlet API using Catalina and partly based on Coyote. It's my hope to start making it into a proper Java specification later this year. So I'm very interested in what the future internals of Tomcat will look like since two of my projects rely on them. - Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21176] - Continuous Memory Leaks
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=21176. 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=21176 Continuous Memory Leaks [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 09:00 --- Please post on tc-user to investigate this, as many people will be able to give you detailed comments and tips. Please do not reopen this bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: decrease idle threads in the pool faster... (II)
- Original Message - From: Carlos Rodríguez Colino [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 30, 2003 1:21 AM Subject: decrease idle threads in the pool faster... (II) Hi everybody I have been searching previous mails about killing idle threads, and I found lots of them describing the same problem (lots of requests carry out new threads that never are released, so, in a long-term, max number of proccesses is reached and Tomcat stops). Some surprising answers were such as: Yes, no attempt is being made at killing processing threads that were created. OTOH, they should be reused if some high load situation occurs again (no new threads will be created). Unless you're really short on OS resources, I don't see that being a huge problem. Remy (12/2001... about TC4.0.1) Do you keep thinking the same? It seems to be a serious problem from my point of view!! Burst of requests increase the number of threads used by Tomcat (I work nowadays with TC4.1.12), but I think they should be released later on. Must they grow until infinite? Must I set maxProcessors to 1 for avoiding Max number of processes reached??? :-P A very complex system relies on Tomcat and a lot of servlets, so I need a solution. Some mails, like mine, proposed to dive in the code to change the management of idle threads and kill them. If there isn't any scheduled action about this problem, could anybody give me a hint about where to look in the code? Well, the place to look is j-t-c/util/java/org/apache/tomcat/net/PoolTcpEndpoint.java. With my experience, it works very well with the stand-alone connector. On one very old (and brain-dead) Linux system, I had to set a soTimeOut for the Jk-Connector to get it to kill-off Threads (but this is really a work-around to a problem with that Linux version). Thanks in advance and best regards, Carlos. - 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: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
- Original Message - From: Brian Olsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 30, 2003 1:31 AM Subject: Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169) Remy Maucherat wrote: Brian Olsen wrote: Hey Guys, I just made a proposed patch for the enhancement request I made regarding the SIP Servlet API http://issues.apache.org/bugzilla/show_bug.cgi?id=21169 It adds a new interface org.apache.catalina.ServletSession that contains the methods that HttpSession has in common with SipSession and SipApplicationSession. The interface changes are non-intrusive meaning that it changes or adds no functionality so if a class implements HttpSession it will also implement all the methods in ServletSession. To make catalina support the new interface have have made the following changes: org.apache.catalina.Session - changed to return a ServletSession in the getSession() method org.apache.catalina.session.StandardSession - makes it implement ServletSession and typecasts to HttpSession where needed. org.apache.catalina.session.StandardSessionFacade - makes it implement ServletSession org.apache.coyote.tomcat5.CoyoteRequest - typecasts from ServletSession to HttpSession in the getSession( boolean ) I'm not that thrilled by the patch, because we made the decision in TC 5 to work only with the HTTP protocol, for complexity reasons. Actually, it's merely the underlying protocol having to behave like HTTP (although the older TC 4.0 was supposedly protocol generic, it ended up being designed with HTTP in mind, so it wasn't much better). I know a bit the SIP spec, and that patch would sove the problem for sessions. How do you plan to solve it for the connector ? (the idea is that Coyote - supporting HTTP and JK - will remain the only supported connector in TC 5, the internal Catalina API being conserved for compatibility, or at least easy porting, of any old Catalina module) I don't see how there should be a problem with the connector, besides the fact that it has to also do outgoing connections. This only means that it gets a little more complex than the ordinary connector but not anything I have worries about. It is sad that you made that descision especially with the arrival of SIP Servlets that is the first real specification for using servlets for something other than HTTP. Before you could only guess as to how servlets otherwise could be used. But how will this decision affect the future of the internal Catalina API??? Will you deprecate all of it, just parts, redesign it all from scratch?? Like Remy, I'm -0 on the patch. As I read Remy's post, this means that neither of us will actually veto it if some other developer decides to post it. However, neither of us consider it to be a-good-idea, so we will be looking for implementation holes to veto ;-). The internal Catalina API (e.g. org.apache.catalina.*) is pretty stable. There are no current plans to change it. I also have another project further ahead in the process than this one (It actually has running code), where I have implemented my own RTSP Servlet API using Catalina and partly based on Coyote. It's my hope to start making it into a proper Java specification later this year. So I'm very interested in what the future internals of Tomcat will look like since two of my projects rely on them. - Brian - 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: Fw: Howto compile mod_jk2 under windows?
Here is a small explanation on how I managed to do it myself. I spent a while looking for detailed documentation with no success. If you find anything better, please keep me informed :-) HTH, Laurent ---BeginMessage--- Laurent Blume wrote: No, it's part of Tomcat, and I think the most relevant sources are those available in the Tomcat source dist, and also as a separate file: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.24/src/ I tried with the complete Tomcat distribution (it looked easier), but couldn't go anywhere (I'm not that used to compiling on Win32, and I didn't have enough time to spend on it). To answer my own question, since I could take some time to try building that connector, and finally did it, here are some notes I took, that might be of use to someone else... Feel free to correct me if needed. If useful, I might improve it and put it online somewhere. Lines starting with c: are for the command prompt. Tomcat 4.1 Connectors - Version: 4.1.24 I used the zip file containing only the connectors code (jakarta-tomcat-connectors-4.1.24-src.zip) MS Visual Studio 98 --- By default, the connector config file looks for RC.EXE in C:\Program Files\Microsoft Visual Studio\VC98\Bin For me, it was in C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin Rather than modifying the config files, I simply copied the file (it'as already twice in the MSVC dir, so what the heck). Example in the Windows command prompt c: copy C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\rc.exe C:\Program Files\Microsoft Visual Studio\VC98\Bin C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin must be in the PATH (some DLLs need it) Example in the Windows command prompt: c: PATH=%PATH%;C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin Apache2 --- Version: 2.0.46 It must be installed using the Custom choice, and Build headers and libraries must be selected. The APACHE2_HOME environment variable must be set to the Apache 2 directory. Example in the Windows command prompt: c: set APACHE2_HOME=C:\Program Files\Apache Group\Apache2 Ant --- Version: 1.5.3 It must be installed, and the bin/ subdir in the PATH Example in the Windows command prompt: c: PATH=%PATH%;C:\Program Files\Apache Group\apache-ant-1.5.3\bin JDK2 Version: 1.4.1_02 The JAVA_HOME environment variable should be set Example in the Windows command prompt: c: set JAVA_HOME=c:\j2sdk1.4.1_02 * Unzip the connectors' source file in a convenient directory. %CONNROOT% indicates the base of the extracted directory. * Adapt the properties file to your needs c: cd %CONNROOT%/jk/ c: notepad build.properties * I only put those two lines in it, since I want to disable debugging and enable code optimization: so.debug=false so.optimize=true * Then, first build, for some dependencies: c: ant jkant * Finally, the connectors (Apache2 and IIS): c: cd native2/ c: ant * The resulting DLLs will be in: %CONNROOT%/jk/build/jk2/apache2/mod_jk2.dll and %CONNROOT%/jk/build/jk2/isapi/redirector2.dll * Just follow the usual installation to replace old binaries Laurent - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Upcoming action items
Bill Barker wrote: Somewhat OT, but is there a plan for TC 4.1.25? There are some serious bugs in the Jk-Coyote code in TC 4.1.24. I was thinking a two week timeframe for 4.1.25. Are all the patches needed already there ? Personally, I need to port a Jasper patch. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21183] New: - Tomcat does not start on OSF 5.1 with JDK 1.3.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=21183. 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=21183 Tomcat does not start on OSF 5.1 with JDK 1.3.1 Summary: Tomcat does not start on OSF 5.1 with JDK 1.3.1 Product: Tomcat 4 Version: 4.0.1 Final Platform: Alpha OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I try to start Tomcat 4.01 on a alpha server with OSF 5.1 and JDK 1.3.1. But I get only an exception (see below). If i use JDK1.3.0 instead of JDK1.3.1 Tomcat starts without any problem. -- Starting service Tomcat-Standalone Apache Tomcat/4.0.1 Exception during startup processing java.lang.reflect.InvocationTargetException: java.lang.LinkageError: start()V/ at org.apache.catalina.connector.http.HttpConnector.newProcessor (HttpConnector.java:919) (pc 28) at org.apache.catalina.connector.http.HttpConnector.start (HttpConnector.java:1144) (pc 93) at org.apache.catalina.core.StandardService.start (StandardService.java:395) (pc 133) at org.apache.catalina.core.StandardServer.start (StandardServer.java:505) (pc 71) at org.apache.catalina.startup.Catalina.start (Catalina.java:776) (pc 330) at org.apache.catalina.startup.Catalina.execute (Catalina.java:681) (pc 8) at org.apache.catalina.startup.Catalina.process (Catalina.java:179) (pc 17) at java.lang.reflect.Method.invoke (Method.java) at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:243) (pc 836) -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Upcoming action items
I was thinking a two week timeframe for 4.1.25. Are all the patches needed already there ? Mine isn't. OutOfMemoryException due to recursive calls in log() of StandardWrapperValve: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19312 Patch was sent to mailing list April 30th. // J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
Howdy, I'm also not a fan of this patch. I don't think it's a particularly good idea to modify the session interface for 4.1.x at this point. Yoav Shapira --- Bill Barker [EMAIL PROTECTED] wrote: - Original Message - From: Brian Olsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 30, 2003 1:31 AM Subject: Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169) Remy Maucherat wrote: Brian Olsen wrote: Hey Guys, I just made a proposed patch for the enhancement request I made regarding the SIP Servlet API http://issues.apache.org/bugzilla/show_bug.cgi?id=21169 It adds a new interface org.apache.catalina.ServletSession that contains the methods that HttpSession has in common with SipSession and SipApplicationSession. The interface changes are non-intrusive meaning that it changes or adds no functionality so if a class implements HttpSession it will also implement all the methods in ServletSession. To make catalina support the new interface have have made the following changes: org.apache.catalina.Session - changed to return a ServletSession in the getSession() method org.apache.catalina.session.StandardSession - makes it implement ServletSession and typecasts to HttpSession where needed. org.apache.catalina.session.StandardSessionFacade - makes it implement ServletSession org.apache.coyote.tomcat5.CoyoteRequest - typecasts from ServletSession to HttpSession in the getSession( boolean ) I'm not that thrilled by the patch, because we made the decision in TC 5 to work only with the HTTP protocol, for complexity reasons. Actually, it's merely the underlying protocol having to behave like HTTP (although the older TC 4.0 was supposedly protocol generic, it ended up being designed with HTTP in mind, so it wasn't much better). I know a bit the SIP spec, and that patch would sove the problem for sessions. How do you plan to solve it for the connector ? (the idea is that Coyote - supporting HTTP and JK - will remain the only supported connector in TC 5, the internal Catalina API being conserved for compatibility, or at least easy porting, of any old Catalina module) I don't see how there should be a problem with the connector, besides the fact that it has to also do outgoing connections. This only means that it gets a little more complex than the ordinary connector but not anything I have worries about. It is sad that you made that descision especially with the arrival of SIP Servlets that is the first real specification for using servlets for something other than HTTP. Before you could only guess as to how servlets otherwise could be used. But how will this decision affect the future of the internal Catalina API??? Will you deprecate all of it, just parts, redesign it all from scratch?? Like Remy, I'm -0 on the patch. As I read Remy's post, this means that neither of us will actually veto it if some other developer decides to post it. However, neither of us consider it to be a-good-idea, so we will be looking for implementation holes to veto ;-). The internal Catalina API (e.g. org.apache.catalina.*) is pretty stable. There are no current plans to change it. I also have another project further ahead in the process than this one (It actually has running code), where I have implemented my own RTSP Servlet API using Catalina and partly based on Coyote. It's my hope to start making it into a proper Java specification later this year. So I'm very interested in what the future internals of Tomcat will look like since two of my projects rely on them. - Brian - 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] = Yoav Shapira [EMAIL PROTECTED] __ 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: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
Bill Barker wrote: Like Remy, I'm -0 on the patch. As I read Remy's post, this means that neither of us will actually veto it if some other developer decides to post it. However, neither of us consider it to be a-good-idea, so we will be looking for implementation holes to veto ;-). The internal Catalina API (e.g. org.apache.catalina.*) is pretty stable. There are no current plans to change it. It's not that I do think it's a bad idea, it's just I think there are other problems. I would be willing to consider including the patch (but I need to look into possible side effects first). Note: We're talking about 5.0.x here, I think. -1 for inclusion in 4.1.x. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21184] New: - Missing s in LocalString(s)_fr.properties filename
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=21184. 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=21184 Missing s in LocalString(s)_fr.properties filename Summary: Missing s in LocalString(s)_fr.properties filename Product: Tomcat 4 Version: 4.1.24 Platform: Other URL: http://cvs.apache.org/viewcvs/jakarta-tomcat- 4.0/catalina/src/share/org/apache/catalina/connector/htt p/ OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] catalina/src/share/org/apache/catalina/connector/http/LocalString_fr.properties Seems that the filename should actually be LocalStrings_fr.properties. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
Bill Barker wrote: - Original Message - From: Brian Olsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 30, 2003 1:31 AM Subject: Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169) Remy Maucherat wrote: Brian Olsen wrote: Hey Guys, I just made a proposed patch for the enhancement request I made regarding the SIP Servlet API http://issues.apache.org/bugzilla/show_bug.cgi?id=21169 It adds a new interface org.apache.catalina.ServletSession that contains the methods that HttpSession has in common with SipSession and SipApplicationSession. The interface changes are non-intrusive meaning that it changes or adds no functionality so if a class implements HttpSession it will also implement all the methods in ServletSession. To make catalina support the new interface have have made the following changes: org.apache.catalina.Session - changed to return a ServletSession in the getSession() method org.apache.catalina.session.StandardSession - makes it implement ServletSession and typecasts to HttpSession where needed. org.apache.catalina.session.StandardSessionFacade - makes it implement ServletSession org.apache.coyote.tomcat5.CoyoteRequest - typecasts from ServletSession to HttpSession in the getSession( boolean ) I'm not that thrilled by the patch, because we made the decision in TC 5 to work only with the HTTP protocol, for complexity reasons. Actually, it's merely the underlying protocol having to behave like HTTP (although the older TC 4.0 was supposedly protocol generic, it ended up being designed with HTTP in mind, so it wasn't much better). I know a bit the SIP spec, and that patch would sove the problem for sessions. How do you plan to solve it for the connector ? (the idea is that Coyote - supporting HTTP and JK - will remain the only supported connector in TC 5, the internal Catalina API being conserved for compatibility, or at least easy porting, of any old Catalina module) I don't see how there should be a problem with the connector, besides the fact that it has to also do outgoing connections. This only means that it gets a little more complex than the ordinary connector but not anything I have worries about. It is sad that you made that descision especially with the arrival of SIP Servlets that is the first real specification for using servlets for something other than HTTP. Before you could only guess as to how servlets otherwise could be used. But how will this decision affect the future of the internal Catalina API??? Will you deprecate all of it, just parts, redesign it all from scratch?? Like Remy, I'm -0 on the patch. As I read Remy's post, this means that neither of us will actually veto it if some other developer decides to post it. However, neither of us consider it to be a-good-idea, so we will be looking for implementation holes to veto ;-). Just try and find any holes ;-) It doesn't add a line of active code only interface change and typecasts. But what other reasons is there against the change other than the principal decision of only supporting HTTP in Tomcat 5??? And Remy himself says earlier in this thread Actually, it's merely the underlying protocol having to behave like HTTP. And both SIP and RTSP behave much like HTTP given they both are designed with basis in HTTP. The problem is really that HttpSession and SipSession doesn't have any common interface, like say ServletRequest, so there is really no way to design a good interface in the container. I admit that the patch I sent is not that pretty. To call it a hack would more be the right term, but since the Servlet specification doesn't define a ServletSession interface how could it otherwise be done? I would really like to keep baseing my servlet containers on tomcat, since (for the most part ;-)) the interfaces are very well thought and designed. And I would really hate to have to start from scratch and make my very own container when a great deal of the foundation has allready been laid by you. The internal Catalina API (e.g. org.apache.catalina.*) is pretty stable. There are no current plans to change it. Pu eh! You had me worried there for a moment. - Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21187] New: - Method init called twice for filter class
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=21187.
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=21187
Method init called twice for filter class
Summary: Method init called twice for filter class
Product: Tomcat 4
Version: 4.1.24
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Critical
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I have a filter in my web application. When tomcat (4.1.24 in linux environmet)
goes up, the method init() of my filter is called twice.
This is wrong for my application. I try to test a static attribute in this way
private static Boolean loggerCreated = new Boolean( false );
public void init( FilterConfig config ) {
if ( !loggerCreated.booleanValue() ) {
synchronized ( loggerCreated ) {
loggerCreated = new Boolean( true );
}
...
but probably the class is load by two different class loaders.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21187] - Method init called twice for filter class
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=21187. 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=21187 Method init called twice for filter class [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|Method init called twice for|Method init called twice for |filter class|filter class --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 13:05 --- The closing statement of the report makes me think this is invalid. You'd want to check your mappings and your deployment, and debug, more (add some Thread.dumpStack() to see where the bad inits are coming from). Please only reopen the bug if you have conclusive evidence (it would be best to attach a WAR test case). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21190] New: - JDBCRealm is trying to use closed connections without checking
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=21190. 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=21190 JDBCRealm is trying to use closed connections without checking Summary: JDBCRealm is trying to use closed connections without checking Product: Tomcat 4 Version: 4.0.6 Final Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] org.apache.catalina.realm.JDBCRealm: 1) Trying to use JDBC connection after it has been closed because of timeout 2) Trying to execute prepared statements (preparedCredentials and preparedRoles in code) on closed connection if the connection has been closed because of timeout In current version if connection to mysql server is closed because of inactivity timeout then next user attempt to login will fail regardless of username and password he has entered. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21116] - EOFException thrown - seemingly random
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=21116.
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=21116
EOFException thrown - seemingly random
--- Additional Comments From [EMAIL PROTECTED] 2003-06-30 14:05 ---
By the way, line 25 in BTecServlet is the second line here:
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException{
ObjectInputStream in = null;
ObjectOutputStream out = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21116] - EOFException thrown - seemingly random
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=21116.
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=21116
EOFException thrown - seemingly random
--- Additional Comments From [EMAIL PROTECTED] 2003-06-30 14:09 ---
Excuse me, line 25 is the second line in the following code: (not what I had
just posted)
public void doPost(HttpServletRequest request, HttpServletResponse
response)throws ServletException, IOException{
ObjectInputStream in = new ObjectInputStream(request.getInputStream());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21116] - EOFException thrown - seemingly random
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=21116. 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=21116 EOFException thrown - seemingly random [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 14:14 --- It feels random because the web client is not posting the correct content length. This usually happens when the web client has aborted the request during the process of making the post. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
Remy Maucherat wrote: Bill Barker wrote: Like Remy, I'm -0 on the patch. As I read Remy's post, this means that neither of us will actually veto it if some other developer decides to post it. However, neither of us consider it to be a-good-idea, so we will be looking for implementation holes to veto ;-). The internal Catalina API (e.g. org.apache.catalina.*) is pretty stable. There are no current plans to change it. It's not that I do think it's a bad idea, it's just I think there are other problems. I would be willing to consider including the patch (but I need to look into possible side effects first). What could those side effects be??? Note: We're talking about 5.0.x here, I think. -1 for inclusion in 4.1.x. I never thought for it to be in 4.1.x, and the patch is also based on the catalina CVS HEAD yesterday. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bug 21190 fix
Hi all!
If somebody is interested in solution for BUG #21190 (recently submited by me -
JDBCRealm is trying to use closed connections without checking in tomcat
4.0.6, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21190) please see the
file attached. BTW this bug also seems to be actual for the last (4.1.24)
version of tomcat too.
Best regards, Alexey
--- JDBCRealm.java.orig Tue Oct 8 18:16:42 2002
+++ JDBCRealm.java Mon Jun 30 18:42:21 2003
@@ -526,8 +526,12 @@
protected Connection open() throws SQLException {
// Do nothing if there is a database connection already open
-if (dbConnection != null)
+if (dbConnection != null !dbConnection.isClosed())
return (dbConnection);
+
+// Need to recompile all prepared statements
+this.preparedCredentials = null;
+this.preparedRoles = null;
// Instantiate our database driver if necessary
if (driver == null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: [OT] Dead laptop
get an apple power book with a 17 display ;-) bye daniel s. haischt -- -Ursprungliche Nachricht- Von: Remy Maucherat [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 29. Juni 2003 23:55 An: Tomcat Developers List Betreff: [OT] Dead laptop Snif, snif, my Sony Vaio GRX laptop is dead :-( I was using it for all my TC development, as well as my email. That means I'll waste some time reconfiguring stuff on my desktop (which I was using as a test machine) before I'm up and running again on TC development. As a replacement, I'm considering getting a Dell Centrino-based laptop (with the 14.1 hi res screen). Any opinion on these ? How's the battery life ? 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]
[PATCH] Change getSession() in org.apache.catalina.Session from HttpSessionto a more general interface (enhancement request 21169)
Hey Guys, I just made a proposed patch for the enhancement request I made regarding the SIP Servlet API http://issues.apache.org/bugzilla/show_bug.cgi?id=21169 It adds a new interface org.apache.catalina.ServletSession that contains the methods that HttpSession has in common with SipSession and SipApplicationSession. The interface changes are non-intrusive meaning that it changes or adds no functionality so if a class implements HttpSession it will also implement all the methods in ServletSession. To make catalina support the new interface have have made the following changes: org.apache.catalina.Session - changed to return a ServletSession in the getSession() method org.apache.catalina.session.StandardSession - makes it implement ServletSession and typecasts to HttpSession where needed. org.apache.catalina.session.StandardSessionFacade - makes it implement ServletSession org.apache.coyote.tomcat5.CoyoteRequest - typecasts from ServletSession to HttpSession in the getSession( boolean ) - Brian ServletSession.tar.gz Description: GNU Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21157] - CookieExample is setting cookie after writing data
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=21157. 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=21157 CookieExample is setting cookie after writing data --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 17:25 --- Here are some facts that may lead you to reconsider. - The servlet spec itself does not mandate a default size for the buffer. The user can call response.setBufferSize to set the buffer to any size. - The user can tweak the bufferSize attribute of coyote or the legacy connector in server.xml. There is nothing preventing user to set it to 0 in which case the cookie example immediately breaks. - Users tend to use these examples as base for something that they like to achieve. So it is a good idea to provide users with an example that is more robust and does not break depending on how much data they write or what settings they have in server.xml. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Dead laptop
For laptoppy goodness you can't beat a Powerbook G4[1], java 1.4.1 on these guys rocks, and Eclipse is available now. Project builder isn't so great, but the form factor, battery life, unix/gnu tools built-in and OS makes it the best laptop (IMHO) that you can buy. On the other hand they're a bit more expensive than a PC, but you get what you pay for. Kev [1] www.apple.com/powerbook/index15.html -- To be governed is to be watched over, inspected, spied on, directed, legislated... - Pierre-Joseph Proudhon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21194] New: - JNDIRealm usersubtree doesn't work properly
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=21194.
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=21194
JNDIRealm usersubtree doesn't work properly
Summary: JNDIRealm usersubtree doesn't work properly
Product: Tomcat 4
Version: 4.1.18
Platform: All
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I am trying to get Tomcat version 4.1.18 to authenticate to novell's eDirectory
8.62 using JNDIRealm. If a user exists in the base directory set, it picks up
the user, no problem. But if a user exists in a subdirectory of the base
selected, the usersubtree being set to 'true' still doesn't change the search
scope to the subdirectory. This is the realm I have set.
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionURL=ldap://10.228.2.91:389;
userBase=ou=People,o=ny
userSearch=(cn={0})
userSubTree=true
roleBase=ou=People,o=ny
roleSubTree=true
roleName=title
roleSearch=(cn={1})
/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.properties.default build.xml
remm2003/06/30 11:21:35
Modified:.build.properties.default build.xml
Log:
- Update to Struts 1.1.
Revision ChangesPath
1.97 +3 -3 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.96
retrieving revision 1.97
diff -u -r1.96 -r1.97
--- build.properties.default 26 Jun 2003 22:23:15 - 1.96
+++ build.properties.default 30 Jun 2003 18:21:34 - 1.97
@@ -189,10 +189,10 @@
# - Struts, version 1.1 or later -
-struts.home=${base.path}/jakarta-struts-1.1-rc1
+struts.home=${base.path}/jakarta-struts-1.1
struts.lib=${struts.home}/lib
struts.jar=${struts.lib}/struts.jar
-struts.loc=http://www.apache.org/dist/jakarta/struts/binaries/jakarta-struts-1.1-rc1.tar.gz
+struts.loc=http://www.apache.org/dist/jakarta/struts/binaries/jakarta-struts-1.1.tar.gz
# --
1.136 +1 -1 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- build.xml 22 Jun 2003 17:42:46 - 1.135
+++ build.xml 30 Jun 2003 18:21:34 - 1.136
@@ -12,7 +12,7 @@
!-- Project Properties --
property name=name value=Apache Tomcat /
- property name=year value=2002 /
+ property name=year value=2003 /
property name=version value=5.0 /
property name=project value=jakarta-tomcat /
property name=final.namevalue=${project}-${version} /
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18220] - Copy Paste doesn't work (Apache Service Monitor)
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=18220. 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=18220 Copy Paste doesn't work (Apache Service Monitor) --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 19:11 --- I just reproduced it on Windows 2000 (Tomcat 5.0.3, JDK 1.4.1_03). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [OT] Dead laptop
IDEA and Together are available as OS X versions too. -Ursprungliche Nachricht- Von: kev [mailto:[EMAIL PROTECTED] Gesendet: Montag, 30. Juni 2003 19:34 An: Tomcat Developers List Betreff: Re: [OT] Dead laptop For laptoppy goodness you can't beat a Powerbook G4[1], java 1.4.1 on these guys rocks, and Eclipse is available now. Project builder isn't so great, but the form factor, battery life, unix/gnu tools built-in and OS makes it the best laptop (IMHO) that you can buy. On the other hand they're a bit more expensive than a PC, but you get what you pay for. Kev [1] www.apple.com/powerbook/index15.html -- To be governed is to be watched over, inspected, spied on, directed, legislated... - Pierre-Joseph Proudhon - 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] Upcoming action items
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, June 30, 2003 4:17 AM Subject: Re: [5.0] Upcoming action items Bill Barker wrote: Somewhat OT, but is there a plan for TC 4.1.25? There are some serious bugs in the Jk-Coyote code in TC 4.1.24. I was thinking a two week timeframe for 4.1.25. Are all the patches needed already there ? If we're still using coyote_10, then there are a few things I need to port from HEAD (e.g. the // fix for mod_jk). Personally, I need to port a Jasper patch. 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]
Re: [5.0] Upcoming action items
Bill Barker wrote: I was thinking a two week timeframe for 4.1.25. Are all the patches needed already there ? If we're still using coyote_10, then there are a few things I need to port from HEAD (e.g. the // fix for mod_jk). Yep, coyote_10 is still used there. I think it would be a big change to switch (it would require JMX, among other things). Is the timeframe I've given for 4.1.25 too long ? (I have to admit that, although I have setup my environment for TC 5 on my desktop, I need to setup 4.1.x again) I can release it at the end of this week if needed. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Change getSession() in org.apache.catalina.Session from HttpSession to a more general interface (enhancement request 21169)
Brian Olsen wrote: Remy Maucherat wrote: It's not that I do think it's a bad idea, it's just I think there are other problems. I would be willing to consider including the patch (but I need to look into possible side effects first). What could those side effects be??? You're changing the core API, so you could affect existing components. I will commit your patch if I find it is safe, and nobody vetoes it. Note: We're talking about 5.0.x here, I think. -1 for inclusion in 4.1.x. I never thought for it to be in 4.1.x, and the patch is also based on the catalina CVS HEAD yesterday. The diff was against TC 5, so I didn't even consider including your patch in TC 4.1.x. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
remm2003/06/30 15:10:00
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
- Don't generate the comments (they can screw up the char encoding in case
i18n is used) when including in an existing web.xml.
Revision ChangesPath
1.47 +5 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- JspC.java 26 Jun 2003 01:18:07 - 1.46
+++ JspC.java 30 Jun 2003 22:10:00 - 1.47
@@ -863,7 +863,7 @@
if (webxmlLevel = ALL_WEBXML) {
mapout.write(Localizer.getMessage(jspc.webxml.header));
mapout.flush();
-} else if (webxmlLevel= INC_WEBXML) {
+} else if ((webxmlLevel= INC_WEBXML) !addWebXmlMappings) {
mapout.write(Localizer.getMessage(jspc.webinc.header));
mapout.flush();
}
@@ -881,7 +881,7 @@
mappingout.writeTo(mapout);
if (webxmlLevel = ALL_WEBXML) {
mapout.write(Localizer.getMessage(jspc.webxml.footer));
-} else if (webxmlLevel = INC_WEBXML) {
+} else if ((webxmlLevel = INC_WEBXML) !addWebXmlMappings) {
mapout.write(Localizer.getMessage(jspc.webinc.footer));
}
mapout.close();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21206] New: - Tomcat 5 - Jetspeed JSP Portlets do not display
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=21206. 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=21206 Tomcat 5 - Jetspeed JSP Portlets do not display Summary: Tomcat 5 - Jetspeed JSP Portlets do not display Product: Tomcat 5 Version: 5.0.3 Platform: PC OS/Version: Linux Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Setup: RedHat Linux 8.0 J2SE 1.4.2-beta Tomcat 5.0.3 Jetspeed 1.4-b4(release) and 1.4-b5-dev(from CVS) Using Tomcat 5.0.3, Jetspeed will not display the contents of any of the JSP Portlets just their title bars. And the only way that I have found to get these JSP Portlets to display is to select 'Edit account' at the top of the Jetspeed page and then just cancel on the next page. Jetspeed JSP Portlets just do not work right with Tomcat 5.0.3. thx, Gerry Reno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display
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=21206. 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=21206 Tomcat 5 - Jetspeed JSP Portlets do not display --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 22:17 --- BTW, I tried this with Tomcat 4.1.24 and the Jetspeed JSP Portlets work fine in that release. thx, Gerry Reno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display
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=21206. 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=21206 Tomcat 5 - Jetspeed JSP Portlets do not display --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 22:18 --- Please investigate this, and point out a TC 5 spec violation causing the wrong behavior. I will close the report if a cause of this behavior cannot be identiied, as it could be an application problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
remm2003/06/30 15:16:40
Modified:.build.xml
Log:
- Use the flag to include declarations inside web.xml, rather than
rely on a token.
Revision ChangesPath
1.137 +3 -15 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.136
retrieving revision 1.137
diff -u -r1.136 -r1.137
--- build.xml 30 Jun 2003 18:21:34 - 1.136
+++ build.xml 30 Jun 2003 22:16:39 - 1.137
@@ -310,6 +310,7 @@
validateXml=false
uriroot=${ROOT.base}
webXmlFragment=${ROOT.base}/WEB-INF/generated_web.xml
+ addWebXmlMappings=true
outputDir=${ROOT.base}/WEB-INF/src /
jasper2
@@ -317,6 +318,7 @@
validateXml=false
uriroot=${jsp-examples.base}
webXmlFragment=${jsp-examples.base}/WEB-INF/generated_web.xml
+ addWebXmlMappings=true
outputDir=${jsp-examples.base}/WEB-INF/src /
jasper2
@@ -325,22 +327,8 @@
validateXml=false
uriroot=${admin.base}
webXmlFragment=${admin.base}/WEB-INF/generated_web.xml
+ addWebXmlMappings=true
outputDir=${admin.base}/WEB-INF/src/admin /
-
-loadfile property=generated_ROOT_web.xml
- srcFile=${ROOT.base}/WEB-INF/generated_web.xml /
-replace file=${ROOT.base}/WEB-INF/web.xml
- token=lt;!--GENERATED_JSPS--gt; value=${generated_ROOT_web.xml}
/
-
-loadfile property=generated_JSP_web.xml
- srcFile=${jsp-examples.base}/WEB-INF/generated_web.xml /
-replace file=${jsp-examples.base}/WEB-INF/web.xml
- token=lt;!--GENERATED_JSPS--gt; value=${generated_JSP_web.xml} /
-
-loadfile property=generated_admin_web.xml
- srcFile=${admin.base}/WEB-INF/generated_web.xml /
-replace file=${admin.base}/WEB-INF/web.xml
- token=lt;!--GENERATED_JSPS--gt; value=${generated_admin_web.xml}
/
javac destdir=${ROOT.base}/WEB-INF/classes
optimize=off
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
custom HTTP headers?
I'm wondering if anyone can point me towards the class/classes that I should look at to add custom HTTP response headers for a customized Tomcat application I'm working on. Thanks very much. -Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20752] - Soft links to jars in a webapp causes IllegalArgumentException
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=20752. 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=20752 Soft links to jars in a webapp causes IllegalArgumentException --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 22:35 --- Similarly TC is blowing up on a load when I attempt to start up any exploded WAR. WebappLoader[irs]: Deploy JAR /WEB-INF/lib/tibrvj.jar to /Users/david/Development/ eclipse/workspace/irs/WEB-INF/lib/tibrvj.jar WebappLoader[irs]: Deploy JAR /WEB-INF/lib/tibrvjweb.jar to /Users/david/Development/ eclipse/workspace/irs/WEB-INF/lib/tibrvjweb.jar WebappLoader[irs]: Reloading checks are enabled for this Context ContextConfig[irs] Exception processing JAR at resource path /WEB-INF/lib/ldapsp.jar javax.servlet.ServletException: Exception processing JAR at resource path /WEB-INF/lib/ ldapsp.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3567) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190) at org.apache.catalina.startup.Catalina.start(Catalina.java:512) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) - Root Cause - java.io.FileNotFoundException at org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextUR LConnection.java:344) at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:161) at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:42) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:78) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:85) at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:69) at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:906) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3567) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190) at org.apache.catalina.startup.Catalina.start(Catalina.java:512) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) ContextConfig[irs]: Marking this application unavailable due to previous error(s)
DO NOT REPLY [Bug 20860] - JDBCRealm looses database connection
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=20860. 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=20860 JDBCRealm looses database connection [EMAIL PROTECTED] changed: What|Removed |Added Keywords|PatchAvailable | --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 22:49 --- Mmm, I can confirm that my patch doesn't work. But the problem is still in there. I hope somebody can look into this for 4.1.25, because things like /manager hidden behind doesn't JDBCRealm, doesn't work anymore if the database closes the connection after 1 night. Or can somebody check this for 5.0.x? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21207] New: - JDBCRealm not thread safe
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=21207. 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=21207 JDBCRealm not thread safe Summary: JDBCRealm not thread safe Product: Tomcat 4 Version: 4.1.24 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Shouldn't there be synchronized blocks in JDBCRealm, because we use global PreparedStatements? This (pseudo-)code, will give two resultsets about id2. thread1.statement.setString(1, id1); thread2.statement.setString(1, id2); ResultSet rs = thread1.statement.execute(); ResultSet rs = thread2.statement.execute(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Upcoming action items
On Monday 30 June 2003 23:25, Remy Maucherat wrote: Bill Barker wrote: I was thinking a two week timeframe for 4.1.25. Are all the patches needed already there ? If we're still using coyote_10, then there are a few things I need to port from HEAD (e.g. the // fix for mod_jk). Yep, coyote_10 is still used there. I think it would be a big change to switch (it would require JMX, among other things). Is the timeframe I've given for 4.1.25 too long ? (I have to admit that, although I have setup my environment for TC 5 on my desktop, I need to setup 4.1.x again) I can release it at the end of this week if needed. Is there a list of features/bugfixes which will go into 4.1.25? Is there a place to do suggestions? Greetings, Ronald. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display
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=21206. 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=21206 Tomcat 5 - Jetspeed JSP Portlets do not display --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 23:31 --- Remy, Yes, I am not discounting the possibility that this could be some type of app problem. However, the app is working perfectly fine under 4.1.24 and not under 5.0.3. I would think that the specs that relate to rendering of JSP content would be the same as the JSP content in question was JSP 1.2 only - nothing was JSP 2.0. Therefore it seems as though one or the other of the containers is not compliant. The app also appears to work ok under Resin. I am not a spec expert that could pinpoint exactly this problem. Perhaps there is someone else more familiar with the specs and the Tomcat and/or Jetspeed code that could assist here. thx, Gerry Reno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21207] - JDBCRealm not thread safe
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=21207. 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=21207 JDBCRealm not thread safe [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-30 23:58 --- All calls go through authenticate(Connection dbConnection, String username, String credentials) which is a synchronized method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: custom HTTP headers?
HttpServletResponse which is part of the servlet API (and portable to other containers) -Tim Adam Fisk wrote: I'm wondering if anyone can point me towards the class/classes that I should look at to add custom HTTP response headers for a customized Tomcat application I'm working on. Thanks very much. -Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21157] - CookieExample is setting cookie after writing data
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=21157. 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=21157 CookieExample is setting cookie after writing data [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Status|RESOLVED|REOPENED Priority|Other |Low Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-07-01 00:06 --- Well, I wasn't too happy with Remy's decision to mark this bug as invalid, either. Having thought about this for a while, I ended up with a list of facts almost identical to the one posted by Vichy. For an example refered to as a starting point for servlet developers and used as a source for copypaste best effort should be made to use good coding practises. Therefore, I decided to reopen this bug. I am currently working on a patch which I will soon propose for discussion. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display
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=21206. 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=21206 Tomcat 5 - Jetspeed JSP Portlets do not display --- Additional Comments From [EMAIL PROTECTED] 2003-07-01 00:25 --- I have tried this on win2k. The war file fails. If you expand the .war to directory form, then all is OK. In .war form -- I get a zip exception. So tomcat is OK with respect to running. The unpacking of the war is a different story. For thos curious, here is the part of the stack trace that might look important in case someone might have an immediate a ha!: SEVERE: Exception processing JAR at resource path C:\opt\data\src\TOMCAT5\jakarta-tomcat-5\build\webapps\jetspeed\WEB-INF\lib\jetspeed-1.4-b4.jar in context /jetspeed java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:112) at java.util.jar.JarFile.init(JarFile.java:117) at java.util.jar.JarFile.init(JarFile.java:82) at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:469) at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:449) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:228) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4037) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:868) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21157] - CookieExample is setting cookie after writing data
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=21157. 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=21157 CookieExample is setting cookie after writing data --- Additional Comments From [EMAIL PROTECTED] 2003-07-01 00:28 --- Created an attachment (id=7033) Proposed patch moving call to response.addCookie() before response.getWriter() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display
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=21206. 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=21206 Tomcat 5 - Jetspeed JSP Portlets do not display --- Additional Comments From [EMAIL PROTECTED] 2003-07-01 00:38 --- Tim, All of the war files in all of my tests with 5.0.3 and 4.1.24 were fully expanded. What exactly are you saying? Are you seeing the exact same problem? What did you mean when you say 'war file fails'? If you meant you just got a zip exception are you thinking this is related to JSP Portlets not displaying? Gerry Reno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21207] - JDBCRealm not thread safe
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=21207. 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=21207 JDBCRealm not thread safe --- Additional Comments From [EMAIL PROTECTED] 2003-07-01 01:32 --- Oops. I looked over that synchronized statement. Sorry. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21206] - Tomcat 5 - Jetspeed JSP Portlets do not display
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=21206. 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=21206 Tomcat 5 - Jetspeed JSP Portlets do not display --- Additional Comments From [EMAIL PROTECTED] 2003-07-01 01:36 --- Let me clarify this a little more. Once you have installed the jetspeed.war file go to the jetspeed home page http://localhost:8080/jetspeed . Login as user 'turbine', password 'turbine'. Now, all the default portlets you see on the page are Velocity Portlets. You have to actually add JSP Portlets to the pages before you can even begin to see the problem. Click on the 'Edit HTML' link and select Home then select 'Add Portlet' and from the list of portlets select some of the JSP types such as JSP HelloWorld or JSP Stock Portfolio (on the next page), save and apply your way out and then you should be able to see the problem. thx, Gerry Reno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TOMCAT 5 Development
I am interested in getting in on the TOMCAT 5.0 development What is needed? Where can I be of some help? -- Andre D Bonner Sun Certified Programmer for the Java 2 Platform 1.4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20376] - Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP
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=20376. 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=20376 Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-07-01 03:40 --- I think this bug is the problem. this is very critical issue ladies and gentleman. Can any body tell me the last version that doesn't have this bug and works with AJP 1.3 *** This bug has been marked as a duplicate of 15278 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15278] - [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]
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=15278. 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=15278 [PATCH] mod_jk2 for IIS, Bugfix corrupted data ] [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-07-01 03:40 --- *** Bug 20376 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c jk_uri_worker_map.h
billbarker2003/06/30 22:16:47
Modified:jk/native/apache-1.3 Tag: coyote_10 mod_jk.c
jk/native/apache-2.0 Tag: coyote_10 mod_jk.c
jk/native/common Tag: coyote_10 jk_uri_worker_map.c
jk_uri_worker_map.h
Log:
Port patch for // from HEAD branch.
Revision ChangesPath
No revision
No revision
1.35.2.1 +6 -4 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
retrieving revision 1.35
retrieving revision 1.35.2.1
diff -u -r1.35 -r1.35.2.1
--- mod_jk.c 7 Jan 2003 01:27:11 - 1.35
+++ mod_jk.c 1 Jul 2003 05:16:46 - 1.35.2.1
@@ -1842,15 +1842,17 @@
r-handler = ap_pstrdup(r-pool, JK_HANDLER);
ap_table_setn(r-notes, JK_WORKER_ID, worker);
} else if(conf-alias_dir != NULL) {
+char *clean_uri = ap_pstrdup(r-pool, r-uri);
+ap_no2slash(clean_uri);
/* Automatically map uri to a context static file */
jk_log(l, JK_LOG_DEBUG,
mod_jk::jk_translate, check alias_dir: %s\n,conf-alias_dir);
-if (strlen(r-uri) 1) {
+if (strlen(clean_uri) 1) {
/* Get the context directory name */
char *context_dir = NULL;
char *context_path = NULL;
char *child_dir = NULL;
-char *index = r-uri;
+char *index = clean_uri;
char *suffix = strchr(index+1,'/');
if( suffix != NULL ) {
int size = suffix - index;
@@ -1887,7 +1889,7 @@
if( context_path != NULL ) {
DIR *dir = ap_popendir(r-pool,context_path);
if( dir != NULL ) {
-char *escurl = ap_os_escape_path(r-pool, r-uri, 1);
+char *escurl = ap_os_escape_path(r-pool, clean_uri, 1);
char *ret =
ap_pstrcat(r-pool,conf-alias_dir,escurl,NULL);
ap_pclosedir(r-pool,dir);
/* Add code to verify real path ap_os_canonical_name */
No revision
No revision
1.65.2.1 +6 -4 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.65
retrieving revision 1.65.2.1
diff -u -r1.65 -r1.65.2.1
--- mod_jk.c 7 Jan 2003 01:27:11 - 1.65
+++ mod_jk.c 1 Jul 2003 05:16:47 - 1.65.2.1
@@ -2134,16 +2134,18 @@
return OK;
} else if(conf-alias_dir != NULL) {
+char *clean_uri = ap_pstrdup(r-pool, r-uri);
+ap_no2slash(clean_uri);
/* Automatically map uri to a context static file */
jk_log(conf-log, JK_LOG_DEBUG,
mod_jk::jk_translate, check alias_dir: %s\n,
conf-alias_dir);
-if (strlen(r-uri) 1) {
+if (strlen(clean_uri) 1) {
/* Get the context directory name */
char *context_dir = NULL;
char *context_path = NULL;
char *child_dir = NULL;
-char *index = r-uri;
+char *index = clean_uri;
char *suffix = strchr(index+1,'/');
if( suffix != NULL ) {
int size = suffix - index;
@@ -2181,7 +2183,7 @@
finfo.filetype = APR_NOFILE;
apr_stat(finfo,context_path,APR_FINFO_TYPE,r-pool);
if( finfo.filetype == APR_DIR ) {
-char *escurl = ap_os_escape_path(r-pool, r-uri, 1);
+char *escurl = ap_os_escape_path(r-pool, clean_uri, 1);
char *ret =
ap_pstrcat(r-pool,conf-alias_dir,escurl,NULL);
/* Add code to verify real path ap_os_canonical_name */
if( ret != NULL ) {
No revision
No revision
1.14.2.1 +31 -7 jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c
Index: jk_uri_worker_map.c
===
RCS file:
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls PureTLSSocketFactory.java PureTLSSupport.java
billbarker2003/06/30 22:21:30
Modified:util/java/org/apache/tomcat/util/net/puretls Tag: coyote_10
PureTLSSocketFactory.java PureTLSSupport.java
Log:
Porting fixes for CLIENT-CERT from HEAD branch.
Revision ChangesPath
No revision
No revision
1.1.2.1 +13 -5
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSocketFactory.java
Index: PureTLSSocketFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSocketFactory.java,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- PureTLSSocketFactory.java 4 Oct 2002 20:03:10 - 1.1
+++ PureTLSSocketFactory.java 1 Jul 2003 05:21:30 - 1.1.2.1
@@ -79,6 +79,8 @@
public class PureTLSSocketFactory
extends org.apache.tomcat.util.net.ServerSocketFactory
{
+static org.apache.commons.logging.Log logger =
+ org.apache.commons.logging.LogFactory.getLog(PureTLSSocketFactory.class);
static String defaultProtocol = TLS;
static boolean defaultClientAuth = false;
static String defaultKeyStoreFile = server.pem;
@@ -158,11 +160,15 @@
}
}
- SSLContext tmpContext=new SSLContext();
- if(clientAuth){
- tmpContext.loadRootCertificates(rootFile);
- }
- tmpContext.loadEAYKeyFile(keyStoreFile,keyPass);
+SSLContext tmpContext=new SSLContext();
+try {
+tmpContext.loadRootCertificates(rootFile);
+} catch(IOException iex) {
+if(logger.isDebugEnabled())
+logger.debug(Error loading Client Root Store: +
+ rootFile,iex);
+}
+tmpContext.loadEAYKeyFile(keyStoreFile,keyPass);
tmpContext.useRandomnessFile(randomFile,keyPass);
SSLPolicyInt policy=new SSLPolicyInt();
@@ -172,6 +178,7 @@
tmpContext.setPolicy(policy);
context=tmpContext;
} catch (Exception e){
+ logger.info(Error initializing SocketFactory,e);
throw new IOException(e.getMessage());
}
}
@@ -183,6 +190,7 @@
Socket sock=socket.accept();
return sock;
} catch (SSLException e){
+logger.debug(SSL handshake error,e);
throw new SocketException(SSL handshake error + e.toString());
}
}
1.1.2.1 +16 -4
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSupport.java
Index: PureTLSSupport.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSupport.java,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- PureTLSSupport.java 4 Oct 2002 20:03:10 - 1.1
+++ PureTLSSupport.java 1 Jul 2003 05:21:30 - 1.1.2.1
@@ -64,6 +64,7 @@
import java.net.*;
import java.util.Vector;
import java.security.cert.CertificateFactory;
+import java.security.cert.X509Certificate;
import org.apache.tomcat.util.buf.HexUtils;
import COM.claymoresystems.sslg.*;
@@ -83,6 +84,9 @@
*/
class PureTLSSupport implements SSLSupport {
+static org.apache.commons.logging.Log logger =
+ org.apache.commons.logging.LogFactory.getLog(PureTLSSupport.class);
+
private COM.claymoresystems.ptls.SSLSocket ssl;
PureTLSSupport(SSLSocket sock){
@@ -130,12 +134,16 @@
CertificateFactory.getInstance(X.509);
ByteArrayInputStream stream =
new ByteArrayInputStream(buffer);
-
-chain[i]=(java.security.cert.X509Certificate)
- cf.generateCertificate(stream);
+
+X509Certificate xCert = (X509Certificate)cf.generateCertificate(stream);
+chain[i-1]= xCert;
+if(logger.isTraceEnabled()) {
+ logger.trace(Cert # + i + = + xCert);
+ }
}
} catch (java.security.cert.CertificateException e) {
-throw new IOException(JDK's broken cert handling can't parse this
certificate (which PureTLS likes);
+ logger.info(JDK's broken cert handling can't parse this certificate
(which PureTLS likes),e);
+throw new IOException(JDK's broken cert handling can't parse this
certificate (which PureTLS likes));
}
return chain;
}
@@ -168,6 +176,10 @@
}
}
+
+
+
+
-
To unsubscribe,
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSE13Factory.java JSSE14Factory.java JSSEFactory.java JSSE14SocketFactory.java JSSE14Support.java JSSEImplementation.java JSSESocketFactory.java
billbarker2003/06/30 22:27:13
Modified:util/java/org/apache/tomcat/util/net/jsse Tag: coyote_10
JSSE14SocketFactory.java JSSE14Support.java
JSSEImplementation.java JSSESocketFactory.java
Added: util/java/org/apache/tomcat/util/net/jsse Tag: coyote_10
JSSE13Factory.java JSSE14Factory.java
JSSEFactory.java
Log:
Porting fixes from the HEAD branch.
Revision ChangesPath
No revision
No revision
1.2.2.2 +1 -1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java
Index: JSSE14SocketFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- JSSE14SocketFactory.java 27 Apr 2003 05:36:50 - 1.2.2.1
+++ JSSE14SocketFactory.java 1 Jul 2003 05:27:12 - 1.2.2.2
@@ -173,7 +173,7 @@
// create proxy
sslProxy = context.getServerSocketFactory();
-logger.debug(Init done);
+
return;
} catch(Exception e) {
if( e instanceof IOException )
1.4.2.2 +2 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14Support.java
Index: JSSE14Support.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14Support.java,v
retrieving revision 1.4.2.1
retrieving revision 1.4.2.2
diff -u -r1.4.2.1 -r1.4.2.2
--- JSSE14Support.java27 Apr 2003 05:36:50 - 1.4.2.1
+++ JSSE14Support.java1 Jul 2003 05:27:12 - 1.4.2.2
@@ -174,6 +174,8 @@
return null;
}
}
+ if(logger.isTraceEnabled())
+ logger.trace(Cert # + i + = + x509Certs[i]);
}
if(x509Certs.length 1)
return null;
1.1.2.2 +24 -45
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSEImplementation.java
Index: JSSEImplementation.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSEImplementation.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- JSSEImplementation.java 27 Apr 2003 05:36:50 - 1.1.2.1
+++ JSSEImplementation.java 1 Jul 2003 05:27:12 - 1.1.2.2
@@ -65,8 +65,6 @@
import org.apache.tomcat.util.net.ServerSocketFactory;
import java.io.*;
import java.net.*;
-import java.lang.reflect.Constructor;
-import javax.net.ssl.SSLSocket;
/* JSSEImplementation:
@@ -77,18 +75,33 @@
public class JSSEImplementation extends SSLImplementation
{
-static final String JSSE14SocketFactory =
-org.apache.tomcat.util.net.jsse.JSSE14SocketFactory;
-static final String JSSE14Support =
-org.apache.tomcat.util.net.jsse.JSSE14Support;
+static final String JSSE14Factory =
+org.apache.tomcat.util.net.jsse.JSSE14Factory;
+static final String JSSE13Factory =
+org.apache.tomcat.util.net.jsse.JSSE13Support;
static final String SSLSocketClass = javax.net.ssl.SSLSocket;
static org.apache.commons.logging.Log logger =
org.apache.commons.logging.LogFactory.getLog(JSSEImplementation.class);
+private JSSEFactory factory;
+
public JSSEImplementation() throws ClassNotFoundException {
// Check to see if JSSE is floating around somewhere
-Class.forName(javax.net.ssl.SSLServerSocketFactory);
+Class.forName(SSLSocketClass);
+ if( JdkCompat.isJava14() ) {
+ try {
+ Class factcl = Class.forName(JSSE14Factory);
+ factory = (JSSEFactory)factcl.newInstance();
+ } catch(Exception ex) {
+ factory = new JSSE13Factory();
+ if(logger.isDebugEnabled()) {
+ logger.debug(Error getting factory: + JSSE14Factory, ex);
+ }
+ }
+ } else {
+ factory = new JSSE13Factory();
+ }
}
@@ -96,47 +109,13 @@
return JSSE;
}
-public ServerSocketFactory getServerSocketFactory()
-{
-ServerSocketFactory ssf = null;
-if( JdkCompat.isJava14() ) {
-try {
-Class ssfCl = Class.forName(JSSE14SocketFactory);
-ssf =(ServerSocketFactory)ssfCl.newInstance();
-} catch(Exception ex) {
-
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
billbarker2003/06/30 22:42:00 Modified:.RELEASE-NOTES-4.1.txt Log: Documenting changes. Revision ChangesPath 1.73 +11 -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.72 retrieving revision 1.73 diff -u -r1.72 -r1.73 --- RELEASE-NOTES-4.1.txt 9 Apr 2003 03:20:51 - 1.72 +++ RELEASE-NOTES-4.1.txt 1 Jul 2003 05:42:00 - 1.73 @@ -915,6 +915,16 @@ [4.1.25] JkHandler: Fix decoding of SSL CLIENT-CERTs passed from Apache/IIS/iPlanet. +[4.1.25] mod_jk: + Fix potential path-traversal problem in mappings. + +[4.1.25] JSSE SSL: + Re-factor to remove dependencies on Sun classes when using a 1.4.x JVM. + It should now be possible to set up a SSL Connector with any vendors + 1.4.x JVM, without having to install Sun's JSSE 1.0.x. + +[4.1.25] PureTLS SSL: + Fix problems with getting the CLIENT-CERT. Jasper Bug Fixes: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
