Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Thank-you for your e-mail. Please note that i will be away from the office starting Wednesday June 29th, returning Thursday July 7th, with no access to email. In my absence, kindly contact Cheri Dueck at [EMAIL PROTECTED] Kind Regards, Natasha Hasmani Senior Event Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Thank-you for your e-mail. Please note that i will be away from the office starting Wednesday June 29th, returning Thursday July 7th, with no access to email. In my absence, kindly contact Cheri Dueck at [EMAIL PROTECTED] Kind Regards, Natasha Hasmani Senior Event Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Thank-you for your e-mail. Please note that i will be away from the office starting Wednesday June 29th, returning Thursday July 7th, with no access to email. In my absence, kindly contact Cheri Dueck at [EMAIL PROTECTED] Kind Regards, Natasha Hasmani Senior Event Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Thank-you for your e-mail. Please note that i will be away from the office starting Wednesday June 29th, returning Thursday July 7th, with no access to email. In my absence, kindly contact Cheri Dueck at [EMAIL PROTECTED] Kind Regards, Natasha Hasmani Senior Event Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
On Thu, Jun 30, 2005 at 06:02:22PM +0200, Mladen Turk wrote: Jeanfrancois Arcand wrote: Actually, on Solaris the big winner is ChannelNioSocket. It wins the performance race easily now. Too bad that NIO on Windows s*cks. I guess that JFA was right, and non-blocking sockets is the way to go. He he. We shall see :) :-). Just take a look at the GlassFish module called appserv-http-engine on java.net (http://weblogs.java.net/blog/jfarcand/). I'm sure you will like it :-). And I'm sure this community can come with something even better Well I'm sure only of the following: 1. Blocking sockets outperforms NIO 2. NIO scales better So the ideal would be to have them both at once. Perhaps one day the Sun will accept some of my ideas and allow to intermix the blocking and nonblocking IO. That sounds great! Nice idea. Never thought about it. Let's say... something like a hybrid solution... that would be interesting. -Vicenç Until then, well, I have 64 bit JVM and a 1GB RAM for couple of bucks, and APR of course :) Regards, Mladen. - 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: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Vicenc Beltran Querol wrote: That sounds great! Nice idea. Never thought about it. Let's say... something like a hybrid solution... that would be interesting. I got used to useless statements coming from you. I see a trend now. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
[EMAIL PROTECTED] wrote: billbarker2005/06/29 19:49:38 With a 16K bufferSize, the APR connector is no longer the clear winner in performance. For BC, it's currently disabled by default, but it's easy enough to change that after some more testing. Yes, I can see performance is better too. It's also possible that taking the APR code, and rewriting it with regular Java IO would also yield slightly better results (regular HTTP is still a little faster than APR HTTP - some VMs make the difference very small, but the VM I use for testing is definitely not the best for JNI). Now that I've looked at it a lot, however, I dislike the Java AJP impl, as it's way overengineered in comparison to what it required by the current Tomcat. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Remy Maucherat schrieb: [EMAIL PROTECTED] wrote: billbarker2005/06/29 19:49:38 With a 16K bufferSize, the APR connector is no longer the clear winner in performance. For BC, it's currently disabled by default, but it's easy enough to change that after some more testing. Yes, I can see performance is better too. It's also possible that taking the APR code, and rewriting it with regular Java IO would also yield slightly better results (regular HTTP is still a little faster than APR HTTP - some VMs make the difference very small, but the VM I use for testing is definitely not the best for JNI). Now that I've looked at it a lot, however, I dislike the Java AJP impl, as it's way overengineered in comparison to what it required by the current Tomcat. Very true I don't like this part of the source. I think we can implement the AJP integration simpler and extract the jk2 mbeans and mx4j JMX integration. Peter Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, June 30, 2005 3:39 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java [EMAIL PROTECTED] wrote: billbarker2005/06/29 19:49:38 With a 16K bufferSize, the APR connector is no longer the clear winner in performance. For BC, it's currently disabled by default, but it's easy enough to change that after some more testing. Yes, I can see performance is better too. It's also possible that taking the APR code, and rewriting it with regular Java IO would also yield slightly better results (regular HTTP is still a little faster than APR HTTP - some VMs make the difference very small, but the VM I use for testing is definitely not the best for JNI). Actually, on Solaris the big winner is ChannelNioSocket. It wins the performance race easily now. Too bad that NIO on Windows s*cks. I guess that JFA was right, and non-blocking sockets is the way to go. Now that I've looked at it a lot, however, I dislike the Java AJP impl, as it's way overengineered in comparison to what it required by the current Tomcat. Hey, I like the overengineering ;-). Yeah, Costin got a little ambitious here before deciding to just use Coyote. On the other hand, when Mladen wants you to implement unix sockets for AJP/APR, ChannelUn is going to start to look good ;-). Rémy This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Bill Barker wrote: Actually, on Solaris the big winner is ChannelNioSocket. It wins the performance race easily now. Too bad that NIO on Windows s*cks. I guess that JFA was right, and non-blocking sockets is the way to go. He he. We shall see :) Now that I've looked at it a lot, however, I dislike the Java AJP impl, as it's way overengineered in comparison to what it required by the current Tomcat. Hey, I like the overengineering ;-). Yeah, Costin got a little ambitious here before deciding to just use Coyote. On the other hand, when Mladen wants you to implement unix sockets for AJP/APR, ChannelUn is going to start to look good ;-). Well, ChannelUn is obsolete because there is no need to add the additional JNI wrapper, because we already have one. Both unix sockets and NT pipes will be supported, by adding a single param 'localAddress' or something. The platform local socket AF_UNIX or NTPIPE will be used depending on the platform itself. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Bill Barker wrote: Actually, on Solaris the big winner is ChannelNioSocket. It wins the performance race easily now. Too bad that NIO on Windows s*cks. I guess that JFA was right, and non-blocking sockets is the way to go. Lol, sure, I'll think about it ;) Hey, I like the overengineering ;-). Yeah, Costin got a little ambitious here before deciding to just use Coyote. On the other hand, when Mladen wants you to implement unix sockets for AJP/APR, ChannelUn is going to start to look good ;-). Well, face it: the only thing which saves all this code is that it's there, and working (ChannelSocket is, at least). Besides this, a lot of it is complexity which didn't turn out to be needed. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Mladen Turk wrote: Bill Barker wrote: Actually, on Solaris the big winner is ChannelNioSocket. It wins the performance race easily now. Too bad that NIO on Windows s*cks. I guess that JFA was right, and non-blocking sockets is the way to go. He he. We shall see :) :-). Just take a look at the GlassFish module called appserv-http-engine on java.net (http://weblogs.java.net/blog/jfarcand/). I'm sure you will like it :-). And I'm sure this community can come with something even better -- Jeanfrancois Now that I've looked at it a lot, however, I dislike the Java AJP impl, as it's way overengineered in comparison to what it required by the current Tomcat. Hey, I like the overengineering ;-). Yeah, Costin got a little ambitious here before deciding to just use Coyote. On the other hand, when Mladen wants you to implement unix sockets for AJP/APR, ChannelUn is going to start to look good ;-). Well, ChannelUn is obsolete because there is no need to add the additional JNI wrapper, because we already have one. Both unix sockets and NT pipes will be supported, by adding a single param 'localAddress' or something. The platform local socket AF_UNIX or NTPIPE will be used depending on the platform itself. Regards, Mladen. - 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: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Jeanfrancois Arcand wrote: :-). Just take a look at the GlassFish module called appserv-http-engine on java.net (http://weblogs.java.net/blog/jfarcand/). I'm sure you will like it :-). And I'm sure this community can come with something even better Yes, I do like parts of it: I'd say 80% of it is just a cool cut paste of my HTTP code. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Jeanfrancois Arcand wrote: Actually, on Solaris the big winner is ChannelNioSocket. It wins the performance race easily now. Too bad that NIO on Windows s*cks. I guess that JFA was right, and non-blocking sockets is the way to go. He he. We shall see :) :-). Just take a look at the GlassFish module called appserv-http-engine on java.net (http://weblogs.java.net/blog/jfarcand/). I'm sure you will like it :-). And I'm sure this community can come with something even better Well I'm sure only of the following: 1. Blocking sockets outperforms NIO 2. NIO scales better So the ideal would be to have them both at once. Perhaps one day the Sun will accept some of my ideas and allow to intermix the blocking and nonblocking IO. Until then, well, I have 64 bit JVM and a 1GB RAM for couple of bucks, and APR of course :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Remy Maucherat wrote: Jeanfrancois Arcand wrote: :-). Just take a look at the GlassFish module called appserv-http-engine on java.net (http://weblogs.java.net/blog/jfarcand/). I'm sure you will like it :-). And I'm sure this community can come with something even better Yes, I do like parts of it: I'd say 80% of it is just a cool cut paste of my HTTP code. LOL :-) Don't know what formula you used to get 80% (might be more :-)) , but why would I re-write something that works pretty well :-). Coyote/http11 was well designed, so was easy to extends. I got rid of the thread pool and replaced the front end with an nio non blocking approach, similar to what you did for APR. -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Jeanfrancois Arcand wrote: LOL :-) Don't know what formula you used to get 80% (might be more :-)) , but why would I re-write something that works pretty well :-). Coyote/http11 was well designed, so was easy to extends. I got rid of the thread pool and replaced the front end with an nio non blocking approach, similar to what you did for APR. Well, all I know is that I only very casually looked at it, and that I should probably not do anything more. For all I know of Sun, you guys might well have patents for it in the pipe, and even if you don't, I am not allowed to reuse the code (and likely not reimplement it after looking at it either). So you can tease me all you want about looking at it in depth: forget it, I will not :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
[EMAIL PROTECTED] wrote: Give Remy something meaningful to benchmark against ;-). Mladen did all the preliminary tests using the HTTP example server that is in the mustang sources, which is a similar comparison. It also has extra GC vs Remy's ChannelAprSocket. ... which will never exist ;) I don't think the way AJP connections are currently processed makes this suitable for this kind of usage, as the GC would likely be too high. Did you test it ? I'll implement the APRized AJP using the same infrastructure (AprEndpoint) and architecture as the HTTP connector, which means socket only. Right now, I'm having more fun trying to add sendfile support (with ranges support). I'll have to make small changes in DefaultServlet to enable it, but nothing that would imapct the default behavior, of course. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Sunday, April 17, 2005 12:22 PM Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java [EMAIL PROTECTED] wrote: Give Remy something meaningful to benchmark against ;-). Mladen did all the preliminary tests using the HTTP example server that is in the mustang sources, which is a similar comparison. It also has extra GC vs Remy's ChannelAprSocket. ... which will never exist ;) I don't think the way AJP connections are currently processed makes this suitable for this kind of usage, as the GC would likely be too high. Did you test it ? On Solaris, threads are really cheap, so ChannelSocket would alway win anyway (just on the context-switching alone :). And, yes, the GC is too high. The only use-case for ChannelNioSocket would be a system where you are forced to set a connectionTimeout for ChannelSocket to keep Tomcat happy, and what that is telling you is that you really need a better OS. I admit that it was somewhat of a vanity project (like a lot of stuff in Jk :), but since almost nobody knows Jk-Coyote well enough to enable it, it seemed harmless. I also have no problem yanking it if all it's going to do is to create tomcat-user questions. I'll implement the APRized AJP using the same infrastructure (AprEndpoint) and architecture as the HTTP connector, which means socket only. Right now, I'm having more fun trying to add sendfile support (with ranges support). I'll have to make small changes in DefaultServlet to enable it, but nothing that would imapct the default behavior, of course. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java JkCoyoteHandler.java
Remy Maucherat a écrit : [EMAIL PROTECTED] wrote: hgomez 2003/09/18 09:21:02 Modified:jk/java/org/apache/jk/common Shm.java JniHandler.java MsgAjp.java ChannelShm.java WorkerDummy.java ChannelUn.java ChannelJni.java jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java Ajp13Request.java Ajp13Connector.java JkServlet.java jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java jk/java/org/apache/jk/apr TomcatStarter.java jk/java/org/apache/jk/config GeneratorJk1.java GeneratorApache2.java GeneratorJk2.java WebXml2Jk.java jk/java/org/apache/ajp AjpHandler.java NegociationHandler.java Ajp13Packet.java RequestHandler.java Ajp13.java jk/java/org/apache/jk/core MsgContext.java Msg.java jk/java/org/apache/ajp/tomcat4/config ApacheConfig.java jk/java/org/apache/jk/server JkMain.java JkCoyoteHandler.java Log: Last batch of clean import. More next week (if Remy didn't drop my commiter status before ;) I'm not root, I can't do that ;-) Anyway, it's weird, I thought I had done it already. Eclipse sucks (or I misconfigured it, which is likely) :) I'm using Eclipse 2.1.1 and the settings is to : Prefs/Java/Compiler : Unused Locale Variables and Unused Imports should be set to Warning ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java JkCoyoteHandler.java
[EMAIL PROTECTED] wrote: hgomez 2003/09/18 09:21:02 Modified:jk/java/org/apache/jk/common Shm.java JniHandler.java MsgAjp.java ChannelShm.java WorkerDummy.java ChannelUn.java ChannelJni.java jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java Ajp13Request.java Ajp13Connector.java JkServlet.java jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java jk/java/org/apache/jk/apr TomcatStarter.java jk/java/org/apache/jk/config GeneratorJk1.java GeneratorApache2.java GeneratorJk2.java WebXml2Jk.java jk/java/org/apache/ajp AjpHandler.java NegociationHandler.java Ajp13Packet.java RequestHandler.java Ajp13.java jk/java/org/apache/jk/core MsgContext.java Msg.java jk/java/org/apache/ajp/tomcat4/config ApacheConfig.java jk/java/org/apache/jk/server JkMain.java JkCoyoteHandler.java Log: Last batch of clean import. More next week (if Remy didn't drop my commiter status before ;) I'm not root, I can't do that ;-) Anyway, it's weird, I thought I had done it already. Eclipse sucks (or I misconfigured it, which is likely) :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Title: RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Impressively fast fix.
Seeing what you've fixed, I can now reinterpret the Sun documentation and see what was going on.
Thanks.
PJDM
--
Peter Mayne
Technology Consultant
Spherion Technology Solutions
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
T: 61 2 62689727 F: 61 2 62689777
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 2 July 2003 4:33 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
billbarker 2003/07/01 23:33:17
Modified: jk/java/org/apache/jk/server Tag: coyote_10 JkMain.java
Log:
The beauty of cut-and paste is that I can be brain-dead in
multiple locations ;-).
Revision Changes Path
No revision
No revision
1.32.2.2 +1 -1
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/serv
er/JkMain.java,v
retrieving revision 1.32.2.1
retrieving revision 1.32.2.2
diff -u -r1.32.2.1 -r1.32.2.2
--- JkMain.java 2 Jul 2003 03:44:32 - 1.32.2.1
+++ JkMain.java 2 Jul 2003 06:33:16 - 1.32.2.2
@@ -282,7 +282,7 @@
log.warn( No properties file found
+ propsF );
}
}
- String initHTTPS = props.get(class.initHTTPS);
+ String initHTTPS = (String)props.get(class.initHTTPS);
if(true.equalsIgnoreCase(initHTTPS)) {
initHTTPSUrls();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The information contained in this email and any attachments to it:
(a) may be confidential and if you are not the intended recipient, any interference with,
use, disclosure or copying of this material is unauthorised and prohibited; and
(b) may contain personal information of the recipient and/or the sender as defined
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to
collect, hold and use such information and any personal information contained in a
response to this email, for any reasonable purpose in the ordinary course of
Spherion's
business, including forwarding this email internally or disclosing it to a third party. All
personal information collected by Spherion will be handled in accordance with
Spherion's Privacy Policy. If you have received this email in error, please notify the
sender and delete it.
(c) you agree not to employ or arrange employment for any candidate(s) supplied in
this email and any attachments without first entering into a contractual agreement with
Spherion. You further agree not to divulge any information contained in this document
to any person(s) or entities without the express permission of Spherion.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
I doesnt have any problems with redirs with Coyote/jk2 using https in
IIS, AFAIK the only use URL class had, was to try to get a absolute RUL
or something like that, with a Method Craig did many time ago this
should be unnecssary...
I wonder how do you did the tests?
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: 3 de octubre de 2002 21:32
Para: [EMAIL PROTECTED]
Asunto: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/10/03 12:31:31
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
If only Ajp connector is used, nobody will initialize the
https: handler
and redirects for https sites will fail ( a URL constructor
is used somewhere ).
PR: 11657
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.30 +20 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/serv
er/JkMain.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JkMain.java 9 Aug 2002 20:54:23 - 1.29
+++ JkMain.java 3 Oct 2002 19:31:31 - 1.30
@@ -124,12 +124,32 @@
modules.put(shm, org.apache.jk.common.Shm);
modules.put(request,org.apache.jk.common.HandlerRequest);
modules.put(container,org.apache.jk.common.HandlerRequest);
+
+initHTTPSUrls();
}
public static JkMain getJkMain() {
return jkMain;
}
+private static String
DEFAULT_HTTPS=com.sun.net.ssl.internal.www.protocol;
+private void initHTTPSUrls() {
+try {
+// 11657: if only ajp is used, https:
redirects need to work ( at least for 1.3+)
+String value =
System.getProperty(java.protocol.handler.pkgs);
+if (value == null) {
+value = DEFAULT_HTTPS;
+} else if (value.indexOf(DEFAULT_HTTPS) = 0 ) {
+return; // already set
+} else {
+value += | + DEFAULT_HTTPS;
+}
+
System.setProperty(java.protocol.handler.pkgs, value);
+} catch(Exception ex ) {
+ex.printStackTrace();
+}
+}
+
// Setting
/** Load a .properties file into and set the values
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
- Original Message -
From: Ignacio J. Ortega [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Sent: Thursday, October 03, 2002 1:36 PM
Subject: RE: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
I doesnt have any problems with redirs with Coyote/jk2 using https in
IIS, AFAIK the only use URL class had, was to try to get a absolute RUL
or something like that, with a Method Craig did many time ago this
should be unnecssary...
I wonder how do you did the tests?
It seems that o.a.c.tomcat4/5.CoyoteResponse is using java.net.URL instead
of Craig's o.a.c.u.URL or (the same class for 3.3) o.a.t.u.net.URL. AFAIK,
changing the import statement in CoyoteResponse should remove the need for
JSSE with Coyote/jk2 for TC 4/5 (3.3 shouldn't be affected).
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: 3 de octubre de 2002 21:32
Para: [EMAIL PROTECTED]
Asunto: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/10/03 12:31:31
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
If only Ajp connector is used, nobody will initialize the
https: handler
and redirects for https sites will fail ( a URL constructor
is used somewhere ).
PR: 11657
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.30 +20 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/serv
er/JkMain.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JkMain.java 9 Aug 2002 20:54:23 - 1.29
+++ JkMain.java 3 Oct 2002 19:31:31 - 1.30
@@ -124,12 +124,32 @@
modules.put(shm, org.apache.jk.common.Shm);
modules.put(request,org.apache.jk.common.HandlerRequest);
modules.put(container,org.apache.jk.common.HandlerRequest);
+
+initHTTPSUrls();
}
public static JkMain getJkMain() {
return jkMain;
}
+private static String
DEFAULT_HTTPS=com.sun.net.ssl.internal.www.protocol;
+private void initHTTPSUrls() {
+try {
+// 11657: if only ajp is used, https:
redirects need to work ( at least for 1.3+)
+String value =
System.getProperty(java.protocol.handler.pkgs);
+if (value == null) {
+value = DEFAULT_HTTPS;
+} else if (value.indexOf(DEFAULT_HTTPS) = 0 ) {
+return; // already set
+} else {
+value += | + DEFAULT_HTTPS;
+}
+
System.setProperty(java.protocol.handler.pkgs, value);
+} catch(Exception ex ) {
+ex.printStackTrace();
+}
+}
+
// Setting
/** Load a .properties file into and set the values
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
De: Bill Barker [mailto:[EMAIL PROTECTED]] Enviado el: 3 de octubre de 2002 22:52 It seems that o.a.c.tomcat4/5.CoyoteResponse is using java.net.URL instead of Craig's o.a.c.u.URL or (the same class for 3.3) o.a.t.u.net.URL. AFAIK, changing the import statement in CoyoteResponse should remove the need for JSSE with Coyote/jk2 for TC 4/5 (3.3 shouldn't be affected). Ok.. this should be fixed too, but i doenst understand why it works for me using Coyote/JK2.. because i have the JSSE jars on my ext dir simply? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Bill Barker wrote:
I doesnt have any problems with redirs with Coyote/jk2 using https in
IIS, AFAIK the only use URL class had, was to try to get a absolute RUL
or something like that, with a Method Craig did many time ago this
should be unnecssary...
I wonder how do you did the tests?
It seems that o.a.c.tomcat4/5.CoyoteResponse is using java.net.URL instead
of Craig's o.a.c.u.URL or (the same class for 3.3) o.a.t.u.net.URL.
AFAIK, changing the import statement in CoyoteResponse should remove the
need for JSSE with Coyote/jk2 for TC 4/5 (3.3 shouldn't be affected).
Unless some other piece of code is using URLs.
I think it is safer to just set the system property - I don't think it
can hurt anyone, and it would allow https:// URLs to work. And it'll
eliminate a difference between running tomcat standalone and with a web
server.
If you think it's a better idea to findfix the uses of URL - I can roll
back.
Costin
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: 3 de octubre de 2002 21:32
Para: [EMAIL PROTECTED]
Asunto: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/10/03 12:31:31
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
If only Ajp connector is used, nobody will initialize the
https: handler
and redirects for https sites will fail ( a URL constructor
is used somewhere ).
PR: 11657
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.30 +20 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/serv
er/JkMain.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JkMain.java 9 Aug 2002 20:54:23 - 1.29
+++ JkMain.java 3 Oct 2002 19:31:31 - 1.30
@@ -124,12 +124,32 @@
modules.put(shm, org.apache.jk.common.Shm);
modules.put(request,org.apache.jk.common.HandlerRequest);
modules.put(container,org.apache.jk.common.HandlerRequest);
+
+initHTTPSUrls();
}
public static JkMain getJkMain() {
return jkMain;
}
+private static String
DEFAULT_HTTPS=com.sun.net.ssl.internal.www.protocol;
+private void initHTTPSUrls() {
+try {
+// 11657: if only ajp is used, https:
redirects need to work ( at least for 1.3+)
+String value =
System.getProperty(java.protocol.handler.pkgs);
+if (value == null) {
+value = DEFAULT_HTTPS;
+} else if (value.indexOf(DEFAULT_HTTPS) = 0 ) {
+return; // already set
+} else {
+value += | + DEFAULT_HTTPS;
+}
+
System.setProperty(java.protocol.handler.pkgs, value);
+} catch(Exception ex ) {
+ex.printStackTrace();
+}
+}
+
// Setting
/** Load a .properties file into and set the values
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, October 03, 2002 2:37 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Bill Barker wrote:
I doesnt have any problems with redirs with Coyote/jk2 using https in
IIS, AFAIK the only use URL class had, was to try to get a absolute RUL
or something like that, with a Method Craig did many time ago this
should be unnecssary...
I wonder how do you did the tests?
It seems that o.a.c.tomcat4/5.CoyoteResponse is using java.net.URL
instead
of Craig's o.a.c.u.URL or (the same class for 3.3) o.a.t.u.net.URL.
AFAIK, changing the import statement in CoyoteResponse should remove the
need for JSSE with Coyote/jk2 for TC 4/5 (3.3 shouldn't be affected).
Unless some other piece of code is using URLs.
I think it is safer to just set the system property - I don't think it
can hurt anyone, and it would allow https:// URLs to work. And it'll
eliminate a difference between running tomcat standalone and with a web
server.
If you think it's a better idea to findfix the uses of URL - I can roll
back.
This seems to be the only place in j-t-c it's being used (at least with a
quick check). I was planning to fix it if only because I'd rather continue
not having to install JSSE. A little less selfish reason is that it also
keeps people from complaining that weird things like:
response.sendRedirect(response.encodeURL(news://));
aren't working. ;-)
I agree that you're patch is harmless, and is a fall-back for systems with
JSSE installed. Personally, I don't see any reason to roll back.
Costin
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: 3 de octubre de 2002 21:32
Para: [EMAIL PROTECTED]
Asunto: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/10/03 12:31:31
Modified:jk/java/org/apache/jk/server JkMain.java
Log:
If only Ajp connector is used, nobody will initialize the
https: handler
and redirects for https sites will fail ( a URL constructor
is used somewhere ).
PR: 11657
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.30 +20 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/serv
er/JkMain.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JkMain.java 9 Aug 2002 20:54:23 - 1.29
+++ JkMain.java 3 Oct 2002 19:31:31 - 1.30
@@ -124,12 +124,32 @@
modules.put(shm, org.apache.jk.common.Shm);
modules.put(request,org.apache.jk.common.HandlerRequest);
modules.put(container,org.apache.jk.common.HandlerRequest);
+
+initHTTPSUrls();
}
public static JkMain getJkMain() {
return jkMain;
}
+private static String
DEFAULT_HTTPS=com.sun.net.ssl.internal.www.protocol;
+private void initHTTPSUrls() {
+try {
+// 11657: if only ajp is used, https:
redirects need to work ( at least for 1.3+)
+String value =
System.getProperty(java.protocol.handler.pkgs);
+if (value == null) {
+value = DEFAULT_HTTPS;
+} else if (value.indexOf(DEFAULT_HTTPS) = 0 ) {
+return; // already set
+} else {
+value += | + DEFAULT_HTTPS;
+}
+
System.setProperty(java.protocol.handler.pkgs, value);
+} catch(Exception ex ) {
+ex.printStackTrace();
+}
+}
+
// Setting
/** Load a .properties file into and set the values
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
Costin
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
