Re: Site-SVN link
Yoav Shapira wrote: Hi, I think it's OK now to have /www/jakarta.apache.org/tomcat be a checkout of the SVN tomcat/site/trunk. I just updated SVN tomcat/site/trunk to show 5.5.12 is latest stable, and committed, but the SVN update is still looking at the old version... Looking in .svn/entries: +++ url=http://svn.apache.org/repos/asf/tomcat/site/branches/pre-tlp/docs; +++ What is in /www/jakarta.apache.org/tomcat belongs to a branch pre-tlp. Cheers Jean-Frederic Yoav - 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: [VOTE] JK 1.2.15
Henri Gomez wrote: Well the build on iSeries failed : /home/apache/jk/native/apache-2.0/mod_jk.c, 86.10: CZM0296(30) £include file unixd.h not found. /home/apache/jk/native/apache-2.0/mod_jk.c, 2437.10: CZM0304(10) No function prototype given for unixd_set_global_mutex_perms. Should add in mod_jk.c line 78 (I still can't commit on jtc ) # if !defined(OS2) !defined(WIN32) !defined(BEOS) !defined(NETWARE) !defined(AS400) Not very good... We should detect unixd.h. - 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: mod_jk 1.2.14.1 core dump
David Rees wrote: I'm getting a core dump on my SGI IRIX machine using mod_jk 1.2.14.1 in jk_lb_worker.c line 605. The stack trace is below. This happens on any JK request I try. Going back to 1.2.11 works fine. Any ideas? When does it happend? -Dave 0 service(e = 0x1035afe8, s = 0x7fff2b28, l = 0x10281f68, is_error = 0x7fff1af4) [/tmp/jakarta-tomcat-connectors-1.2.14.1-src/jk/native/common/jk_lb_worker.c:605, 0x4315080] 1 jk_handler(r = 0x103719a0) [/tmp/jakarta-tomcat-connectors-1.2.14.1-src/jk/native/apache-2.0/mod_jk.c:1889, 0x4305648] 2 ap_run_handler(r = 0x103719a0) [/tmp/httpd-2.0.54/server/config.c:152, 0x1008b624] 3 ap_invoke_handler(r = 0x103719a0) [/tmp/httpd-2.0.54/server/config.c:364, 0x1008c390] 4 ap_process_request(r = 0x103719a0) [/tmp/httpd-2.0.54/modules/http/http_request.c:249, 0x10071990] 5 ap_process_http_connection(c = 0x10365460) [/tmp/httpd-2.0.54/modules/http/http_core.c:251, 0x10070f78] 6 ap_run_process_connection(c = 0x10365460) [/tmp/httpd-2.0.54/server/connection.c:43, 0x100a3e94] 7 ap_process_connection(c = 0x10365460, csd = 0x10365378) [/tmp/httpd-2.0.54/server/connection.c:176, 0x100a4568] 8 child_main(child_num_arg = 0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:610, 0x1007c444] 9 make_child(s = 0x102941c0, slot = 0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:704, 0x1007c6ac] 10 startup_children(number_to_start = 5) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:722, 0x1007c75c] 11 ap_mpm_run(_pconf = 0x1025aac0, plog = 0x1028cb88, s = 0x102941c0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:941, 0x1007cda0] 12 main(argc = 3, argv = 0x7fff2f44) [/tmp/httpd-2.0.54/server/main.c:618, 0x100b1c48] 13 __start() [/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s:177, 0x1004b9e8] - 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/jni/native/include tcn.h
Now I am not sure that the right correction: - sablevm uses short names first so it should work without the additional __J - tracing in sableVM shows that the JNI_OnLoad fails. That probably a classloader problem (org/apache/tomcat/jni/FileInfo is not found but java/lang/String is found), any hint? Cheers Jean-Frederic [EMAIL PROTECTED] wrote: jfclere 2005/08/27 09:14:50 Modified:jni/native/include tcn.h Log: Add support for sableVM. Revision ChangesPath 1.31 +6 -1 jakarta-tomcat-connectors/jni/native/include/tcn.h Index: tcn.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/include/tcn.h,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- tcn.h 12 Jul 2005 14:56:10 - 1.30 +++ tcn.h 27 Aug 2005 16:14:50 - 1.31 @@ -100,8 +100,13 @@ #define TCN_IMPARGS JNIEnv *e, jobject o, void *sock #define TCN_IMPCALL(X) e, o, X-opaque +#ifdef HAVE_SABLEVM +#define TCN_IMPLEMENT_CALL(RT, CL, FN) \ +JNIEXPORT RT JNICALL Java_org_apache_tomcat_jni_##CL##_##FN##__J +#else #define TCN_IMPLEMENT_CALL(RT, CL, FN) \ JNIEXPORT RT JNICALL Java_org_apache_tomcat_jni_##CL##_##FN +#endif #define TCN_IMPLEMENT_METHOD(RT, FN)\ static RT method_##FN - 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: mod_jk logging buffer
Mladen Turk wrote:
Jean-frederic Clere wrote:
Radek Wierzbicki wrote:
Hello,
better :
if (l-level JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG ||
level==JK_LOG_ERROR)
No?
Flush should not be executed for INFO level. It slows the things
down by the factor of 2. I agree for ERROR and EMERG.
DEBUG and TRACE uses fflush so the order of messages can be traced,
but that is also dubious because the messages could come from
different threads, so the best would be to use the fflush only
with ERROR and EMERGE levels.
So it is OK to commit the following:
++
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
retrieving revision 1.71
diff -u -r1.71 jk_util.c
--- common/jk_util.c1 Jul 2005 15:41:08 - 1.71
+++ common/jk_util.c14 Aug 2005 18:28:29 -
@@ -186,7 +186,7 @@
fwrite(what, 1, sz, p-logfile);
fputc('\n', p-logfile);
/* [V] Flush the dam' thing! */
-if (l-level JK_LOG_INFO_LEVEL)
+if (l-level JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG ||
level==JK_LOG_ERROR)
fflush(p-logfile);
}
++
isn't it?
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: mod_jk logging buffer
Radek Wierzbicki wrote:
Hello,
I see a problem with logging mechanism in mod_jk 1.2.14.1. The logger
buffers and delays the output of messages with levels below 'info'
(info, warning, error, emergency, request).
With the new version, setting the log level to 'error' on production
setups will delay the output of critical error messages. I think that
is unacceptable.
Wouldn't it make sense to reverse the logic and immediatelly flush the
log messages with level 'info' and below, and buffer 'debug' and
'trace' messages?
Maybe a configuration option for log buffering would make sense?
Patch:
--- jk_util.c.orig 2005-07-01 17:41:08.0 +0200
+++ jk_util.c 2005-08-12 13:44:01.0 +0200
@@ -186,7 +186,7 @@
fwrite(what, 1, sz, p-logfile);
fputc('\n', p-logfile);
/* [V] Flush the dam' thing! */
-if (l-level JK_LOG_INFO_LEVEL)
+if (l-level JK_LOG_DEBUG_LEVEL)
fflush(p-logfile);
}
... awaiting comments ...
better :
if (l-level JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG ||
level==JK_LOG_ERROR)
No?
-Radek W.
-
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: bugreports for commons-daemon
Longson, Robert wrote: Hi, I'm writing to the tomcat-dev list as I understand that commons-daemon originated here. I've provided a number of bugreports, each with an associated patch to commons-daemon over the last three months (and also one for tomcat) but none of them have been applied. Yep there are 20 bugs reported... Time to think for a new release for Daemon I will look for the unix patches. Cheers Jean-Frederic Am I doing something wrong with bugzilla or is it just that there isn't a committer who understands commons daemon actively looking at the commons-dev list? If there are any tomcat developers willing to spend some time on commons-daemon I would appreciate it very much. Best regards Robert Longson The information contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.14.1 Released?
Jess Holle wrote: Was 1.2.14.1 ever officially released? I have to annonce it ;-) If not, will it be soon? -- Jess Holle - 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: mod_jk 1.2.14.1 Released?
Jess Holle wrote: Where are the zip/tar balls of the sources for those wishing to jump the gun? [I assume they're not changing at this point...] Just try http://jakarta.apache.org/site/downloads/downloads_tomcat-connectors.cgi Jean-frederic Clere wrote: Jess Holle wrote: Was 1.2.14.1 ever officially released? I have to annonce it ;-) If not, will it be soon? -- Jess Holle - 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] - 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: tomcat API doc, where?
Yoav Shapira wrote: Hi, Download eith ther .zip or .tar.gz base distro: you probably downloaded the .exe. You can also just look at the ones on the web site: go to http://jakarta.apache.org/tomcat, pick the Documentation link for your version, and scroll down near the bottom of the left-hand menu. That does not work with 5.5 (See http://jakarta.apache.org/tomcat/tomcat-5.5-doc/catalina/docs/api/index.html). Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Andreas Schenk [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 26, 2005 5:41 PM To: tomcat-dev@jakarta.apache.org Subject: tomcat API doc, where? Hi, if I try to get the API doc, I always end up with Tomcat's internal javadoc is no longer installed by default. Download and install the fulldocs package to get it. You can also access the javadoc online in the Tomcat documentation bundle. Where can I download the API doc? Can you give me a link to the fulldocs package? Thanks in advance, Andreas Schenk - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.14.1 Released?
Jess Holle wrote: Was 1.2.14.1 ever officially released? 1.2.14.1 is only a repackaging of 1.2.14. If not, will it be soon? -- Jess Holle - 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]
[ANN] Apache Tomcat mod_jk 1.2.14 Web Server Connector released
The Apache Tomcat team is pleased to announce the release of version 1.2.14 of the Apache Tomcat mod_jk web server connector. Tomcat is the reference implementation of a web application server which implements the Java Servlet and JavaServer Pages specifications. mod_jk is a connector which allows a web server such as Apache HTTPD to act as a front end to the Tomcat web application server. This version fixes a number of minor bugs. See http://jakarta.apache.org/tomcat/connectors-doc/changelog.html for a complete list of changes. Source distribtions can be downloaded from an Apache Software Foundation mirror at: (they are named jakarta-tomcat-connectors-1.2.14.1-src.tar.gz and jakarta-tomcat-connectors-1.2.14.1-src.zip) http://jakarta.apache.org/site/sourceindex.cgi Binary distributions for a number of different operating systems and web servers can be downloaded from an Apache Software Foundation mirror at: http://jakarta.apache.org/site/binindex.cgi Documentation for using mod_jk with Tomcat 3.3, 4.1, 5.0 and 5.5 can be found at: http://jakarta.apache.org/tomcat/ The Apache Tomcat team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support JSS in Tomcat
Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, July 21, 2005 3:03 AM Subject: Re: Support JSS in Tomcat Christine Ho wrote: Thanks. It works. JSS can be used under either Mozilla Public License (MPL) or LGPL. Is MPL or LGPL compatible with ASF license? The good thing about JSS is that it is FIPS-140 compliant. First, the Tomcat portion of the code needs to be donated to the ASF. The code cannot import LGPL packages, but I don't know about MPL (I'd say it's ok). MPL is listed as ok on http://wiki.apache.org/jakarta/LicenceIssues. But it says in comments: (confirm. 1.0, 1.1 different?) 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New tag ?
Remy Maucherat wrote: Yoav Shapira wrote: Hi, I'm OK with cutting 5.5.10 tomorrow or Saturday. If that's too early, let's pick a different time. I don't have further code changes to add in this build, it seems. After 5.5.10, I want to talk about SVN migration again ;) I'm aware of the lack of satisfaction among the CVS GUI users, but infra is cutting off CVS on January 1st, and for me personally, August seems like a great time to do the transition since it's traditionally a low-activity period. In my new work, I can't use cvs (only http/https it accepted by the proxy). It's not really a UI thing for me. One feature I use often are revision lists for a particular file, to be able to tell where a bug has been introduced (I then do diffs between revisions). It seems with SVN I have to retrieve the full revision list for the repository (which will take hours). If someone can offer a workaround for this problem, then I'll support a move to SVN :) How do you do this in cvs? 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: Support JSS in Tomcat
Bill Barker wrote: - Original Message - From: Jean-frederic Clere [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, July 21, 2005 11:33 AM Subject: Re: Support JSS in Tomcat Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, July 21, 2005 3:03 AM Subject: Re: Support JSS in Tomcat Christine Ho wrote: Thanks. It works. JSS can be used under either Mozilla Public License (MPL) or LGPL. Is MPL or LGPL compatible with ASF license? The good thing about JSS is that it is FIPS-140 compliant. First, the Tomcat portion of the code needs to be donated to the ASF. The code cannot import LGPL packages, but I don't know about MPL (I'd say it's ok). MPL is listed as ok on http://wiki.apache.org/jakarta/LicenceIssues. But it says in comments: (confirm. 1.0, 1.1 different?) IANAL, but the relevant parts of 1.0 1.1 look the same. Of course, it's up to the Tomcat PMC to decide the policy on importing MPLed classes :). The following worried me a little: http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200403.mbox/[EMAIL PROTECTED] 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.14 core dump oddity
William A. Rowe, Jr. wrote: At 03:04 PM 7/12/2005, William A. Rowe, Jr. wrote: It's not the return OK; my bad. Something deeper is going on here, some interaction with Apache 2, having to do with the request_rec status not being bubbled back to the origin error. But if anyone has clues to point me at, I'd appreciate it. Ok, most httpd modules presume r-status is 200, and only set it in the case of exceptions. This is why a cgi with no 'Status:' header will return the error code if it is configured as the errordocument, but if 'Status: 200' is passed with the headers, the 'error code' is lost. In mod_jk's case, we always set r-status. So we could decide to do nothing for 200 OK, or leave as is. In mod_jk r-status is set in ws_start_response(), that is called the first time ws_write is called or directly when Tomcat sends the headers. Of course you get the error page defined in Tomcat not the one defined in httpd.conf. But it seems that alot of modules make this 'mistake' and it really should be up to httpd to 'fix' the error result if it's using a given resource as an 'error page'. So I'm proposing to httpd that it gets fixed on that side. Bill - 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: [VOTE] JK 1.2.14.1
[x] Stable -- good build [ ] Alpha -- something serious is wrong: what is it? Please test and vote. Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
Tim Funk wrote: As part of the Google SOC. Google accepted the tomcat-reverse-proxy project to be executed by Anders Nyman ( anders.nyman at gmail d ot com ) The scope of the project is to let Tomcat act a reverse proxy by extending the balancer webapp. To make it easier to get the job done this summer while not relying on an intermediate committer, I propose granting commit access for only the following module: jakarta-tomcat-catalina/webapps/balancer/ The apache id granted would be prefixed with soc and be temporary. A CLA has already been signed and submitted. The vote is for commit access only for the module listed above. Voting rights will not be granted. [ ] Sounds good to me [ ] I'm indifferent [ ] I don't like it. Here's why Probably the best is to create a sourceforge project and when the code is mature enough incubate it. -Tim - 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: j-t-c/common/build - j-t-c/jk/support ?
William A. Rowe, Jr. wrote: It turns out the common/build macros are only referenced within the jk tree (which is all I check out to build modjk). I'd like to move the apache.m4, get_ver.awk and os_apache.m4 scripts to this new home, preserving history by copying the ,v files, stripping old tags from the new copies and then cvs rm'ing the originals. Votes/comments/concerns? +1 Bill - 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: ((Urgent)) Which one is better: JSP or PHP with tomcat
Abdullah Abdullah wrote: Hello everyone !!! Which one is better with tomcat : JSP or PHP ?? JSP. Using PHP with Tomcat is _very_ hard. which one is easier ?? None, the two languages are very different. If you use C libraries, using PHP could be the only solution. whch one is suitable more to be secured (authentication and ssl) with tomcat ?? You should compare httpd+mod-ssl and Tomcat+JSSE or + PureSSL, again that is hard to tell (but I prefer httpd+mod-ssl). Thanks in advance Abdullah _ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/ - 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: ((Urgent)) Which one is better: JSP or PHP with tomcat
Remy Maucherat wrote: jean-frederic clere wrote: You should compare httpd+mod-ssl and Tomcat+JSSE or + PureSSL, again that is hard to tell (but I prefer httpd+mod-ssl). How about that new Tomcat + mod_ssl-like ? ;) You have already finished the client certificates part? 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]
[VOTE] JK 1.2.14.1
Hi, JK 1.2.14 has been released. Please see the: http://jakarta.apache.org/tomcat/connectors-doc/changelog.html for a full list of changes. Sources can be found at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.14/ Binaries can be found at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/ Feel free to add any other binaries for your favorite platform :) Please vote: [ ] Stable -- good build [ ] Alpha -- something serious is wrong: what is it? Cheers, Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JK 1.2.14.1
Mladen Turk wrote: [X] Stable -- good build Thanks for volunteering for a RM! You're welcome, I should do it more often it is getting more easy ;-) 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: Releasing JK 1.2.14
Mladen Turk wrote: jean-frederic clere wrote: Done, the branch is ready. The files are in http://people.apache.org/~jfclere/jakarta-tomcat-connectors/ Hmm, it will not do. The .zip files should have .dsp files (at least) in CR-LF format. For the next release I will arrange jkrelease.sh to the CR-LF in the needed files... Think you'll need a win platform for making those. If you don't have one, I can build a .zip files. No I don't have windoze, so please build the .zip files. 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]
http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/
Hi, Just a note: the current files are a bit old, shouldn't they point via a link to the last released version? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/
Mladen Turk wrote: jean-frederic clere wrote: Hi, Just a note: the current files are a bit old, shouldn't they point via a link to the last released version? No, the current should point to the latest stable version. You can add dev that will point to the latest version. No I have added (-current-) in README.html 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: Releasing JK 1.2.14
Ari Suutari wrote: Hi, Now most of the bugs are closed, the documentation updated, JK 1.2.14 is nearly ready (changelog still needs some input). I have put the current tarballs for testing at http://people.apache.org/~jfclere/jakarta-tomcat-connectors/ I have compiled these on FreeBSD 4.10, Apache 2.0.54. On tomcat side I have 4.1 and 5.0 versions. No problems so far. Thanks, I will tag jakarta-tomcat-connectors repository today. Ari S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common portable.h
Mladen Turk wrote: [EMAIL PROTECTED] wrote: jfclere 2005/07/06 06:52:06 Modified:jk/native/common portable.h Log: just for the plaforms that don't have configure... Revision ChangesPath 1.4 +110 -0 jakarta-tomcat-connectors/jk/native/common/portable.h Why did you commit that? First because it was not up to date, I have not added it... For something weird plaforms it is nice to have it instead having to get it's content. It should be zero, because WIN and Netware will fail to build. The portable.h is generated with configure, not in the CVS. Right... That is a pitty to break Netware - I will add the file as portable.h.sample and restore the old one - 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/native/common portable.h
Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: Why did you commit that? First because it was not up to date, I have not added it... For something weird plaforms it is nice to have it instead having to get it's content. Hmm, portable.h is generated from portable.h.in on platforms that have ./configure scripts at the first place. All other platforms simply don't use it, but the file exists so that we don't need extra #ifdef's Agreed. Right... That is a pitty to break Netware - I will add the file as portable.h.sample and restore the old one - What would be the purpose of that sample? I mean, it is generated, so each platform has more or less unique one. If the configure can not generate the platform.h from platform.h.is, what's the purpose of the configure at the first place? Well... If configure fails it is more easy to hand write a platform.h from a platform.h.sample then from nothing. The other reason could be cross compiling but the Makefile are missing if configure fails. 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: Releasing JK 1.2.14
jean-frederic clere wrote: Ari Suutari wrote: Hi, Now most of the bugs are closed, the documentation updated, JK 1.2.14 is nearly ready (changelog still needs some input). I have put the current tarballs for testing at http://people.apache.org/~jfclere/jakarta-tomcat-connectors/ I have compiled these on FreeBSD 4.10, Apache 2.0.54. On tomcat side I have 4.1 and 5.0 versions. No problems so far. Thanks, I will tag jakarta-tomcat-connectors repository today. Done, the branch is ready. The files are in http://people.apache.org/~jfclere/jakarta-tomcat-connectors/ If no one complains I will move it its offical location tomorrow morning (it is 19h00 in Barcelona, time to care for the hamsters). Ari S. - 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/xdocs faq.xml
Mark Thomas wrote: [EMAIL PROTECTED] wrote: For additional help, the best resource is the Tomcat Users Discussion list. You should start by searching -a href=http://mikal.org/interests/java/tomcat/index.html; +a href=http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED] the mail list archive/a before you post questions to the list. If you are unable to locate the answer to your question in the archive, Eyebrowse has been turned off. The new URL should be: http://mail-archives.apache.org/mod_mbox/jakarta-tomcat-user/ Fixed thanks. - 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]
Releasing JK 1.2.14
Hi, Now most of the bugs are closed, the documentation updated, JK 1.2.14 is nearly ready (changelog still needs some input). I have put the current tarballs for testing at http://people.apache.org/~jfclere/jakarta-tomcat-connectors/ Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jni error
Hi, I have the following error when compiling: +++ src/file.c 502: [error]: CFE1136 struct JNINativeInterface_ has no field GetDirectBufferAddress char *bytes = (char *)(*e)-GetDirectBufferAddress(e, buf); ^ +++ My java version is 1.3.1, why are we requiring a very new one? Cheers Jean-frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
jean-frederic clere wrote: Hi, Now most of the bugs are closed, the documentation updated, JK 1.2.14 is nearly ready (changelog still needs some input). I have put the current tarballs for testing at http://people.apache.org/~jfclere/jakarta-tomcat-connectors/ Don't test yet... I have found something wrong in native/common/jk_md5.h Cheers Jean-Frederic - 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/tools jkrelease.sh
Mladen Turk wrote: [EMAIL PROTECTED] wrote: +# Check for links or w3m +W3MOPTS=-dump -cols 80 -t 4 -S -O iso-8859-1 -T text/html +LNKOPTS=-dump Great, but I think that the links/elinks options should be: --dump --no-references --no-numbering --no-home That's at least for the elinks, but I suppose the links should have something similar. no: links only wants -dump, but I have not problems to add elinks. Just using dump will make the output pretty unfriendly ;) In fact, the reason why I choose w3m was because it can give a very clean .txt output. 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/tools jkrelease.sh
Mladen Turk wrote: jean-Frederic clear wrote: Mladen Turk wrote: [EMAIL PROTECTED] wrote: no: links only wants -dump, but I have not problems to add elinks. Also, how about you volunteer for a 1.2.14 RM? Well there are still 20 bugs in tomcat5/mod-jk, what do with them? I was doing that for the last year and I'm getting pretty tired ;) I will build as many binaries as I can. 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/tools jkrelease.sh
Mladen Turk wrote: Henri Gomez wrote: Because JFC is a great guy and someone I meet often. He he. And yes he will be a great RM :) Go JFC, go Right. I think he can take some responsibility, if he mess up, we'll kidnap his hamsters :) You have to catch them first :) (Well for 2 of them just put the hand in the cage and make some noise). Cheers, 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/tools jkrelease.sh
Mladen Turk wrote: jean-frederic clere wrote: Well there are still 20 bugs in tomcat5/mod-jk, what do with them? Not sure. Lot's of obsolete things that need a simple cleanup. Ok I will start to clean bugzilla. I can only tell the current CVS is the best ever mod_jk we had. If it builds on all platforms (ant it does AFAICT), we should go for the release ASAP. I will test it on BS2000, if it builds and runs there it is ready for a release! There are just too many things that has been fixed since last stable, that we should ignore or try to wait much further. 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]
jk/native/CHANGES.txt and jk/xdocs/changelog.xml
Hi, Should't we remove CHANGES.txt or add in it please write the changes in ../xdocs/changelog.xml? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
Mladen Turk wrote: Henri Gomez wrote: could you provide a beta source tarball to make the usual iSeries builds ? Well, you have the j-t-c/tools/jkrelease.sh But I've put the current head at: http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz It gives: +++ /home/jfclere/usr/local/apr/build-1/libtool --silent --mode=compile gcc -I/home/jfclere/usr/local/apache2/include -g -O2 -DUSE_APACHE_MD5 -I ../common -I /home2/java/j2sdk1.4.2_03/include -I /home2/java/j2sdk1.4.2_03/include/unix -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -g -O2 -pthread -DHAVE_APR -I/home/jfclere/usr/local/apr/include/apr-1 -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -c mod_jk.c In file included from mod_jk.c:28: /home/jfclere/usr/local/apache2/include/ap_config.h:21:23: apr_hooks.h: No such file or directory /home/jfclere/usr/local/apache2/include/ap_config.h:22:32: apr_optional_hooks.h: +++ apr and apr-util are installed in /home/jfclere/usr/local/apr /home/jfclere/usr/local/apr-util. apr_hooks.h is in /home/jfclere/usr/local/apr-util/include/apr-1/apr_hooks.h, probably something more is needed in configure. 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: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: jean-frederic clere wrote: Chad La Joie wrote: Yeah, I know what mod-ssl says, and for most cases it's probably right, however the optional_no_ca option is interesting to us because it provides exactly the functionality that we need; accepting the client cert, putting it in a standard place, and allowing our application to do the verification for us. As you said, PKCS12 wouldn't help us. The problem isn't that the Java keystore is some how flawed. It's that that's just not a viable mechanism for us. Our certificates are communicated in SAML2 metadata files. These files change periodically (when new service or identity providers come online or old ones go offline). We had discussed a process whereby we'd extract the certs from the file and create a keystore but that has and unacceptable drawback, in our opinion. With the SAML2 metadata files we can get fresh copies of those files and use them immediately in a running system. With the keystore mechanism Tomcat would need to be restarted because the keystore, or at least part of it, is cached in memory and as far as I can tell, the cache is never refreshed. Given the indeterminate frequency for metadata updates, we do not see this as a viable solution for a production level system. I am not sure I got it right... If you have clients that use client certificates you only need to get them signed by a CA that is known by Tomcat or do you want to change the server certificate Tomcat is using? That's the problem, Tomcat might not know the CA that signed the cert. All certificate information, including CA(s), are expressed in the SAML2 metadata file. It could be that the CA that signed the client cert was something like Verisign, but it's much more likely to be the case that it's some organization's CA, which Tomcat wouldn't know about. OK I have added a new CA using: +++ [EMAIL PROTECTED]:~ $JAVA_HOME/bin/keytool -import -trustcacerts -file ~/CERTS/demoCA/cacert.pem -keystore $JAVA_HOME/jre/lib/security/cacerts +++ To get Tomcat accepting client certificates from this CA I had to restart it... Bad. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
Mladen Turk wrote: jean-frederic clere wrote: apr_hooks.h is in /home/jfclere/usr/local/apr-util/include/apr-1/apr_hooks.h, probably something more is needed in configure. Try to run the: apxs2 -q APU_INCLUDEDIR it tells: +++ [EMAIL PROTECTED]:~ usr/local/apache2/bin/apxs -q APU_INCLUDEDIR /home/jfclere/usr/local/apr-util/include/apr-1 +++ Seems that: apxs2 -q INCLUDEDIR +++ [EMAIL PROTECTED]:~ usr/local/apache2/bin/apxs -q INCLUDEDIR /home/jfclere/usr/local/apache2/include +++ is giving the /home/jfclere/usr/local/apache2/include and 'apxs2 -q APR_INCLUDEDIR' is giving the /home/jfclere/usr/local/apr/include/apr-1 +++ [EMAIL PROTECTED]:~ usr/local/apache2/bin/apxs -q APR_INCLUDEDIR /home/jfclere/usr/local/apr/include/apr-1 +++ The solution is to eiter copy APU_INCLUDEDIR to the INCLUDEDIR, Should I fix it? or figure out why APU_INCLUDEDIR gives nothing or points to the wrong location. 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: Releasing JK 1.2.14
Mladen Turk wrote: jean-frederic clere wrote: Try to run the: apxs2 -q APU_INCLUDEDIR it tells: +++ [EMAIL PROTECTED]:~ usr/local/apache2/bin/apxs -q APU_INCLUDEDIR /home/jfclere/usr/local/apr-util/include/apr-1 +++ That's bad. It should point to your apr-utils/include. NO: +++ ls -lt /home/jfclere/usr/local/apr-util/include/ total 4 drwxr-xr-x2 jfclere users4096 2005-06-29 10:43 apr-1 +++ It's probably the apxs broken, and I doubt you'll be able to compile *any* module, not just jk. The solution is to eiter copy APU_INCLUDEDIR to the INCLUDEDIR, Should I fix it? Well, the majority of apache distributions either have all httpd, apr and apr-utils includes in a single directory. The only difference is RHEL that has that separated, but even there both apr and apr-utils includes are in the single directory. Anyhow, it has nothing to do with the mod_jk. He correctly queries and populates those include dirs if the apxs reports them correctly. 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: Releasing JK 1.2.14
Mladen Turk wrote:
jean-frederic clere wrote:
it tells:
+++
[EMAIL PROTECTED]:~ usr/local/apache2/bin/apxs -q APU_INCLUDEDIR
/home/jfclere/usr/local/apr-util/include/apr-1
+++
That's bad.
It should point to your apr-utils/include.
NO:
+++
ls -lt /home/jfclere/usr/local/apr-util/include/
total 4
drwxr-xr-x2 jfclere users4096 2005-06-29 10:43 apr-1
+++
Sorry, it was typo.
apxs -q APU_INCLUDEDIR
/home/jfclere/usr/local/apr-util/include/apr-1
your apr-util is at:
/home/jfclere/usr/local/apr-util/include
and that's where the includes should be thought.
OTOH it might be the error in the configure.in:
INCTEMP=`$APXS -q APR_INCLUDEDIR` `$APXS -q APU_INCLUDEDIR`
for INC in ${INCTEMP}; do
APRINCLUDEDIR=${APRINCLUDEDIR} -I${INC}
done
Try to change the:
INCTEMP=`$APXS -q APR_INCLUDEDIR` `$APXS -q APU_INCLUDEDIR`
to:
INCTEMP=`$APXS -q APU_INCLUDEDIR` `$APXS -q APR_INCLUDEDIR`
Seems strange that the
-I/home/jfclere/usr/local/apr-util/include/apr-1 is not listed on the
original dump you've posted.
I have just retried from cvs it is ok.
From:
http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz
it does not work. (the configure is wrong).
Cheers
Jean-Frederic
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: Releasing JK 1.2.14
William A. Rowe, Jr. wrote: JFC, there's no way you would build against apr-1 for an httpd-2.0 server (and, you must build against apr-1 for an httpd-2.1/2.2 server.) You forgot to mention how you configured. right I am building a httpd-2.1/2.2 The very first release of APR 1.0.0 was borked, it deployed apr-config and apu-config, wiping out the 0.9 flavors. Today it should be deploying apr-1-config (or apr-config-1, can't recall offhand.) apr-1-config Bill At 04:58 AM 6/29/2005, jean-frederic clere wrote: Mladen Turk wrote: Henri Gomez wrote: could you provide a beta source tarball to make the usual iSeries builds ? Well, you have the j-t-c/tools/jkrelease.sh But I've put the current head at: http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz It gives: +++ /home/jfclere/usr/local/apr/build-1/libtool --silent --mode=compile gcc -I/home/jfclere/usr/local/apache2/include -g -O2 -DUSE_APACHE_MD5 -I ../common -I /home2/java/j2sdk1.4.2_03/include -I /home2/java/j2sdk1.4.2_03/include/unix -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -g -O2 -pthread -DHAVE_APR -I/home/jfclere/usr/local/apr/include/apr-1 -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -c mod_jk.c In file included from mod_jk.c:28: /home/jfclere/usr/local/apache2/include/ap_config.h:21:23: apr_hooks.h: No such file or directory /home/jfclere/usr/local/apache2/include/ap_config.h:22:32: apr_optional_hooks.h: +++ apr and apr-util are installed in /home/jfclere/usr/local/apr /home/jfclere/usr/local/apr-util. apr_hooks.h is in /home/jfclere/usr/local/apr-util/include/apr-1/apr_hooks.h, probably something more is needed in configure. 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] - 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/tools jkrelease.sh
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfclere 2005/06/29 09:20:15 Modified:jk/tools jkrelease.sh Log: Allow to use http_proxy if available. This is unfait: I am without email (I switched to using a forward as an emergency measure), CVS access, etc. How did you do a commit ? I am using the lastest version of ssh and have forced protocol 2. 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: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. Have you tried to use keystoreType=PKCS12 in the connector? Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use SSLVerifyClient optional_no_ca HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. BTW: mod-ssl says: +++ In practice only levels none and require are really interesting, because level optional doesn't work with all browsers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.) +++ And keystoreType= PKCS12 doesn't help. Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use SSLVerifyClient optional_no_ca HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: Yeah, I know what mod-ssl says, and for most cases it's probably right, however the optional_no_ca option is interesting to us because it provides exactly the functionality that we need; accepting the client cert, putting it in a standard place, and allowing our application to do the verification for us. As you said, PKCS12 wouldn't help us. The problem isn't that the Java keystore is some how flawed. It's that that's just not a viable mechanism for us. Our certificates are communicated in SAML2 metadata files. These files change periodically (when new service or identity providers come online or old ones go offline). We had discussed a process whereby we'd extract the certs from the file and create a keystore but that has and unacceptable drawback, in our opinion. With the SAML2 metadata files we can get fresh copies of those files and use them immediately in a running system. With the keystore mechanism Tomcat would need to be restarted because the keystore, or at least part of it, is cached in memory and as far as I can tell, the cache is never refreshed. Given the indeterminate frequency for metadata updates, we do not see this as a viable solution for a production level system. I am not sure I got it right... If you have clients that use client certificates you only need to get them signed by a CA that is known by Tomcat or do you want to change the server certificate Tomcat is using? jean-frederic clere wrote: Chad La Joie wrote: Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. BTW: mod-ssl says: +++ In practice only levels none and require are really interesting, because level optional doesn't work with all browsers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.) +++ And keystoreType= PKCS12 doesn't help. Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use SSLVerifyClient optional_no_ca HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? - 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/jni/native configure.in
Mladen Turk wrote:
William A. Rowe, Jr. wrote:
At 02:01 AM 6/23/2005, Mladen Turk wrote:
-CFLAGS=${CFLAGS} -DDEBUG -Wall
+CFLAGS=${CFLAGS} -DDEBUG
I would prefer that you add some platform case/esac that will
in ReliantUnix case add what ever you wish to the CFLAGS.
Conversely, a compiler case/esac would avoid altogether breaking
AIX, HP/UX, Reliant and a dozen other oddballs. Forcing users to
play cflags is really a symptom of a weak build system.
Something simple like:
if test $GCC = yes; then
CFLAGS=${CFLAGS} -DDEBUG -Wall
elif test $AIX_XLC = yes; then
CFLAGS=${CFLAGS} -DDEBUG -qfullpath -qinitauto=FE -qcheck=all
elif test $MYCOMPILER = yes; then
CFLAGS=${CFLAGS} -DDEBUG my what ever flags
else
CFLAGS=${CFLAGS} -DDEBUG
fi
Would do the trick ;)
Yep, even:
+++
if test $GCC = yes; then
CFLAGS=${CFLAGS} -DDEBUG -Wall
else
CFLAGS=${CFLAGS} -DDEBUG
fi
+++
gets my +1.
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]
core in jni
Hi, I have core in jakarta-tomcat-connectors: +++ #9 0x in ?? () #10 0xab7731c6 in Java_org_apache_tomcat_jni_Socket_timeoutSet (e=0x80fcb60, o=0xbe9ff838, sock=58090580307188, timeout=135264680) at src/network.c:893 +++ Any hints why tmset is NULL? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: core in jni
jean-frederic clere wrote: Hi, I have core in jakarta-tomcat-connectors: +++ #9 0x in ?? () #10 0xab7731c6 in Java_org_apache_tomcat_jni_Socket_timeoutSet (e=0x80fcb60, o=0xbe9ff838, sock=58090580307188, timeout=135264680) at src/network.c:893 +++ Any hints why tmset is NULL? Now it is ok, thanks Mladen ;-) Cheers Jean-Frederic - 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/jni/native configure.in
[EMAIL PROTECTED] wrote:
mturk 2005/06/18 06:04:42
Modified:jni/native configure.in
Log:
Add --enable-maintainer-mode to the configure options, so that
statistics gets compiled in when configure is called with that option.
Revision ChangesPath
1.6 +20 -5 jakarta-tomcat-connectors/jni/native/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/configure.in,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- configure.in 12 Jun 2005 06:10:13 - 1.5
+++ configure.in 18 Jun 2005 13:04:42 - 1.6
@@ -12,7 +12,7 @@
sinclude(build/find_apr.m4)
dnl Generate ./config.nice for reproducing runs of configure
-dnl
+dnl
APR_CONFIG_NICE(config.nice)
dnl # Some initial steps for configuration. We setup the default directory
@@ -94,11 +94,11 @@
AC_SUBST(JAVA_OS)
APR_ADDTO(TCNATIVE_PRIV_INCLUDES,[-I$JAVA_HOME/include])
-APR_ADDTO(TCNATIVE_PRIV_INCLUDES,[-I$JAVA_HOME/include/$JAVA_OS])
+APR_ADDTO(TCNATIVE_PRIV_INCLUDES,[-I$JAVA_HOME/include/$JAVA_OS])
dnl
dnl Detect openssl toolkit installation
-dnl
+dnl
TCN_CHECK_SSL_TOOLKIT
so_ext=$APR_SO_EXT
@@ -113,7 +113,7 @@
host_alias=`uname -s`
case $host_alias in
dnl ### BeOS requires that ALL symbols resolve at LINK time!
-dnl ###
+dnl ###
dnl ### So, if we're building on BeOS then we need to add in the
dnl ### apr and expat libraries to the build or it'll die a truly
horrible
dnl ### death. We now use the apr-config tool to determine the correct
@@ -128,6 +128,21 @@
AC_SUBST(EXTRA_OS_LINK)
+dnl CFLAGS for maintainer mode
+dnl it also allows the CFLAGS environment variable.
+CFLAGS=${CFLAGS}
+AC_ARG_ENABLE(
+maintainer-mode,
+[ --enable-maintainer-mode Turn on debugging and compile time warnings],
+[
+case ${enableval} in
+y | Y | YES | yes | TRUE | true )
+CFLAGS=${CFLAGS} -DDEBUG -Wall
-Wall will not wrong on every machine, for example on ReliantUnix:
+++
$ cc -Wall toto.c -o toto
cc: [warning]: CDR9977 invalid option '-Wall' ignored
+++
+AC_MSG_RESULT([...Enabling Maintainer mode...])
+;;
+esac
+])
+
dnl
dnl Prep all the flags and stuff for compilation and export to other builds
dnl
@@ -178,7 +193,7 @@
fi
dnl
-dnl everthing is done.
+dnl everthing is done.
MAKEFILES=Makefile
AC_OUTPUT([
tcnative.pc
-
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/jni/native configure.in
Remy Maucherat wrote: jean-frederic clere wrote: -Wall will not wrong on every machine, for example on ReliantUnix: +++ $ cc -Wall toto.c -o toto cc: [warning]: CDR9977 invalid option '-Wall' ignored +++ Mladen is away for two days, so you won't get a reply right away. Ok, I will fix it. Cheers Jean-Frederic 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: Sun One/iPlanet nsapi_redirector issue
Kevin Convy (Contractor) wrote:
I am having an issue posting a large request (that also requires
authentication) through a Sun One/IPlanet 6.0sp5 webserver to Tomcat 5.5
using the 1.2.8 nsapi_redirector. The client that is doing the posting
gets a server write error if the request body is over a certain size
(~150K). The issue occurs on both the Windows XP and Solaris
versions.The issue does NOT occur using an Apache-mod_jk configuration.
If I use the attached version of the ajp_process_callback method in
jk_ajp_common.c (changes from the 1.2.8 version of the code are marked
with KCADD comments) it resolves the problem.
A diff -u would help to see your changes.
It seems to resolve it by
making sure the entire request body is read off the netbuf before
turning around and starting the response (which occurs in this case
because an authentication challenge is sent before the entire request is
read by tomcat). I don't mean to offer this as a fix, but I was
wondering if this is a known issue and if there is a better fix
somewhere.
I sent a slightly different version of this email to the tomcat-user
list a couple of weeks ago and apologize for the cross-post.
Thanks,
Kevin Convy
Icebox LLC
static int ajp_process_callback(jk_msg_buf_t *msg,
jk_msg_buf_t *pmsg,
ajp_endpoint_t * ae,
jk_ws_service_t *r, jk_logger_t *l)
{
int code = (int)jk_b_get_byte(msg);
// KCADD
int bytesread = 0;
unsigned char buf1[AJP13_MAX_SEND_BODY_SZ];
JK_TRACE_ENTER(l);
switch (code) {
case JK_AJP13_SEND_HEADERS:
{
jk_res_data_t res;
if (!ajp_unmarshal_response(msg, res, ae, l)) {
jk_log(l, JK_LOG_ERROR,
ajp_unmarshal_response failed\n);
JK_TRACE_EXIT(l);
return JK_AJP13_ERROR;
}
//KCADD
// make sure the entire request body has been read.
jk_log(l, JK_LOG_INFO, KCDEBUG: this many bytes left: %d,
ae-left_bytes_to_send);
while(ae-left_bytes_to_send 0) {
r-read(r, buf1, AJP13_MAX_SEND_BODY_SZ, bytesread);
ae-left_bytes_to_send -= bytesread;
}
r-start_response(r, res.status, res.msg,
(const char *const *)res.header_names,
(const char *const *)res.header_values,
res.num_headers);
}
return JK_AJP13_SEND_HEADERS;
case JK_AJP13_SEND_BODY_CHUNK:
{
unsigned len = (unsigned)jk_b_get_int(msg);
if (!r-write(r, jk_b_get_buff(msg) + jk_b_get_pos(msg),
len)) {
jk_log(l, JK_LOG_INFO,
Connection aborted or network problems\n);
JK_TRACE_EXIT(l);
return JK_CLIENT_ERROR;
}
}
break;
case JK_AJP13_GET_BODY_CHUNK:
{
int len = (int)jk_b_get_int(msg);
if (len 0) {
len = 0;
}
if (len AJP13_MAX_SEND_BODY_SZ) {
len = AJP13_MAX_SEND_BODY_SZ;
}
if ((unsigned int)len ae-left_bytes_to_send) {
len = ae-left_bytes_to_send;
}
/* the right place to add file storage for upload */
if ((len = ajp_read_into_msg_buff(ae, r, pmsg, len, l)) =
0) {
r-content_read += len;
JK_TRACE_EXIT(l);
return JK_AJP13_HAS_RESPONSE;
}
jk_log(l, JK_LOG_INFO,
Connection aborted or network problems\n);
JK_TRACE_EXIT(l);
return JK_CLIENT_ERROR;
}
break;
case JK_AJP13_END_RESPONSE:
{
ae-reuse = (int)jk_b_get_byte(msg);
if (!ae-reuse) {
/*
* Strange protocol error.
*/
if (JK_IS_DEBUG_LEVEL(l))
jk_log(l, JK_LOG_DEBUG, Reuse: %d\n, ae-reuse);
ae-reuse = JK_FALSE;
}
/* Reuse in all cases */
ae-reuse = JK_TRUE;
}
JK_TRACE_EXIT(l);
return JK_AJP13_END_RESPONSE;
break;
default:
jk_log(l, JK_LOG_ERROR,
Invalid code: %d\n, code);
JK_TRACE_EXIT(l);
return JK_AJP13_ERROR;
}
JK_TRACE_EXIT(l);
return JK_AJP13_NO_RESPONSE;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
Bill Barker wrote: To whom it may engage... I think I have fixed this one in rules.mk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_shm.h jk_status.c
William A. Rowe, Jr. wrote: Mladen; are you sure you weren't looking for 'long long', al la int64_t? Falling over to the FPU is rarely the best performance decision. A little more coding is needed, because I have a related error (on ReliantUnix): +++ /home/apache20/apache20/build/libtool --silent --mode=compile cc -I/home/apache20/apache20/include -g -DUSE_APACHE_MD5 -I ../common -I /include -I /include/unix -DSVR4 -g -DHAVE_APR -I/home/apache20/apache20/include -I/home/apache20/apache20/include -g -g -DSVR4 -c ../common/jk_ajp14.c ../common/jk_md5.h65: [error]: CFE1020 identifier uint32_t is undefined typedef uint32_t JK_UINT4; ^ +++ I am going to add in configure some code to check for long long and sizeof(short/int/long). Bill At 02:55 AM 6/13/2005, [EMAIL PROTECTED] wrote: mturk 2005/06/13 00:55:51 Modified:jk/native/common jk_lb_worker.c jk_shm.h jk_status.c Log: Use double instead size_t for trensferred/read, so that lb doesn't break on trnasferred mode when 2G of data has been send/read. -size_t mytraffic = 0; -size_t curmin = 0; +double mytraffic = 0; +double curmin = 0; - 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/native/common jk_lb_worker.c jk_shm.h jk_status.c
Mladen Turk wrote: jean-frederic clere wrote: William A. Rowe, Jr. wrote: Mladen; are you sure you weren't looking for 'long long', al la int64_t? Falling over to the FPU is rarely the best performance decision. A little more coding is needed, because I have a related error (on ReliantUnix): undefined typedef uint32_t JK_UINT4; ^ Seems that the uint32_t is not inside includes referenced by jk_global.h. Not sure what is the possible location for that type on all platforms. Perhaps u_int32_t would be more portable. I would prefer to add in configure something like: +++ AC_CHECK_SIZEOF(char, 1) AC_CHECK_SIZEOF(int, 4) AC_CHECK_SIZEOF(long, 4) AC_CHECK_SIZEOF(short, 2) AC_CHECK_SIZEOF(long long, 8) +++ and testing $ac_cv_sizeof_WHATWETESTED makes sure we right one. 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/native/common jk_lb_worker.c jk_shm.h jk_status.c
Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: Perhaps u_int32_t would be more portable. I would prefer to add in configure something like: +++ AC_CHECK_SIZEOF(char, 1) AC_CHECK_SIZEOF(int, 4) AC_CHECK_SIZEOF(long, 4) AC_CHECK_SIZEOF(short, 2) AC_CHECK_SIZEOF(long long, 8) +++ and testing $ac_cv_sizeof_WHATWETESTED makes sure we right one. Yes, but all that we need is 32 bit unsigned integer for JK_UINT4 What will you use if the int is 64 bits? a long ;-) 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/native/common jk_lb_worker.c jk_shm.h jk_status.c
Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: Yes, but all that we need is 32 bit unsigned integer for JK_UINT4 What will you use if the int is 64 bits? a long ;-) Right :) You will need the portable.in in that case, right? Yes and I will ask Henri to check AS400 see jk_global.h: +++ #if !defined(WIN32) !defined(AS400) #include portable.h #else +++ - 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/native/common jk_lb_worker.c jk_shm.h jk_status.c
Henri Gomez wrote: What do you need on iSeries ? Just to know what to use to have: JK_UINT4 (unsigned long of 32 bits) and JK_UINT8 (unsigned long long of 64 bits) and to check status_strfsize(). 2005/6/14, jean-frederic clere [EMAIL PROTECTED]: Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: Yes, but all that we need is 32 bit unsigned integer for JK_UINT4 What will you use if the int is 64 bits? a long ;-) Right :) You will need the portable.in in that case, right? Yes and I will ask Henri to check AS400 see jk_global.h: +++ #if !defined(WIN32) !defined(AS400) #include portable.h #else +++ - 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] - 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/native/common jk_lb_worker.c jk_shm.h jk_status.c
Henri Gomez wrote: status_strfsize ? APR ? Nearly: jakarta-tomcat-connectors/jk/native/common/jk_status.c ;-) 2005/6/14, jean-frederic clere [EMAIL PROTECTED]: Henri Gomez wrote: What do you need on iSeries ? Just to know what to use to have: JK_UINT4 (unsigned long of 32 bits) and JK_UINT8 (unsigned long long of 64 bits) and to check status_strfsize(). 2005/6/14, jean-frederic clere [EMAIL PROTECTED]: Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: Yes, but all that we need is 32 bit unsigned integer for JK_UINT4 What will you use if the int is 64 bits? a long ;-) Right :) You will need the portable.in in that case, right? Yes and I will ask Henri to check AS400 see jk_global.h: +++ #if !defined(WIN32) !defined(AS400) #include portable.h #else +++ - 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] - 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] - 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/native/common jk_lb_worker.c jk_shm.h jk_status.c
Henri Gomez wrote: ok, but couldn't build now from CVS, but it should works after jk_u64_t is defined as unsigned long long. Since we couldn't use portable.h on iSeries, it should be elsewhere ... Sure... I will add the need #if defined(AS400). 2005/6/14, jean-frederic clere [EMAIL PROTECTED]: Henri Gomez wrote: status_strfsize ? APR ? Nearly: jakarta-tomcat-connectors/jk/native/common/jk_status.c ;-) 2005/6/14, jean-frederic clere [EMAIL PROTECTED]: Henri Gomez wrote: What do you need on iSeries ? Just to know what to use to have: JK_UINT4 (unsigned long of 32 bits) and JK_UINT8 (unsigned long long of 64 bits) and to check status_strfsize(). 2005/6/14, jean-frederic clere [EMAIL PROTECTED]: Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: Yes, but all that we need is 32 bit unsigned integer for JK_UINT4 What will you use if the int is 64 bits? a long ;-) Right :) You will need the portable.in in that case, right? Yes and I will ask Henri to check AS400 see jk_global.h: +++ #if !defined(WIN32) !defined(AS400) #include portable.h #else +++ - 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] - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
[EMAIL PROTECTED] wrote: jfclere 2005/06/08 09:52:58 Modified:jni/examples/org/apache/tomcat/jni SSLServer.java jni/java/org/apache/tomcat/jni BIOCallback.java SSL.java SSLContext.java jni/native/src ssl.c sslcontext.c Log: Change the BIOCallback interface to use write(byte[] buf) and read(byte[] buf); Add SSL_accept to do the client handshake. Arrange the corresponding example. +++ CUT +++ Hi, I am not 100% happy with the code. Mladen already asked me to rollback the changes. I think the worst thing is setSock() I have added to BIOCallback. My idea is/was to use BIOCallback or a similar interface to be able to openssl either with normal JAVA sockets or APR native ones. Comments? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
Mladen Turk wrote: Bill Barker wrote: I am not 100% happy with the code. Mladen already asked me to rollback the changes. It looked OK to me. Basically it's the APR implementation of SSLEngine. Don't really see a problem. It does not, because it should fit inside the APR standard socket implementation. Having callbacks would actually make a thing way slower, because we would have to call the native, and from the native call the Java that would call back the native again. Well we just need a nativeBIO and a javaBIO. Of course, I don't really care about the APR-SSL Connector one way or the other. Since the config is the same as for mod_ssl, there is absolutely no reason to not simply use mod_ssl instead. If I just wanted the native-code optimizations, I'd use PureTLS instead. It's not an APR-SSL connector, but rather the SSL support for the APR connector. Since all that is optional feel free to just not use it :) 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/jni/native/src ssl.c sslcontext.c
Mladen Turk wrote: jean-frederic clere wrote: It does not, because it should fit inside the APR standard socket implementation. Having callbacks would actually make a thing way slower, because we would have to call the native, and from the native call the Java that would call back the native again. Well we just need a nativeBIO and a javaBIO. The plan is to use the: 1. apr_sock_accept/connect 2. obtain a os_sock 3. Make a BIO with os_sock_t 4. Use APR for socket_opt_set/socket_opt_get 5. Do a SSL_accept/SSL_connect 6. Make verify/handshake 7. use SSL_write/SSL_read for I/O. All that will use the poller and the pool cleanup. The Java part will go to the SSLSocket with the Socket API with specific read* and write* OK, I will create a SSLBIO.java/sslbio.c to go on testing/experimenting using with the BIOCallback, the interest there is to use an hardware accelator with openssl. 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: [EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
Bill Barker wrote: To whom it may engage... Funny... I don't get it. Which Apache are you using for the test? This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-native has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-native : Connectors to various web servers Full details are available at: http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build) Work ended in a state of : Failed Elapsed: 31 secs Command Line: make [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native] - mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2670: error: dereferencing pointer to incomplete type mod_jk.c:2680: error: dereferencing pointer to incomplete type mod_jk.c:2684: error: dereferencing pointer to incomplete type mod_jk.c:2689: error: dereferencing pointer to incomplete type mod_jk.c:2689: error: dereferencing pointer to incomplete type mod_jk.c:2693: error: dereferencing pointer to incomplete type mod_jk.c:2693: error: dereferencing pointer to incomplete type mod_jk.c:2694: error: dereferencing pointer to incomplete type mod_jk.c:2697: error: dereferencing pointer to incomplete type mod_jk.c:2698: error: dereferencing pointer to incomplete type mod_jk.c:2704: error: dereferencing pointer to incomplete type mod_jk.c:2707: error: dereferencing pointer to incomplete type mod_jk.c:2707: error: dereferencing pointer to incomplete type mod_jk.c:2710: error: dereferencing pointer to incomplete type mod_jk.c:2710: error: dereferencing pointer to incomplete type mod_jk.c:2711: error: dereferencing pointer to incomplete type mod_jk.c:2712: error: dereferencing pointer to incomplete type mod_jk.c:2720: error: dereferencing pointer to incomplete type mod_jk.c:2721: error: dereferencing pointer to incomplete type mod_jk.c:2721: error: dereferencing pointer to incomplete type mod_jk.c:2723: error: dereferencing pointer to incomplete type mod_jk.c:2729: error: dereferencing pointer to incomplete type mod_jk.c:2729: error: dereferencing pointer to incomplete type mod_jk.c:2729: error: dereferencing pointer to incomplete type mod_jk.c: In function `jk_register_hooks': mod_jk.c:2740: error: `APR_HOOK_MIDDLE' undeclared (first use in this function) mod_jk.c:2740: error: (Each undeclared identifier is reported only once mod_jk.c:2740: error: for each function it appears in.) make[1]: *** [mod_jk.lo] Error 1 make[1]: Leaving directory `/x1/gump/public/workspace/jakarta-tomcat-connectors/jk/native/apache-2.0' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 17001831052005,
Re: [EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
jean-frederic clere wrote: Bill Barker wrote: To whom it may engage... Funny... I don't get it. Which Apache are you using for the test? The answer is 2.0 (and it works with today sources for me): +++ CUT +++ `/x1/gump/public/workspace/jakarta-tomcat-connectors/jk/native/apache-2.0' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 17001831052005, vmgump.apache.org:vmgump-public:17001831052005 Gump E-mail Identifier (unique within run) #4. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java
Mladen Turk wrote: [EMAIL PROTECTED] wrote: billbarker2005/05/20 20:02:25 Modified:catalina/src/share/org/apache/catalina/connector Connector.java Response.java Log: Reverting previous patch in favor of the better one submitted by JFC No idea why but suddenly I'm getting the following when stopping the Tomcat with simple CTRL+C and AJP connector enabled. INFO: Pausing Coyote HTTP/1.1 on http-8080 May 25, 2005 4:46:53 PM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.NoSuchMethodError: org.apache.jk.core.MsgContext.getRequest()Ljava/lang/Object;) executing [EMAIL PROTECTED], terminating thread May 25, 2005 4:46:54 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina Any ideas why? Why do you think the changes in Connector and Response cause the problem? 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]
filter to support EBCDIC encoding
Hi, I have written a filter to solve the encoding problems in EBCDIC machines. Where should the filter code goes? - jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters or somewhere else? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
Mladen Turk wrote:
Hi,
Just noticed a strange behavior in the Java part of the
JK dealing with large (over 8184 bytes) data transfers.
Since with 8192 bytes AJP packet size, the maximum
transferred size per each packet is 8184 bytes one
would expect that for 2 bytes file the packets
would be in a form of:
1:8184,2:8184,3:3632 thus total of 2 bytes.
But in fact the behavior is rely weird:
1:8184,2:8,3:8184,4:8,5:3616.
Instead only three, the five! packets are transferred.
Seems that algorithm is breaking 8192 bytes of data to
two packets (8184 and 8 bytes).
I have an ugly patch for that. Find it attached (that just for gettting
comments).
Cheers
Jean-Frederic
Bill,
Any idea how to solve this, because it's way too
inefficient.
What's makes the things even worse is that for each
packet Apache2 creates a transient bucket thus
rising the memory usage.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: Response.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Response.java,v
retrieving revision 1.12
diff -u -r1.12 Response.java
--- Response.java 25 Apr 2005 22:06:30 - 1.12
+++ Response.java 20 May 2005 15:56:25 -
@@ -68,6 +68,16 @@
public Response() {
+outputBuffer = new OutputBuffer();
+outputStream = new CoyoteOutputStream(outputBuffer);
+writer = new CoyoteWriter(outputBuffer);
+urlEncoder.addSafeCharacter('/');
+}
+
+public Response(int size) {
+outputBuffer = new OutputBuffer(size);
+outputStream = new CoyoteOutputStream(outputBuffer);
+writer = new CoyoteWriter(outputBuffer);
urlEncoder.addSafeCharacter('/');
}
@@ -174,20 +184,19 @@
/**
* The associated output buffer.
*/
-protected OutputBuffer outputBuffer = new OutputBuffer();
+protected OutputBuffer outputBuffer;
/**
* The associated output stream.
*/
-protected CoyoteOutputStream outputStream =
-new CoyoteOutputStream(outputBuffer);
+protected CoyoteOutputStream outputStream;
/**
* The associated writer.
*/
-protected CoyoteWriter writer = new CoyoteWriter(outputBuffer);
+protected CoyoteWriter writer;
/**
Index: Connector.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java,v
retrieving revision 1.18
diff -u -r1.18 Connector.java
--- Connector.java 30 Apr 2005 03:32:43 - 1.18
+++ Connector.java 20 May 2005 15:56:42 -
@@ -897,7 +897,12 @@
*/
public Response createResponse() {
-Response response = new Response();
+System.out.println(Connector: createResponse: getProtocol: +
getProtocol());
+Response response = null;
+if (AJP/1.3.equals(getProtocol()))
+response = new Response(8184);
+else
+response = new Response();
response.setConnector(this);
return (response);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
Mladen Turk wrote: Hi, Just noticed a strange behavior in the Java part of the JK dealing with large (over 8184 bytes) data transfers. Since with 8192 bytes AJP packet size, the maximum transferred size per each packet is 8184 bytes one would expect that for 2 bytes file the packets would be in a form of: 1:8184,2:8184,3:3632 thus total of 2 bytes. But in fact the behavior is rely weird: 1:8184,2:8,3:8184,4:8,5:3616. Instead only three, the five! packets are transferred. Look to Ajp13.java: public static final int MAX_SEND_SIZE = MAX_PACKET_SIZE - H_SIZE - 4; 8184. The CoyoteWriter gets called with blocks of 8192 bytes max... 8184+8... Seems that algorithm is breaking 8192 bytes of data to two packets (8184 and 8 bytes). Bill, Any idea how to solve this, because it's way too inefficient. What's makes the things even worse is that for each packet Apache2 creates a transient bucket thus rising the memory usage. 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: AJP/Java connector issues
Mladen Turk wrote: Hi, Just noticed a strange behavior in the Java part of the JK dealing with large (over 8184 bytes) data transfers. Since with 8192 bytes AJP packet size, the maximum transferred size per each packet is 8184 bytes one would expect that for 2 bytes file the packets would be in a form of: 1:8184,2:8184,3:3632 thus total of 2 bytes. But in fact the behavior is rely weird: 1:8184,2:8,3:8184,4:8,5:3616. Instead only three, the five! packets are transferred. Seems that algorithm is breaking 8192 bytes of data to two packets (8184 and 8 bytes). Ajp13.java... No that is the old code the new one is in JkCoyoteHandler.java. In JkCoyoteHandler the method doWrite cuts the 8192 bytes in 2 messages: one of 8184 and the other of 8 bytes that is the problem. Bill, Any idea how to solve this, because it's way too inefficient. What's makes the things even worse is that for each packet Apache2 creates a transient bucket thus rising the memory usage. 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: JK 1.2.13 TAGGED - ws_write call to ap_rflush in mod_jk.c
Mladen Turk wrote: Jean-Jacques Clar wrote: re-sending : Am I missing details? Calling ap_rflush() at the end of ws_write() in mod_jk.c is causing me problems when doing downloads from the server to a client. Performance degradation and, less importantly, memory usage, are the problems. Seems we are the only module out there that calls the apr_rflush in Apache2. Althought I said 'no more features' I propose that we make a config option that will be in the form of: JkFlush (On|Off|size) with On as default for each packet write. That way we'd be able to flush after each write, flush after each 'size' bytes or not flush at all. How that sounds? Won't it be better to have a ws_flush()? 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: JK 1.2.13 TAGGED
Mladen Turk wrote: Günter Knauf wrote: Hi Mladen, JK 1.2.13 has been taggeded as we agreed last week, and the tarballs are available at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.13/ any particular reason why you didnt tag my last commit on jk_connect.c? http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/jk/native/common/jk_connect.c?rev=1.59view=log now we can again not build for AP13 on NetWare without patching. I thought you said last time that you are fine with the patch? Seems I made a mistake while tagging, although have no idea why that happened :(. I've retagged the jk_connect.c JK_1_2_13 to rev 1.59, so that Netware patches are now included. Hope I didn't break any ASF rule by that. Should I recreate the tarballs? I am not 100% ok with this because the tarballs without the patch are already in mirrors... If the error is only in NetWare put the patch in README.html of /www/www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/netware. 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: JK 1.2.13 TAGGED - ws_write call to ap_rflush in mod_jk.c
Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: JkFlush (On|Off|size) with On as default for each packet write. That way we'd be able to flush after each write, flush after each 'size' bytes or not flush at all. Won't it be better to have a ws_flush()? Not sure what you mean by that. Like a generic callback? Yes to able to flush the same way we write. Not sure if it would make sense. IIS for example does auto flushing, so It's only needed for Apache2. Having 'JkFlush size' like 'JkFlush 65536' will insert an EOS bucket after 64K. Having large chunks might make problems to outgoing filters like deflate, that depends on EOS bucket for compressing window size. Right now the chunk size is AJP packet size (8K) that might cause memory problems like JJC said. yep. (write(8K) + flush())*n is not ok. (write(8K)*n + flush() is the right thing. Adding that as configurable server wide option will not break exiting behavior, while it might speed up large data transfer, and keep the memory low. If 'JkFlush Off' is used a single ap_rflush will be issued when all the data is send. Then why not using 'JkFlush Off' as default behaviour? 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: JK 1.2.13 TAGGED - ws_write call to ap_rflush in mod_jk.c
Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: I think on/off is enough - Think of the questions nnn will bring in user list - So how about to just add the flag to JkOptions like +FlushPackets? +1. 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: JK 1.2.13 TAGGED - ws_write call to ap_rflush in mod_jk.c
Henri Gomez wrote: good idea. Which state by default ? off (-FlushPackets). 2005/5/18, jean-frederic clere [EMAIL PROTECTED]: Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: I think on/off is enough - Think of the questions nnn will bring in user list - So how about to just add the flag to JkOptions like +FlushPackets? +1. 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] - 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]
[Fwd: [daemon] VOTE release daemon 1.0.1]
For info. Cheers Jean-Frederic ---BeginMessage--- Hi, All the known bugs bug are now fixed and 2 new parameters are now supported -wait and -stop The RC is here: http://people.apache.org/~jfclere/daemon-1.0.1.tar.gz Cheers Jean-Frederic - To unsubscribe, e-mail: [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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
Remy Maucherat wrote: jean-frederic clere wrote: I will try to solve the problem with a filter. You can simply call response.getWriter() in your filter if you determine the file needs to use fileEncoding. I have used a filter with two wrappers one for GET the other for PUT, Now Tomcat runs correcly on the BS2000 Mainframe. 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: Tagging 1.2.12
Mladen Turk wrote: Hi, It's been a week since 1.2.11 has been tagged and released. Because of bug in wc_close, and sice no other bugs have been reported for a week, I plan to tag the 1.2.12 tomorrow morning, 10:00 GMT. Any objections? It seems a lot of people are on holidays in Europe. 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-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
jfclere 2005/05/04 00:04:30
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
When the file comes from a resource fileEncoding was not working.
The default beahviour is unchanged: the file is send without a
conversion.
if (cacheEntry.resource != null) {
byte buffer[] = cacheEntry.resource.getContent();
if (buffer != null) {
+if (fileEncoding != null
+cacheEntry.attributes.getMimeType()!=null
+
cacheEntry.attributes.getMimeType().equals(text/html)) {
+/* the binary have to be converted from
fileEncoding to UTF-8 */
+try {
+String str = new String(buffer, fileEncoding);
+buffer = str.getBytes(UTF-8);
+} catch (Exception e) {
+}
+}
ostream.write(buffer, 0, buffer.length);
return;
So, can you revert the patch ? I think that's what we more or less
agreed on, right ?
Done.
Forcing the use of a writer using a getWriter call would likely be more
efficient (much less GC hungry at least).
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]
JspReader/Parser and encoding
Hi, When following the code, something looks strange: The JspReader converts from sourceEnc to JAVA (UTF-8) so why isDefaultPageEncoding not set to true? Find enclosed the patch I have tested on BS2000 with jsp files in EBCDIC using +++ jsp-property-group url-pattern/*/url-pattern page-encodingOSD_EBCDIC_DF04_1/page-encoding /jsp-property-group +++ In web.xml Without the patch the page is sent in EBCDIC to the broswer (text/html;charset=OSD_EBCDIC_DF04_1). Any comments? Cheers Jean-Frederic Index: jasper2/src/share/org/apache/jasper/compiler/ParserController.java === RCS file: /home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java,v retrieving revision 1.56 diff -u -r1.56 ParserController.java --- jasper2/src/share/org/apache/jasper/compiler/ParserController.java 11 Jan 2005 22:14:55 - 1.56 +++ jasper2/src/share/org/apache/jasper/compiler/ParserController.java 5 May 2005 15:28:09 - @@ -208,6 +208,10 @@ JspReader jspReader = new JspReader(ctxt, absFileName, sourceEnc, inStreamReader, err); +// If sourceEnc is used the page is converted by jspReader +if (sourceEnc!=null) +isDefaultPageEncoding=true; + parsedPage = Parser.parse(this, jspReader, parent, isTagFile, directiveOnly, jarFileUrl, sourceEnc, jspConfigPageEnc, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfclere 2005/05/04 00:04:30 Modified:catalina/src/share/org/apache/catalina/servlets DefaultServlet.java Log: When the file comes from a resource fileEncoding was not working. The default beahviour is unchanged: the file is send without a conversion. This kind of operation is extremely costly (will likely make fileEncoding a problematic option, as imagine doing it on a 1MB text file), and seems wrong: the purpose of the byte based sending is to send the resource unchanged. Yes, but if the text files are encoded in EBCDIC for example we will send EBCDIC to the browsers. 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-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
Remy Maucherat wrote: jean-frederic clere wrote: Yes, but if the text files are encoded in EBCDIC for example we will send EBCDIC to the browsers. Your change makes using the fileEncoding option extremely harmful. For straight file serving, we need to send the unchanged resource's bytes, so you need to properly encode them on your HD. This is not going to change. but http://jakarta.apache.org/tomcat/tomcat-5.5-doc/default-servlet.html tells about fileEncoding: +++ File encoding to be used when reading static resources. [platform default] +++ My platform default is OSD_EBCDIC_DF04_1 I have no chances to convince the users to use UTF-8 for text files! and httpd (apache-1.3) it is serving those files correctly. What about converting the files when reading them? The purpose of fileEncoding is to be used when including static files using a request dispatcher, that's it. 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-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
Remy Maucherat wrote: jean-frederic clere wrote: Remy Maucherat wrote: but http://jakarta.apache.org/tomcat/tomcat-5.5-doc/default-servlet.html tells about fileEncoding: +++ File encoding to be used when reading static resources. [platform default] +++ My platform default is OSD_EBCDIC_DF04_1 I have no chances to convince the users to use UTF-8 for text files! and httpd (apache-1.3) it is serving those files correctly. Do you mean it has the same kind of ugly check for text files, and the same kind of file encoding option, and the same reencoding ? I won't tell it ugly, but yes the text file are in EBCDIC in the machine and converted to ASCII before beeing send to the browsers. What about converting the files when reading them? No. I contend resources must be served as is in the default operation mode of DefaultServlet. If you disagree with that, you can use a filter, right ? I will try to solve the problem with a filter. 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]
WebappClassLoader patch for EBCDIC
Hi,
I have prepared a patch to be able to use properties in native encoding. In
EBCDIC Environment the FileInputStream is localized but not the
ByteArrayInputStream therefore loading a properties using the WebappClassLoader
class loader fails.
Any comment before I commit the attached patch?
Cheers
Jean-Frederic
Index: catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.48
diff -u -r1.48 WebappClassLoader.java
--- catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
30 Mar 2005 13:01:00 - 1.48
+++ catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
3 May 2005 06:46:51 -
@@ -354,6 +354,11 @@
*/
protected boolean hasExternalRepositories = false;
+/**
+ * need conversion for properties files
+ */
+protected boolean needConvert = false;
+
/**
* All permission.
@@ -1444,6 +1449,15 @@
public void start() throws LifecycleException {
started = true;
+String encoding = null;
+try {
+encoding = System.getProperty(file.encoding);
+} catch (Exception e) {
+return;
+}
+if (encoding.indexOf(EBCDIC)!=-1) {
+needConvert = true;
+}
}
@@ -1695,6 +1709,8 @@
Resource resource = null;
+boolean fileNeedConvert = false;
+
for (i = 0; (entry == null) (i repositoriesLength); i++) {
try {
@@ -1728,6 +1744,12 @@
return null;
}
+if (needConvert) {
+if (path.endsWith(.properties)) {
+fileNeedConvert = true;
+}
+}
+
// Register the full path for modification checking
// Note: Only syncing on a 'constant' object is needed
synchronized (allPermission) {
@@ -1855,8 +1877,8 @@
byte[] binaryContent = new byte[contentLength];
+int pos = 0;
try {
-int pos = 0;
while (true) {
int n = binaryStream.read(binaryContent, pos,
@@ -1874,6 +1896,14 @@
return null;
}
+if (fileNeedConvert) {
+String str = new String(binaryContent,0,pos);
+try {
+binaryContent = str.getBytes(UTF-8);
+} catch (Exception e) {
+return null;
+}
+}
entry.binaryContent = binaryContent;
// The certificates are only available after the JarEntry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't compile jk nativ connector under Suse 9.3
William A. Rowe, Jr. wrote: At 01:32 AM 4/27/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: ... Thank you; but the other half of my question... It was my fault. SD_SEND is defined only on winsock. On other platforms it is 1. Already committed a fix. Why a Win32 fix rather than a proper posix fix? I suspect you were looking for SHUT_WR in sys/socket.h. Even my most crufty 2.95 gcc compilers offer it. SHUT_WR and other are also in the sys/socket.h of Solaris and BS2000 ;-) Bill - 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: bugs 34140 and 34199
Thanks ;-) I will do the following: 1 - Add a switch to jsvc to stop the service (doing in C what Henri is doing in his shell script). 2 - Add a switch to jsvc to wait until the controller process reaches its loop by doing the following: create_tmp_file(); while (!stopping) sleep(60); /* pause() not threadsafe */ remove_tmp_file(); Any comments? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bugs 34140 and 34199
Hi, Those 2 are reported against Daemon, but the user is looking for a safe way to know that Tomcat is completly up (AJP connector ready) or completly down. In jsvc the completly down case is easy: the JVM has exited. Any hints for the completly up case? Cheers Jean-frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src network.c
Remy Maucherat wrote: Mladen Turk wrote: [EMAIL PROTECTED] wrote: jfclere 2005/04/16 03:31:34 Modified:jni/java/org/apache/tomcat/jni Socket.java jni/native/src network.c Log: Throw an exception when bind() failed. Why did you do that? I mean there is no need to throw an exception if we can get a direct APR status code. The trow is used *only* for functions that return status and fill a single pointer. We are not trying to be Java compatible, but as close to follow the APR api (as is possible). Yes, please don't start adding exception throwing everywhere. I'm only -0 for this particular commit, since there are far worse places to throw something. Ok I am now convinced that testing apr-status is better than throwing exception... 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: bugreports for commons-daemon
Simon Kitching wrote: Hi, Commons-daemon is shipped with Tomcat. In fact, I believe it originated in the Tomcat project and was moved to commons. However it appears that there are no longer any active developers working on commons-daemon. The number of bugreports in bugzilla for this component is growing: currently at 11 open bugreports + 1 reasonable enhancement request. I will try to spend some time on the problems. I just thought I would bring this to your attention...if there are any tomcat developers willing to dedicate some time to addressing these bugreports I am sure it would be appreciated. Cheers, Simon - 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]
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/building.html
Hi, I have tried to build the tomcat following the document. The part about using proxy misses the problems related to cvs (cvs does not support http-proxy and ssh + ext could be used for committers). I have some questions: - When do we move to subversion? - Does it make sense to improve the building.html document? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/examples/org/apache/tomcat/jni Echo.java
Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
+int rc = Socket.bind(serverSock, inetAddress);
+if (rc != 0) {
+ throw(new Exception(Can't create Acceptor:bind
failed));
+}
You can use 'throw(new Exception(Error.strerror(rv)));'
It will return apr_os_error.
done.
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: Tomcat and APR
Henri Gomez wrote: Well I've no problems with using APR if we could still use a pure Java implementation. Some may not have APR on their boxes, or an incorrect version of APR, or an invalid APR configuration (ie not multi-threaded). Remember mod_webapp and the reasons why it failed, ie too many peoples couldn't get the correct APR for there machine. A the time of mod_webapp APR was not stable enough, now this has improved a lot. So if we could make it configurable, via server.xml for example, using APR seems a great idea. On 4/14/05, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, Apologies if I missed it, but I've seen responses to Yoav's and Peter's posts, but I have yet to see anything about Jess' NIO question. Since I agree with his observations, I was wondering if a reponse was in the works? (I assume it'll say something like, Yes, a Java NIO solution could very well provide enough improvements, but APR is already written, fully-established, and field- tested.) Just curious. In addition to Remy's response, you may want to search the message archives for this list. We've discussed NIO many times in the past in good depth. Yoav - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and APR
Henri Gomez wrote: I've got no problem with APR stability but availability in the correct version for some OS, ie iSeries or ... BS2000 :) Right there is also the thread libraries APR should use the same the JMV is using (no always easy to find). On 4/15/05, jean-frederic clere [EMAIL PROTECTED] wrote: Henri Gomez wrote: Well I've no problems with using APR if we could still use a pure Java implementation. Some may not have APR on their boxes, or an incorrect version of APR, or an invalid APR configuration (ie not multi-threaded). Remember mod_webapp and the reasons why it failed, ie too many peoples couldn't get the correct APR for there machine. A the time of mod_webapp APR was not stable enough, now this has improved a lot. So if we could make it configurable, via server.xml for example, using APR seems a great idea. On 4/14/05, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, Apologies if I missed it, but I've seen responses to Yoav's and Peter's posts, but I have yet to see anything about Jess' NIO question. Since I agree with his observations, I was wondering if a reponse was in the works? (I assume it'll say something like, Yes, a Java NIO solution could very well provide enough improvements, but APR is already written, fully-established, and field- tested.) Just curious. In addition to Remy's response, you may want to search the message archives for this list. We've discussed NIO many times in the past in good depth. Yoav - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native BUILDING
Mladen Turk wrote: [EMAIL PROTECTED] wrote: Building from the cvs tree: chmod a+x build/get-version.sh Need the chmod a+x build/get-version.sh too. BTW, do you know how to set the modes in CVS so they'll get checkout correctly? I don't remember for the moment but I will do it later. Regards, Mlade. - 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] Tomcat 5.X connectors SSL Accelerator proxy support
[EMAIL PROTECTED] wrote: Dev Team, Attached is a patch to address the Tomcat 5.X inability to specify a secure proxy without an SSL connection. The goal is to specify secure=true, scheme=https, proxyPort=443, and proxyName=ssl-accelerator.domain.com on a plain HTTP Connector in server.xml. BTW: This proxy does not allow to get client certificates doesn't it? I am not sure if this is the best, (or even acceptable), solution, but it is the simplest I could come up with while not changing the documented Tomcat 5.X Connector attributes. The configuration above used to work with Tomcat 4.1, because the SSL support was never enabled unless the Factory/ tag was specified within the Connector specification. The approach here for Tomcat 5.X is to ignore the secure attribute/property configuration in the underlying Http11Protocol instance if the Connector is configured with either a proxyPort or proxyName and there are no other explicit SSL configuration attributes specified. The logic behind this choice is that use of an SSL Accelerator will imply a proxied port and/or host and will not specify any SSL related options. Furthermore, in the event a proxied SSL Connection was desired afterall, it will almost always require at least some keystore access configuration. One possible variation might be to only ignore the secure configuration if the proxyName is set; this might be preferable if simple port forwarding on the host server is more prevalent than the use of SSL Accelerators, (albeit potentially more confusing). The patch is limited to the jakarta-tomcat-connectors module and should be compatible with Tomcat 4.1 and Tomcat 5.X versions. It has been tested only against Tomcat 5.0.30 so far. If someone the Dev Team indicates that this patch is acceptable, I can certainly proceed with Tomcat 4.1 and Tomcat 5.5 testing... I just would like a sanity check first if at all possible. Note: I believe that the minor patch to o/a/coyote/Request.java has already been performed against the Tomcat 5.5 main trunk by Remy, but was missing on the Tomcat 5.0 branch. Thanks for your consideration in advance, Randy Watler Finali-Convergys Corporation - 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: [VOTE] Propose Jim Jagielski and William A. Rowe as JakartaTomcatConnectors commiters
+1 for both Great to see them with us ;-) Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS commit request - jakarta-tomcat-connectors
Jim Jagielski wrote: I'd like to request commit privs for the jakarta-tomcat-connectors tree. I will be working mostly on the apache/mod_jk integration aspects to complement what is going on in the httpd mod_proxy side. Great ;-)) you need to be in the jakarta group. - 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]
