RE: RegExp issues with Tomcat 5
On a side note, try using bind variables (prepared statements) in your sql statements. This way, you don't have to escape anything, gain performance and avoid sql-injection attacks. Slavik. -Original Message- From: Karl Coleman [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 10:01 PM To: Tomcat Users List Subject: RE: RegExp issues with Tomcat 5 Either. I'll look at the java.util.regex one. I posted at taglib-user earlier and still waiting for response. Thanks again. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 2:52 PM To: Tomcat Users List Subject: RE: RegExp issues with Tomcat 5 Hi, Is there a regexp library people recommend? I saw there is one on the Jakarta site. Library in general or JSP tag library specifically? I've been fine with java.util.regex, which I think requires JDK 1.4. If you must use a JDK older than 1.4, use jakarta-regexp (which tomcat uses). For a JSP tag library to handle regular expressions: I don't know and don't have time to research, but it does seem Glenn is actively working on the regexp taglib and I can't imagine its next release not working on tomcat 5. As I said previously, ask on taglib-user, and I'm sure he'll respond. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- This message contains information that may be confidential or privileged. If you are not the intended recipient, you may not use, copy or disclose to anyone any of the information in this message. If you have received this message and are not the intended recipient, kindly notify the sender and delete this message from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problems with adding Verisign root certificate to keystore
Just bumped into this problem myself. Didn't know that the ImportKey code exists so had to write my own :-(. I think that your problem is (based on the problem I had) that when you use ImportKey on the certificate you received from Verisign, you don't have a certificate chain to the intermediate CA. The simplest solution that worked for me was to edit the certificate from verisign and paste the intermediate certificate after your certificate thus creating the certificate chain. -BEGIN CERTIFICATE- Your certificate here -END CERTIFICATE- -BEGIN CERTIFICATE- Verisign intermediate certificate here -END CERTIFICATE- I think that the only reason it worked so far was that the intermediate certificate exists in IE predefined certificates (cached there under Tools-Internet Options-Content-Certificates-Intermediate Certificate Authorities). Hope that helps, Slavik. -Original Message- From: Jorrit Kronjee [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 12:08 PM To: [EMAIL PROTECTED] Subject: problems with adding Verisign root certificate to keystore Dear list, I've been browsing to the archives a bit, but I couldn't find what i am looking for, so I'll ask here. Since the expiration of one of the Verisign certificates, the SSL certificate on our Tomcat server is no longer valid. Back then I imported the key and certificate with ImportKey from http://www.computer-mutter.de/docs/tomcat_ssl/comu/ImportKey.java That still works, but somehow I can't add the new Verisign certificate too. I've tried adding it with alias root through keytool, but it doesn't seem to work. I also added the new certificates from Verisign to cacerts as http://sunsolve.sun.com/pub-cgi/retrieve.pl?type=0doc=fsalert/57436 suggests. What am I doing wrong? Thanks in advance, Jorrit -- InfoPact Netwerkdiensten B.V. http://www.infopact.nl/ Emmastraat 11-13 3255 BD Oude Tonge tel. +31(0)187-64 77 11 fax. +31(0)187-64 77 99 --- This message contains information that may be confidential or privileged. If you are not the intended recipient, you may not use, copy or disclose to anyone any of the information in this message. If you have received this message and are not the intended recipient, kindly notify the sender and delete this message from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problems with RequestFilterValve
Sorry Yoav, As you know, threading (race-condition) issues are really hard to test and come up with a test case. They are by nature very machine, cpu, etc. dependent. Synchronizing the process method would be a bad idea (bottleneck for all requests) so it looks like there won't be any choice but to recreate the RE as local variables. There is also a possibility (ugly one) of serializing the array of RE to a byte array and de-serializing it in the process method. Thoughts? Slavik. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, December 29, 2003 4:50 PM To: Tomcat Users List Subject: RE: Problems with RequestFilterValve Howdy, This could actually be a bug! (This is refreshing and exciting to me, because there's about 1 of these for every 100 supposed bugs that are user errors). (And this is a slow week). ;) Can you come up with a simple unit test in a WAR file that will demonstrate this behavior so that we can reproduce it? If so, please create a bugzilla item and attach your test WAR and observations. Looking at the code, I probably wouldn't want to synchronize the process(..) method. Hmm... Yoav Shapira Millennium ChemInformatics -Original Message- From: Slavik Markovich [mailto:[EMAIL PROTECTED] Sent: Sunday, December 28, 2003 4:56 AM To: [EMAIL PROTECTED] Subject: Problems with RequestFilterValve Hi All, I'm having some problems with using RemoteAddrValve to allow only certain addresses to access an Engine. I'm using tomcat 4.1.27 with jdk1.3.1 on Solaris. I've configured the following: Valve className=org.apache.catalina.valves.RemoteAddrValve allow=a.b.c.d/ under the engine. I know I should have escaped the '.' (regexp) but it should work as is. I'm receiving once in every few thousands of requests the following error: 2003-12-26 11:26:51 CoyoteAdapter An exception or error occurred in the container during the request processing java.lang.StringIndexOutOfBoundsException: String index out of range: 11 at java.lang.String.charAt(String.java:511) at org.apache.regexp.StringCharacterIterator.charAt(StringCharacterIterato r.ja va:90) at org.apache.regexp.RE.matchNodes(RE.java:1161) at org.apache.regexp.RE.matchAt(RE.java:1448) at org.apache.regexp.RE.match(RE.java:1540) at org.apache.regexp.RE.match(RE.java:1468) at org.apache.regexp.RE.match(RE.java:1561) at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValv e.ja va:335) at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java: 131) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:57 7) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:6 01) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process Conn ection(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:5 65) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPoo l.ja va:619) at java.lang.Thread.run(Thread.java:479) Also, once in every few thousands of requests I'm receiving a 403 access denied error on a valid address (I can see that in the access log). After checking the RequestFilterValve class, I can see it saves the compiled regular expressions (RE) and reuses them to check every request. Looking at regexp documentations, it is explicitly stated that RE is not thread-safe. Am I missing something? It looks like under load, this valve fails. Also, I can see that the RequestFilterValve class didn't change in the 5.0.16 version either. Any help will be appreciated... Slavik. --- This message contains information that may be confidential or privileged. If you are not the intended recipient, you may not use, copy or disclose to anyone any of the information in this message. If you have received this message and are not the intended recipient, kindly notify the sender and delete this message from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged
Problems with RequestFilterValve
Hi All, I'm having some problems with using RemoteAddrValve to allow only certain addresses to access an Engine. I'm using tomcat 4.1.27 with jdk1.3.1 on Solaris. I've configured the following: Valve className=org.apache.catalina.valves.RemoteAddrValve allow=a.b.c.d/ under the engine. I know I should have escaped the '.' (regexp) but it should work as is. I'm receiving once in every few thousands of requests the following error: 2003-12-26 11:26:51 CoyoteAdapter An exception or error occurred in the container during the request processing java.lang.StringIndexOutOfBoundsException: String index out of range: 11 at java.lang.String.charAt(String.java:511) at org.apache.regexp.StringCharacterIterator.charAt(StringCharacterIterator.java:90) at org.apache.regexp.RE.matchNodes(RE.java:1161) at org.apache.regexp.RE.matchAt(RE.java:1448) at org.apache.regexp.RE.match(RE.java:1540) at org.apache.regexp.RE.match(RE.java:1468) at org.apache.regexp.RE.match(RE.java:1561) at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:335) at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:131) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:601) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619) at java.lang.Thread.run(Thread.java:479) Also, once in every few thousands of requests I'm receiving a 403 access denied error on a valid address (I can see that in the access log). After checking the RequestFilterValve class, I can see it saves the compiled regular expressions (RE) and reuses them to check every request. Looking at regexp documentations, it is explicitly stated that RE is not thread-safe. Am I missing something? It looks like under load, this valve fails. Also, I can see that the RequestFilterValve class didn't change in the 5.0.16 version either. Any help will be appreciated... Slavik. --- This message contains information that may be confidential or privileged. If you are not the intended recipient, you may not use, copy or disclose to anyone any of the information in this message. If you have received this message and are not the intended recipient, kindly notify the sender and delete this message from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
