Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Ack - there was a lingering #ifdef JK_NEED_... which should have been an #if JK_NEED_... - this is fixed in cvs, please retry and thanks for the detailed report! Bill Tim Whittington wrote: Confused me too. Error message is listed below. [exec] cl.exe /nologo /MD /W3 /Zi /O2 /I ..\common /I C:\j2sdk1.4.2_07\include /I C:\j2sdk1.4.2_07\include \win32 /I C:/Program Files/Apache Group/Apache2\include /D NDEBUG /D WIN32 /D _WINDOWS /Fo.\Release\\ /Fd.\R elease\mod_jk_src /FD /c ..\common\jk_worker.c [exec] jk_worker.c [exec] cl.exe @C:\TEMP\nm7CC.tmp [exec] mod_jk.c [exec] mod_jk.c(2437) : warning C4013: 'unixd_set_global_mutex_perms' undefined; assuming extern returning int [exec] link.exe @C:\TEMP\nm7CD.tmp [exec] LINK : fatal error LNK1104: cannot open file 'MSVCRT.lib' [exec] NMAKE : fatal error U1077: 'link.exe' : return code '0x450' [exec] Stop. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Tim Whittington wrote: This breaks the build on Windows using Microsoft Visual C++ Toolkit 2003 (at least). It seems #define FOO 0 on WIN32 is still defined according to #ifdef Your suggestion is counterintuitive and reflects, perhaps, a compiler bug. It would be very helpful if you would post the *precise* error messages from msvc 7. Thanks! Bill - 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
Question - is gump building against apache 2 trunk or against the httpd/branches/2.0.x (or some other particular httpd snapshot/rev)? The failure below... Making all in apache-2.0 make[1]: Entering directory `/x1/gump/public/workspace/jakarta-tomcat-connectors/jk/native/apache-2.0' /usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -DUSE_APACHE_MD5 -I ../common -I /opt/jdk1.4/include -I /opt/jdk1.4/include/unix -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 -I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -c mod_jk.c -o mod_jk.lo mod_jk.c:85:28: #if with no expression didn't jive with my expectations below, unless AP_NEED_SET_MUTEX_PERMS was actually defined, and it shouldn't be defined on 2.0.x. I'm going to propose the patch today to define AP_NEED_SET_MUTEX_PERMS to 1, and then move forward to define it 0 everywhere else on httpd 2.1.x and beyond. I'll propose today so if we are fetching up 2.1+ to build against, this problem should be resolved. The code (the final #if was the one which had 'no expression'). /* Yes; sorta sucks - with luck we will clean this up before httpd-2.2 * ships, leaving AP_NEED_SET_MUTEX_PERMS def'd as 1 or 0 on all platforms. */ #ifdef AP_NEED_SET_MUTEX_PERMS # define JK_NEED_SET_MUTEX_PERMS AP_NEED_SET_MUTEX_PERMS #else /* A special case for httpd-2.0 */ # if !defined(OS2) !defined(WIN32) !defined(BEOS) !defined(NETWARE) # define JK_NEED_SET_MUTEX_PERMS 1 # else # define JK_NEED_SET_MUTEX_PERMS 0 # endif #endif #if JK_NEED_SET_MUTEX_PERMS #include unixd.h /* for unixd_set_global_mutex_perms */ #endif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commit 1.153 on jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Mladen (and everyone) ... could you please provide more descriptive commit log messages? At least, one sentence of what the commit fixes? This one wasn't too helpful, and wastes extra time reviewing commits. Thanks :) Revision 1.153 - (view) (download) (as text) (annotate) - [select for diffs] Mon Sep 12 13:26:06 2005 UTC (8 hours, 6 minutes ago) by mturk Branch: MAIN CVS Tags: HEAD Changes since 1.152: +2 -2 lines Diff to previous 1.152 (colored) Fix #bug 35809. Patch provided by Christophe Dubach . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commit 1.153 on jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Remy Maucherat wrote: William A. Rowe, Jr. wrote: Mladen (and everyone) ... could you please provide more descriptive commit log messages? At least, one sentence of what the commit fixes? This one wasn't too helpful, and wastes extra time reviewing commits. Very funny. It even links the bug report, the diff is 3 chars long, and even I can understand it. Meaning I aught to delve every bug report, every diff, every time I try to read the cvs commit log of 24 months of activity? Get real :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commit 1.153 on jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
William A. Rowe, Jr. wrote: Remy Maucherat wrote: William A. Rowe, Jr. wrote: Mladen (and everyone) ... could you please provide more descriptive commit log messages? At least, one sentence of what the commit fixes? This one wasn't too helpful, and wastes extra time reviewing commits. Very funny. It even links the bug report, the diff is 3 chars long, and even I can understand it. Meaning I aught to delve every bug report, every diff, every time I try to read the cvs commit log of 24 months of activity? Get real :) Let me rephrase :) I've been digging since Sunday a.m. through about 270 commits from 5 projects, across dozens and dozens of files, looking for various issues and edge cases. Yes, for pure review of a single case, the bug #'s have been extraordinarily helpful! But in terms of seeing net changes on some files I'm looking at, without even a mention such as Fix JKMountCopy directive. is a huge waste of otherwise productive time :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c]
I didn't miss the SVN conversion horizion?
This needs to hit jk before we roll out 1.2.15. 1.152 broke Apache 2.0
builds (while conforming to Apache 2.2) - so this patch is the umbrella
which addresses both flavors.
Bill
Original Message
Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Date: 12 Sep 2005 22:21:31 -
From: [EMAIL PROTECTED]
Reply-To: Tomcat Developers List tomcat-dev@jakarta.apache.org
To: [EMAIL PROTECTED]
wrowe 2005/09/12 15:21:31
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Modify the test introduced in 1.152 for httpd-2.2 compatibility, the
new symbol isn't available in httpd-2.0 leading to perms issues.
This patch anticipates that the flag will become a 0|1 flag defined
always before httpd-2.2 ships.
Revision ChangesPath
1.154 +16 -2
jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.153
retrieving revision 1.154
diff -u -r1.153 -r1.154
--- mod_jk.c 12 Sep 2005 13:26:06 - 1.153
+++ mod_jk.c 12 Sep 2005 22:21:31 - 1.154
@@ -68,7 +68,21 @@
#include apr_strings.h
+/* Yes; sorta sucks - with luck we will clean this up before httpd-2.2
+ * ships, leaving AP_NEED_SET_MUTEX_PERMS def'd as 1 or 0 on all
platforms.
+ */
#ifdef AP_NEED_SET_MUTEX_PERMS
+# define JK_NEED_SET_MUTEX_PERMS AP_NEED_SET_MUTEX_PERMS
+#else
+ /* A special case for httpd-2.0 */
+# if !defined(OS2) !defined(WIN32) !defined(BEOS)
!defined(NETWARE)
+# define JK_NEED_SET_MUTEX_PERMS 1
+# else
+# define JK_NEED_SET_MUTEX_PERMS 0
+# endif
+#endif
+
+#if JK_NEED_SET_MUTEX_PERMS
#include unixd.h /* for unixd_set_global_mutex_perms */
#endif
/*
@@ -2419,7 +2433,7 @@
return HTTP_INTERNAL_SERVER_ERROR;
}
-#ifdef AP_NEED_SET_MUTEX_PERMS
+#ifdef JK_NEED_SET_MUTEX_PERMS
rv = unixd_set_global_mutex_perms(jk_log_lock);
if (rv != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, 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]
[Vote] (was Re: Top Level Project? Time for Top Level Lists?)
Costin Manolache wrote: Remy Maucherat wrote: I doubt that filling the inbox with the bug reports or commit messages will make anyone care more ( or make anyone read them when they don't want to ) :-) It seems most people use filters anyway, and those who don't ( like using gmane or a web-based interface ) just suffer the noise, but still ignore the bugs/commits they don't care about. I would really appreciate splitting them - I try to read tomcat-dev as much as possible, but web-based interfaces ( like gmane's RSS view or the html viewer ) are almost useless due to the noise, and filtering the news is not easy either. Well, my first point was that, as a TLP, the lists should become @tomcat.apache.org; whatever they become. But AFA different lists are concerned, is it worth a vote? I'm going to abstain, as I'm not on the PMC (IIRC). But here it is, go ahead and cast an opinion... Bugs [ ] forward to [EMAIL PROTECTED] [ ] forward to [EMAIL PROTECTED] Commits [ ] forward to [EMAIL PROTECTED] [ ] forward to [EMAIL PROTECTED] Vote away :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Top Level Project? Time for Top Level Lists?
Folks, as Tomcat is now (IIUC) a TLP, is it time to break apart the single dumping ground, fondly known as tomcat-dev, into multiple lists for folks with more targeted issues? E.g. [EMAIL PROTECTED] - our friend, this list [EMAIL PROTECTED] - svn/cvs commits [EMAIL PROTECTED] - bugzilla/jira reports I bring this up because, for example, I don't monitor the bugzilla noise as an email stream much, but want to continue to actively monitor cvs commits, and development chatter. I can see some [EMAIL PROTECTED] types who would be interested in following [EMAIL PROTECTED], but who have little to no interest in watching commits@ fly by. So I, for one, would be most appreciative of splitting the traffic; I already do split it in my email client, but I think this would be a help to many participants. [Especially if, for example, you want the dev@ traffic to go to a higher priority email account, and have the commits/issues type traffic hit your lower priority account.] Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Top Level Project? Time for Top Level Lists?
Remy Maucherat wrote: Of course, but also fewer people will care about bug reports. Perhaps; perhaps not. In my case, I prefer to use the tool, and take advantage of the whole bugzilla/jira feature set. Bug emails are noise, because they scream me, me!, instead of reflecting on all the long outstanding, quiet bugs. Just two different perspectives, I guess. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fwd: Reminder: CFP for ApacheCon
At 10:14 AM 8/11/2005, Yoav Shapira wrote: Hi, These are good, but I feel like we should talk about the new stuff we've been doing: PMC, APR connector, etc. Then again, I don't feel like doing the talks myself at the moment, so I'll just shut up about it now ;) Well, pmc is a noop (it's business not project) ... the APR connector would be very cool, and if anyone wants to point it out in my win32 'roll your own track' as the third alternative, I'd be happy to recognize you from the podium! But my point was that Tomcat itself needs coverage, and although I think the deadline just passed, I hope that enough proposals were submitted to satisfy the hungry servlet and jsp authors. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Reminder: CFP for ApacheCon
At 02:51 PM 8/9/2005, Yoav Shapira wrote: Hey, Is anyone speaking about Tomcat at ApacheCon 2005 US? It will be nice to have something... And related to that, who's planning on going? In my two tracks (one may be BOF) I will be speaking to both mod_proxy_ajp and mod_jk on Win32. But truly had no plans to delve into the Java side of Tomcat, only the connection layer. If a Win32 user has questions trying to get up and going with the Apache side of Tomcat, my preso or BOF, if accepted, might prove helpful. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JK 1.2.14.1
At 11:08 AM 7/11/2005, jean-frederic clere wrote: JK 1.2.14 has been released. Uhm, I've said several times before you took a stab at being the RM, but no, it had not been released, it's just a tarball. You must wait for 3 +1's and more +1's than -1's before calling it released. blogs, slashdot etc are known to prematurely announce releases if the messages aren't worded correctly on the dev lists, and this has caused headaches to the httpd project on more than one occasion :) Usually I'd pick the phrase A release candidate is available at ..., please test this tarball and vote. Please vote: [X] Stable -- good build [ ] Alpha -- something serious is wrong: what is it? So... I'll vote :) Nice work! Regression tested against both Apache 1.3 and 2.0 on Solaris 8, Linux 2.4 kernel and HPUX 11. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
At 01:25 PM 7/11/2005, you wrote: William A. Rowe, Jr. wrote: It's important for students involved with SoC to learn to use the tools of our organization; I don't agree with you. The Tomcat is not place for some 'sandbox' projects. If the ASF have some agreement with Google then it should have created a 'SoC Google sandbox' not trying to force every project to create a 'Google sandbox'. The ASF didn't agree with Google that 'we need more code' (many projects seem overwhelmed at times by the amount of code they manage already, no slight intended...) The ASF agreed that Open Source needs to continue to grow in contributors. The only way to grow more contributors is to have them learn in-place. The mentor's job is to help them set up, avoid the usual foibles, help them participate in the community, and do a bit of steering of the project. Because the entire pace is 'accelerated' it is humanistically challenging, but far from impossible to bring an individual up to speed over a month or few. So it's unusual, and we aren't handing away keys to the entire kingdom. But setting up a sandbox (not your problem, it's the mentors) and watching the progress (if it scratches your itch) is not an imposition on the individual project communities. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JK 1.2.14 core dump oddity
Something's not quite right in mod_jk-land. The pertinent httpd.conf is; ErrorDocument 404 /examplestomcat/error.jsp Alias /examplestomcat /local0/test/webapps/examplestomcat JkMount /examplestomcat/*.jsp ajp13 when the 404 causes error.jsp to be returned, the response code is unset from 404 to 200-ok. This behavior is not a regression, seems it's been that way for a long (1.2.8 or earlier) time. Line 1971 of jk/native/apache-2.0/mod_jk.c says... return OK; /* NOT r-status, even if it has changed. */ This goes back to version 1.1 of the module; the question is; WHY? Bill Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.14 core dump oddity
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. At 02:52 PM 7/12/2005, William A. Rowe, Jr. wrote: Something's not quite right in mod_jk-land. The pertinent httpd.conf is; ErrorDocument 404 /examplestomcat/error.jsp Alias /examplestomcat /local0/test/webapps/examplestomcat JkMount /examplestomcat/*.jsp ajp13 when the 404 causes error.jsp to be returned, the response code is unset from 404 to 200-ok. This behavior is not a regression, seems it's been that way for a long (1.2.8 or earlier) time. Line 1971 of jk/native/apache-2.0/mod_jk.c says... return OK; /* NOT r-status, even if it has changed. */ This goes back to version 1.1 of the module; the question is; WHY? Bill 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: JK 1.2.14 core dump oddity
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. 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]
Re: [VOTE] SOC temporary committer Anders Nyman
At 03:48 AM 7/12/2005, Mladen Turk wrote: Well if Tim wants to mentor that project, then fine with me. I'm sure he will ensure the integrity of the Tomcat source outside that 'sandbox' repository. Exactly the point; there were no SoC participants who did not have mentors. If this slides into the Tomcat CVS, the mentor will help with calling the vote, following procedures, etc. If the project will have access and modify the files outside that repository, I'll be strongly against that. No; I don't think anyone is asking for the SoC participants to have live access on projects that have strong traditions of merit-before-commit privileges. Some projects are much loser granting commit, such projects would probably just add another committer for the summer. I'm sure the Tim will find a solution for a files that needs to be changed and that are are of the core, by simply mirroring them to the sandbox repository or something similar. Or merging back the outcome with history. I just wanted to point out three other things; * it's really much easier if the sandbox is in svn:, such users don't need accounts on a box. * no matter if cvs or svn, the sandbox commits must be broadcast to [EMAIL PROTECTED] read or ignore them as you please. And please don't complain about the outcome if you didn't feel like actually following the progress :) * development discussion under the tomcat umbrella should occur on [EMAIL PROTECTED], the whole point is for the participants to follow the day to day life of a project, and be welcome to put forward proposals and accept feedback. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
At 12:52 PM 7/11/2005, Mladen Turk wrote: I have developed, and I am developing the majority of the code without being connected to the CVS all the time. It's important for students involved with SoC to learn to use the tools of our organization; and it's equally important that we capture the history and evolution of the code, from its infancy through the process of peer review. A code dump isn't what we are looking for, and the code should be developed incrementally with peer/mentor review. -1 to any SoC happening outside of Tomcat's purview. +1 to creating a sandbox for this project so the effort can be merged back in, trivially, if and when it's successful (that includes successful peer review, the usual 3 +1's etc.) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
j-t-c/common/build - j-t-c/jk/support ?
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? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
Assuming you have apr checked out, apr/build/lineends.pl --cr will convert a tree to cr/lf dos format, and info-zip does a lovely job on Unix of zipping it up. Bill At 12:02 PM 7/6/2005, 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. Think you'll need a win platform for making those. If you don't have one, I can build a .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]
Re: Releasing JK 1.2.14
At 12:50 PM 7/6/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: Assuming you have apr checked out, apr/build/lineends.pl --cr will convert a tree to cr/lf dos format, and info-zip does a lovely job on Unix of zipping it up. Right, a smarter unix2dos :) Yup :) It has the benefit that if it sees randomly placed ^M's that don't coincide with ^J's, or if some ^J's have ^M's and some don't, it asserts that the file is binary. --force will override if, for example, someone tosses in a few ^M's or strips them making the file inconsistent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
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. 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.) 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]
Re: cvs commit: jakarta-tomcat-connectors/jni/native configure.in
At 02:01 AM 6/23/2005, Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
jfclere 2005/06/21 03:31:41
Log:
-Wall is only for gcc.
That's true. But if your 'cc' doesn't support
the -Wall then make CFLASG with some platform
switch rather then interfering with 99% of others that are using gcc.
The -Wall is very valuable when dealing with compile warnings,
and that was the main reason what the --enable-maintainer-mode
was added at the first place. It makes no sense without.
-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.
Bill (Who's wasted untold hours fighting with auto linux-isms
lately and who has no humor left for penguins :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat on remote server
At 01:00 AM 6/20/2005, sai krishna wrote: Hello list, Is there no one to really answer my question here?? Nope. You want an appropriate users list, this list is for the development of the Tomcat server. Please review http://jakarta.apache.org/site/mail.html Bill - 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; 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. 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]
Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
At 02:08 PM 6/7/2005, Mladen Turk wrote: It works of course, but IIRC you are planning to use it for reconfiguring mod_jk. I think you might get into the problems with shared memory (particularly on unix) because some child might have a different idea about shared memory addresses. Oh - so this is a bug/design flaw in mod_jk? Does the same affect the prefork/worker MPMs? One aspect is inheritance of handles (e.g. handle to SHM segment). I've always ment to make that more generic, and it would be nice to solve for Apache 2.2. It's used now to hand of the score and listener handles from the parent to child. The trivial solution is to use an anon segment which Win32 will not inherit, which means that SHM is unique to a single generation, and won't be polluted by changes in another worker. This does sound like a good use case, though, for handing off memory segments, mutexes and so forth to child processes. With a pointer or two, I'll be happy to look at it. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graceful restart on Windows [was Re: Adding working dynamically with mod_jk status?]
At 04:44 PM 5/31/2005, [EMAIL PROTECTED] wrote: After some more digging, it *appears* that apache -k restart WILL do a graceful restart of Apache2 on Windoze. Of course it will. Can anyone confirm this please? And are there any gotcha's to watch out for? Can someone explain exactly how this works? eg if I am in the middle of a chunk (or series) of work with a web browser and one of the tomcats, will it restart in the middle of that? It has nothing to do with Tomcat [in fact it's mildly off-topic here.] Essentially, the old child with multiple workers is told to quit it, so it stops accepting requests, and fulfills all the pending requests it accept()ed. And a new child is kicked off to serve all future incoming requests. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0
Apparently there was something peculiar with the line endings in the previous generation of these files. Here is the patch below, compressed with --ignore-space: Index: mod_jk.dsp === RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.dsp,v retrieving revision 1.10 retrieving revision 1.11 diff -u -b -r1.10 -r1.11 --- mod_jk.dsp 15 Feb 2005 12:02:27 - 1.10 +++ mod_jk.dsp 11 May 2005 23:38:30 - 1.11 @@ -42,8 +42,8 @@ # PROP Intermediate_Dir Release # PROP Ignore_Export_Lib 0 # PROP Target_Dir -# ADD BASE CPP /nologo /MD /W3 /Zi /O2 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /FD /c -# ADD CPP /nologo /MD /W3 /Zi /O2 /I ..\common /I $(APACHE1_HOME)\include /I $(APACHE1_HOME)\src\include /I $(APACHE1_HOME)\src\os\win32 /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /FdRelease\mod_jk_src /FD /c +# ADD BASE CPP /nologo /MD /W3 /O2 /Oy- /Zi /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /FD /c +# ADD CPP /nologo /MD /W3 /O2 /Oy- /Zi /I ..\common /I $(APACHE1_HOME)\include /I $(APACHE1_HOME)\src\include /I $(APACHE1_HOME)\src\os\win32 /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /FdRelease\mod_jk_src /FD /c # ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d NDEBUG Index: mod_jk.dsp === RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.dsp,v retrieving revision 1.12 retrieving revision 1.13 diff -u -b -r1.12 -r1.13 --- mod_jk.dsp 15 Feb 2005 12:02:28 - 1.12 +++ mod_jk.dsp 11 May 2005 23:38:30 - 1.13 @@ -42,8 +42,8 @@ # PROP Intermediate_Dir Release # PROP Ignore_Export_Lib 0 # PROP Target_Dir -# ADD BASE CPP /nologo /MD /W3 /O2 /D WIN32 /D NDEBUG /D _WINDOWS /FD /c -# ADD CPP /nologo /MD /W3 /Zi /O2 /I ..\common /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I $(APACHE2_HOME)\srclib\apr\include /I $(APACHE2_HOME)\srclib\apr-util\include /D NDEBUG /D WIN32 /D _WINDOWS /D HAVE_APR /FdRelease/mod_jk_src /FD /c +# ADD BASE CPP /nologo /MD /W3 /O2 /Oy- /Zi /D WIN32 /D NDEBUG /D _WINDOWS /FD /c +# ADD CPP /nologo /MD /W3 /O2 /Oy- /Zi /I ..\common /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I $(APACHE2_HOME)\srclib\apr\include /I $(APACHE2_HOME)\srclib\apr-util\include /D NDEBUG /D WIN32 /D _WINDOWS /D HAVE_APR /FdRelease/mod_jk_src /FD /c # ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d NDEBUG and here is the commit log that bounced - in all it's ugly glory: wrowe 2005/05/11 16:38:30 Modified:jk/native/apache-1.3 mod_jk.dsp jk/native/apache-2.0 mod_jk.dsp Log: Add the /Oy- following /O2, to disable this optimization. It specifically re-enables stack frame mechanics to help analize user.dmp files or perform JIT debugging of a crash(ing) Apache instance. Same patch in the works for httpd itself, making mod_jk and httpd crashes somewhat more traceable. Did not add /Gs0 per brane's comments, leaving the stack frame probes configured as /Gs (implied by /O2). Reviewed by: stoddard, brane Revision ChangesPath 1.11 +287 -287 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.dsp Index: mod_jk.dsp === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.dsp,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- mod_jk.dsp15 Feb 2005 12:02:27 - 1.10 +++ mod_jk.dsp11 May 2005 23:38:30 - 1.11 @@ -1,287 +1,287 @@ -# Microsoft Developer Studio Project File - Name=mod_jk - Package Owner=4 -# Microsoft Developer Studio Generated Build File, Format Version 6.00 -# ** DO NOT EDIT ** - -# TARGTYPE Win32 (x86) Dynamic-Link Library 0x0102 - -CFG=mod_jk - Win32 Debug -!MESSAGE This is not a valid makefile. To build this project using NMAKE, -!MESSAGE use the Export Makefile command and run -!MESSAGE -!MESSAGE NMAKE /f mod_jk.mak. -!MESSAGE -!MESSAGE You can specify a configuration when running NMAKE -!MESSAGE by defining the macro CFG on the command line. For example: -!MESSAGE -!MESSAGE NMAKE /f mod_jk.mak CFG=mod_jk - Win32 Debug -!MESSAGE -!MESSAGE Possible choices for configuration are: -!MESSAGE -!MESSAGE mod_jk - Win32 Release (based on Win32 (x86) Dynamic-Link Library) -!MESSAGE mod_jk - Win32 Debug (based on Win32 (x86) Dynamic-Link
cvs commit: jakarta-tomcat-connectors/jk/native/iis/installer
wrowe 2005/05/12 11:46:22 Modified:jk/native/iis/installer License.rtf Log: Fix the License.rtf after -kb'ing the file (the various \x10 \x11 \x13 all have specific meanings to this format.) Cuts HTTP Server Subcomponents from the license text. If any additional terms apply to mod_jk, I didn't find corresponding NOTICE files in this repository. Revision ChangesPath 1.2 +71 -265 jakarta-tomcat-connectors/jk/native/iis/installer/License.rtf Index: License.rtf === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/iis/installer/License.rtf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 Binary files /tmp/cvsYze2Of and /tmp/cvsaS9gES differ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/nt_service nt_service.dsp
wrowe 2005/05/12 11:55:09 Modified:jk/native/domino dsapi.dsp jk/native/iis isapi.dsp isapi_redirect.rc isapi_redirect.reg jk/native/iis/installer isapi-redirector-win32-msi.ism jk/native/isapi tomcat_redirector.reg jk/native/netscape nsapi.dsp jk/native/nt_service nt_service.dsp Log: All of the following -text- files suffered from /r/r/n problems. Wiping superfluous /r codes - whitespace only patch. Revision ChangesPath 1.10 +305 -305 jakarta-tomcat-connectors/jk/native/domino/dsapi.dsp http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/domino/dsapi.dsp.diff?r1=1.9r2=1.10 1.15 +299 -299 jakarta-tomcat-connectors/jk/native/iis/isapi.dsp http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/iis/isapi.dsp.diff?r1=1.14r2=1.15 1.4 +53 -53 jakarta-tomcat-connectors/jk/native/iis/isapi_redirect.rc http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/iis/isapi_redirect.rc.diff?r1=1.3r2=1.4 1.2 +9 -9 jakarta-tomcat-connectors/jk/native/iis/isapi_redirect.reg http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/iis/isapi_redirect.reg.diff?r1=1.1r2=1.2 1.9 +4595 -4595jakarta-tomcat-connectors/jk/native/iis/installer/isapi-redirector-win32-msi.ism http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/iis/installer/isapi-redirector-win32-msi.ism.diff?r1=1.8r2=1.9 1.2 +9 -9 jakarta-tomcat-connectors/jk/native/isapi/tomcat_redirector.reg http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/isapi/tomcat_redirector.reg.diff?r1=1.1r2=1.2 1.15 +275 -275 jakarta-tomcat-connectors/jk/native/netscape/nsapi.dsp http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/netscape/nsapi.dsp.diff?r1=1.14r2=1.15 1.10 +199 -199 jakarta-tomcat-connectors/jk/native/nt_service/nt_service.dsp http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/nt_service/nt_service.dsp.diff?r1=1.9r2=1.10 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src shm.c ssl.c
wrowe 2005/05/12 12:28:03 Modified:jni/native libtcnative.dsp libtcnative.dsw tcnative.dsp jni/native/build win32ver.awk jni/native/src shm.c ssl.c Log: Fix more ^M polution, whitespace changes, only. Revision ChangesPath 1.6 +218 -218 jakarta-tomcat-connectors/jni/native/libtcnative.dsp Index: libtcnative.dsp === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/libtcnative.dsp,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- libtcnative.dsp 3 Feb 2005 07:48:56 - 1.5 +++ libtcnative.dsp 12 May 2005 19:28:03 - 1.6 @@ -1,218 +1,218 @@ -# Microsoft Developer Studio Project File - Name=libtcnative - Package Owner=4 -# Microsoft Developer Studio Generated Build File, Format Version 6.00 -# ** DO NOT EDIT ** - -# TARGTYPE Win32 (x86) Dynamic-Link Library 0x0102 - -CFG=libtcnative - Win32 Debug -!MESSAGE This is not a valid makefile. To build this project using NMAKE, -!MESSAGE use the Export Makefile command and run -!MESSAGE -!MESSAGE NMAKE /f libtcnative.mak. -!MESSAGE -!MESSAGE You can specify a configuration when running NMAKE -!MESSAGE by defining the macro CFG on the command line. For example: -!MESSAGE -!MESSAGE NMAKE /f libtcnative.mak CFG=libtcnative - Win32 Debug -!MESSAGE -!MESSAGE Possible choices for configuration are: -!MESSAGE -!MESSAGE libtcnative - Win32 Release (based on Win32 (x86) Dynamic-Link Library) -!MESSAGE libtcnative - Win32 Debug (based on Win32 (x86) Dynamic-Link Library) -!MESSAGE - -# Begin Project -# PROP AllowPerConfigDependencies 0 -# PROP Scc_ProjName -# PROP Scc_LocalPath -CPP=cl.exe -MTL=midl.exe -RSC=rc.exe - -!IF $(CFG) == libtcnative - Win32 Release - -# PROP BASE Use_MFC 0 -# PROP BASE Use_Debug_Libraries 0 -# PROP BASE Output_Dir Release -# PROP BASE Intermediate_Dir Release -# PROP BASE Target_Dir -# PROP Use_MFC 0 -# PROP Use_Debug_Libraries 0 -# PROP Output_Dir Release -# PROP Intermediate_Dir Release -# PROP Ignore_Export_Lib 0 -# PROP Target_Dir -# ADD BASE CPP /nologo /MD /W3 /O2 /D WIN32 /D NDEBUG /D _WINDOWS /FD /c -# ADD CPP /nologo /MD /W3 /Zi /O2 /I ./include /I ../apr/include /I ../apr/include/arch/win32 /I $(JAVA_HOME)/include /I $(JAVA_HOME)/include/win32 /I ../openssl/inc32 /D NDEBUG /D TCN_DECLARE_EXPORT /D WIN32 /D _WINDOWS /D WIN32_LEAN_AND_MEAN /D NO_IDEA /D NO_RC5 /D NO_MDC2 /D OPENSSL_NO_IDEA /D OPENSSL_NO_RC5 /D OPENSSL_NO_MDC2 /D HAVE_OPENSSL /D HAVE_SSL_SET_STATE=1 /FdRelease\libtcnative_src /FD /c -# ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /o /win32 NUL -# ADD MTL /nologo /D NDEBUG /mktyplib203 /o /win32 NUL -# ADD BASE RSC /l 0x409 /d NDEBUG -# ADD RSC /l 0x409 /d NDEBUG -BSC32=bscmake.exe -# ADD BASE BSC32 /nologo -# ADD BSC32 /nologo -LINK32=link.exe -# ADD BASE LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib psapi.lib ole32.lib /nologo /base:0x6EE0 /subsystem:windows /dll /debug /machine:I386 /opt:ref -# ADD LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib psapi.lib ole32.lib libeay32.lib ssleay32.lib /nologo /base:0x6EE0 /subsystem:windows /dll /debug /machine:I386 /out:Release/libtcnative-1.dll /libpath:../openssl/out32dll /libpath:../openssl/out32 /opt:ref - -!ELSEIF $(CFG) == libtcnative - Win32 Debug - -# PROP BASE Use_MFC 0 -# PROP BASE Use_Debug_Libraries 1 -# PROP BASE Output_Dir Debug -# PROP BASE Intermediate_Dir Debug -# PROP BASE Target_Dir -# PROP Use_MFC 0 -# PROP Use_Debug_Libraries 1 -# PROP Output_Dir Debug -# PROP Intermediate_Dir Debug -# PROP Ignore_Export_Lib 0 -# PROP Target_Dir -# ADD BASE CPP /nologo /MDd /W3 /GX /Zi /Od /D WIN32 /D _DEBUG /D _WINDOWS /FD /c -# ADD CPP /nologo /MDd /W4 /GX /Zi /Od /I ./include /I ../apr/include /I ../apr/include/arch/win32 /I $(JAVA_HOME)/include /I $(JAVA_HOME)/include/win32 /I ../openssl/inc32 /D _DEBUG /D TCN_DECLARE_EXPORT /D WIN32 /D _WINDOWS /D WIN32_LEAN_AND_MEAN /D NO_IDEA /D NO_RC5 /D NO_MDC2 /D OPENSSL_NO_IDEA /D OPENSSL_NO_RC5 /D OPENSSL_NO_MDC2 /D HAVE_OPENSSL /D HAVE_SSL_SET_STATE=1 /FdDebug\libtcnative_src /FD /c -# ADD BASE MTL /nologo /D _DEBUG /mktyplib203 /o /win32 NUL -# ADD MTL /nologo /D _DEBUG /mktyplib203 /o /win32 NUL -# ADD BASE RSC /l 0x409 /d _DEBUG -# ADD RSC /l 0x409 /d _DEBUG -BSC32=bscmake.exe -# ADD BASE BSC32 /nologo -# ADD BSC32 /nologo -LINK32=link.exe -# ADD BASE LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib psapi.lib ole32.lib /nologo /base:0x6EE0 /subsystem:windows /dll /incremental:no /debug /machine:I386 -# ADD LINK32 kernel32.lib advapi32.lib ws2_32.lib mswsock.lib wldap32.lib psapi.lib ole32.lib libeay32.lib ssleay32.lib /nologo
cvs commit: jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni OS.java
wrowe 2005/05/12 12:29:47 Modified:jni/java/org/apache/tomcat/jni OS.java Address.java Log: More ^M polution fixed, whitespace changes only. Revision ChangesPath 1.5 +15 -15 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/OS.java Index: OS.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/OS.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- OS.java 18 Jan 2005 10:22:50 - 1.4 +++ OS.java 12 May 2005 19:29:47 - 1.5 @@ -73,23 +73,23 @@ * Gather system info. * PRE * On exit the inf array will be filled with: - * inf[0] - Physical RAM - * inf[1] - Available RAM - * inf[2] - Total page file (swap + Physical RAM) - * inf[3] - Free page file + * inf[0] - Physical RAM + * inf[1] - Available RAM + * inf[2] - Total page file (swap + Physical RAM) + * inf[3] - Free page file * inf[4] - Memory Load - * - * inf[5] - Idle Time in microseconds - * inf[6] - Kernel Time in microseconds + * + * inf[5] - Idle Time in microseconds + * inf[6] - Kernel Time in microseconds * inf[7] - User Time in microseconds - * - * inf[8] - Process creation time (apr_time_t) - * inf[9] - Process Kernel Time in microseconds + * + * inf[8] - Process creation time (apr_time_t) + * inf[9] - Process Kernel Time in microseconds * inf[10] - Process User Time in microseconds - * - * inf[11] - Current working set size. - * inf[12] - Peak working set size. - * inf[13] - Number of page faults. + * + * inf[11] - Current working set size. + * inf[12] - Peak working set size. + * inf[13] - Number of page faults. * /PRE * @param inf array that will be filled with system informations. */ 1.5 +8 -8 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Address.java Index: Address.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Address.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- Address.java 16 Apr 2005 16:45:13 - 1.4 +++ Address.java 12 May 2005 19:29:47 - 1.5 @@ -72,13 +72,13 @@ */ public static native String getnameinfo(long sa, int flags); -/** - * Return the IP address (in numeric address string format) in - * an APR socket address. APR will allocate storage for the IP address - * string from the pool of the apr_sockaddr_t. - * @param ss The socket address to reference. - * @return The IP address. - */ +/** + * Return the IP address (in numeric address string format) in + * an APR socket address. APR will allocate storage for the IP address + * string from the pool of the apr_sockaddr_t. + * @param ss The socket address to reference. + * @return The IP address. + */ public static native String getip(long sa); /** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/howto apache.xml
wrowe 2005/05/12 13:26:59 Modified:jk/native2 CHANGES.txt jk/xdocs/howto apache.xml Log: Last of the ^M bogosity I could uncover. Think that we are ready for a new tarball :) Revision ChangesPath 1.19 +6 -6 jakarta-tomcat-connectors/jk/native2/CHANGES.txt Index: CHANGES.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/CHANGES.txt,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- CHANGES.txt 12 May 2005 18:37:14 - 1.18 +++ CHANGES.txt 12 May 2005 20:26:59 - 1.19 @@ -1,12 +1,12 @@ JAKARTA TOMCAT CONNECTORS 2 (JK2) CHANGELOG:-*-text-*- Last modified at [$Date$] -AS OF NOVEMBER 15, 2004, JK2 IS NO LONGER SUPPORTED. ALL BUGS RELATED TO JK2 -WILL BE MARKED AS WONTFIX. IN ITS PLACE, SOME OF ITS FEATURES HAVE BEEN +AS OF NOVEMBER 15, 2004, JK2 IS NO LONGER SUPPORTED. ALL BUGS RELATED TO JK2 +WILL BE MARKED AS WONTFIX. IN ITS PLACE, SOME OF ITS FEATURES HAVE BEEN BACKPORTED TO JK1. MOST OF THOSE FEATURES WILL BE SEEN IN 1.2.7 AND LATER -VERSIONS. - -ANOTHER ALTERNATIVE IS THE AJP ADDITION TO MOD_PROXY WHICH WILL BE PART OF +VERSIONS. + +ANOTHER ALTERNATIVE IS THE AJP ADDITION TO MOD_PROXY WHICH WILL BE PART OF APACHE 2.1. Changes in JK2 HEAD: 1.8 +2 -2 jakarta-tomcat-connectors/jk/xdocs/howto/apache.xml Index: apache.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/howto/apache.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- apache.xml13 Apr 2005 12:17:07 - 1.7 +++ apache.xml12 May 2005 20:26:59 - 1.8 @@ -294,7 +294,7 @@ source # Load mod_jk module LoadModulejk_module libexec/mod_jk.so -# Declare the module for lt;IfModule directivegt; (remove this line on Apache 2.0.x) +# Declare the module for lt;IfModule directivegt; (remove this line on Apache 2.0.x) AddModule mod_jk.c # Where to find workers.properties JkWorkersFile /etc/httpd/conf/workers.properties - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.12 is broken and can not be released as stable
Ok, all of the file ^M fixes within jakarta-tomcat-connectors are finished. I added the /Oy- flag as there was unanimous concensus for -that- change. I left out the /Gs0 since legit concerns were raised. Think we are ready for a tarball :) -kb files which should not have been are now -ko. It's easier than diddling the ,v files directly, and I've never found the cvs admin magic to take away the -k flag altogether. You need a clean checkout to observe the actual tree, cvs up does a lousy job of picking up -k flag changes. Win32 images should be checked out on win32 cvs. Short of that, there is also some lovely magic in apr/build/lineends.pl that fixes only files it should touch. (This works on unix to take in win32 files, and on win32 to take in unix files.) Unix users can now feel free to modify .dsp files etc as needed, without playing ^M games. Truly hope it helps. Sorry for having to route through rowe-clan, it seems tomcat-dev hates my apache.org persona. (tomcat cvs did not complain, but it's forwarded onto tomcat-dev.) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Modifying Win32 default optimizations?
I'd like to modify the Win32 build projects (of mod_jk, and httpd 1.3/2.0/2.1-dev, along with apr); The /O2 optimization option is extremely agressive, unfortunately it produces less than ideal crash traceback information. That is due to the (implicit) /Oy flag, which omits respecible stack framing. I'd like to change this to /O2 /Oy- to disable this optimization; processing will be unmeasurably slower, but far more useful when crashes do occur. The /O2 optimization also simplifies the stack frame checking for many functions. The /Gs0 option would restore full frame checks, to ensure we don't overflow the stack in the processing of any function. With FirstBill's (wise) choice to reduce the size of our default stack frames within httpd, it seems wise to be extra diligent. However, MS's docs state that /O2 implies /Gs - and I can't determine if that is /Gs0 (implied) or some other behavior. Thoughts from someone with more experience playing in stack probes would be appreciated. All in all - comments? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modifying Win32 default optimizations?
At 08:46 AM 5/11/2005, Branko Čibej wrote: All in all - comments? How about moving away from MSVC 6 to (say) VC.Net 2003, while we're at it? It's time, to say the least. Not for 1.3 or 2.0 httpd - you lose some measure of binary compatibility. We can jump through hoops to continue to use the msvcrt.dll but it's suboptimal. To pick up msvcr70.dll will cause some measure of pain. I'm willing to consider moving to Visual C 7 for binary builds of httpd-2.1+ if enough of the community is behind it. For that matter, perhaps its time to drop Win9x support from httpd-2.1+ (?) If your thought is no - lots of people still use 9x - then also consider that lots of people are quite happy with their VC 5 or 6 and it just continues to work for them. Here's an example of the issue; http://mail.gnome.org/archives/dia-list/2003-March/msg00141.html Nothing stops YOU today from using VC7, in fact VisualStudio will gladly parse the .dsp files into .vcproc's, .dsw into .sln. The question, rather, is what clib and compiler to use to create the binary distributions - and right now, We obviously want users to be able to elect /GS compilation under VC7 for stack guard sentinels. If the open source community tends to push back on Microsoft's newest compilers, it's simply because their forced treadmill is the anathema of inclusiveness. At 10:45 AM 5/11/2005, Branko Čibej wrote: 99% of the work of moving from MSVC6 to any flavour of VC.Net is in converting the project files. So it doesn't matter if the target is 2003 or 2005. That would be 1% of the work. Visual Studio.NET does that work for you. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modifying Win32 default optimizations?
At 04:35 PM 5/11/2005, Branko Čibej wrote: William A. Rowe, Jr. wrote: If the open source community tends to push back on Microsoft's newest compilers, it's simply because their forced treadmill is the anathema of inclusiveness. That's what's happening right now with Subversion. The Python 2.4 distro is built with VS.NET (2003, I think). HTTPD is built with MSVC 6. Subversion tries to link with both. So right now, we're stuck with either providing only Python 2.3 bindings, or not being able to use an HTTPD from the apache.org installer... Yes - I see Python 2.3 / Mod Perl 5.8 / Apache 2.0 / APR 0.9 / etc all in the same 'generation' of code. Do you want the ASF to be a leader of this 'breakage' as the Python project was? This is why the push back. And I hope for Python 2.4 / Apache 2.2 / APR 2.0 / etc to all be of the next 'generation', finally adopting msvcr70. Seem rational? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modifying Win32 default optimizations?
At 08:29 PM 5/11/2005, Randy Kobes wrote: That sounds great, but one consideration from the point of view of Perl (eg, mod_perl) is that the dominant Win32 Perl binary, from ActiveState, uses VC 6 to compile, and they don't have any plans soon of changing that. But that might change by the next generation. There is yet another consideration which might kill this entire discussion. The beta VC++ 2005 Express includes everything one would want, nmake, cl, lib, link et al. It does not have msvcr70.lib in it's lib/ tree. It does have msvcrt.lib. In SDK\v2.0\Bin one also finds msvcr80.dll. Which means, it appears, that msvcr70.dll never 'arrived' and has been orphaned. Perhaps ActiveState took a better route with Perl than Python. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.12 is broken and can not be released as stable
At 04:33 AM 5/10/2005, Mladen Turk wrote: Interesting is that it was spotted only when the release was made, so this gives one reason more for making some sort of releases and binaries to attract more users to actually do the testing. Agreed that development releases (early and often) are a very good thing. They need the same 3 +1 votes (more + than -) but have a much lower barrier of entry. (Is it tar'red complete? Does it build? Do some basic regressions work?) We can retag and release 1.2.13, or just wait if something else will arise and have some vacation in the mean time :). I'd suggest 1) tag 1.2.13 with any bug fixes in the past week or two. Give me this evening to commit a small tweak to the Win32 .dsp project compile flags, which emit much more legible user.dmp crash analysis output. (I found this out over the weekend.) 2) let it ride - skip adding any new features till it shakes out, at least to 1.2. If someone wants to add some new stuff, make a CVS branch to develop it on, or fork 1.3 already depending on the desired patches. 3) wait for something else to arise, put together the docs on the newest features, and in, say, 3 weeks after 1.2.13 is announced, bless 1.2.14 as the next stable release. And 4) pull down 1.2.11 which was never released (according to your judgement) and 1.2.12 (which is broke, and obviously confuses users who were used to the odds-evens system of dev and stable tarballs.) If they are needed by the occasional user, archive.apache.org/dist/ is the place to look. What is the thought, is 1.2.10 stable? 1.2.8? Or 1.2.6? I'm partial to 1.2.8 myself. Bill will love this, for sure ;) Nope - I hoped 1.2.12 would pan out, I just wasn't planning to endorse it for another three weeks or so. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging 1.2.12
At 02:30 PM 5/9/2005, Jean-Jacques Clar wrote: Build and run on NetWare with apache 2.0.54. Woot! And thank you for the example, Jean-Jacques, of exactly why we need more than a few days before we declare 'stable' releases ;-) But I do think it's wonderful that the NetWare issues are gone. What about 1.3.33? What about 2.1-dev? What about other servers? And you mention it runs, but against which Tomcat, 5(.5)? I hope you see my point, there is an incredible set of combinations which are quite useful and legitimate in tomcat-connectors. I keep hearing the refrain Lets deprecate all this stuff I don't test. Rather than deprecate, what about simply allowing enough time for dust to settle, and reports to roll in. 3 +1's that all looks like it's good, and then let the community (with all their goofy combinations of OS's, connectors, and backends) chime in with complaints. [Yes - I mean complaints, few ever give us the good news when all is well :-] Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging 1.2.12
At 05:08 PM 5/9/2005, Jean-Jacques Clar wrote: I built and tried mod_jk against 2.0.52 and 2.1-dev. However, in these two cases it was not tested as for 2.0.54. Stress tests were done against Tomcat 4.1.30, validation against 4.1.31. For 1.3.33, I am sorry to admit that I did not build JK and is not currently planning to do it.I currently have access to these resources. What else do you want me to do? I will not and could never be able to cover this incredible set of combinations.Next time I will put more details in my report, but I was reporting a fact not more, not less.But from what I could do, 1.2.12 is good. Thank you Jean-Jacques - narrows down the scope of what I need to test. Of course the handful here will never test with any of the breadth of options available, it was my point :) I'm in a good position to have my staff beat on jk .12 / Apache 1.3 tomcat 4.1 and 5.0. I'll focus on that since the Apache2 side seems well covered. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN/VOTE] JK 1.2.12 Released
At 11:23 AM 5/7/2005, Mladen Turk wrote: Hi, JK 1.2.12 has been released. Question; How? I don't see a vote. It has been tagged and packaged. It is not released unless there is a vote on the PMC I missed [and shouldn't be discussed there anyways.] I would also like to make a stability VOTE at once Certainly; but it's not yours to have released it in the first place. I know this isn't the first time I've had to remind you; but I'm doing so in public only because it's -critical- that all understand the ASF regulation here. There must be 3 +1's, more +1's than -1's in order for an arbitrary tarball to be Released. In the interim, this tree is The Release Manager's (Mladen Turk's) candidate. It is NOT a release. Please, do not let this occur again. If I missed a vote due to connectivity issues; please, pardon the reminder of this policy. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN/VOTE] JK 1.2.12 Released
At 10:37 PM 5/7/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: It is NOT a release. Sure it is not. That's why there is a VOTE inside, and that's why it was posted only on the dev list. Perhaps I should subject that email as: '1.2.12 tarballs available for testing'. Yes that would have been clearer - let's use that language in the future. We are speaking about that for more then a month. There was a stability vote for 1.2.11 and passed, but was not released even enough votes collected, because of bug in wc_close, manifesting in multi vhost scenarios. Ack. Although in theory it was 'released', I don't see any reason the RM (release manager) has to honor the vote to release - if they think there is a fatal flaw. If someone disagrees with the RM they are welcome to serve as RM and roll a release, themself (as the RM.) That said; http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/ sure makes it appear that 1.2.11 was a released version. So instead just fixing that and re-releasing that should be done, there was a week left for any other findings. Please, do not let this occur again. If I missed a vote due to connectivity issues; please, pardon the reminder of this policy. I really don't see what is your problem with releasing JK. Not an issue with releasing (future tense), you totally missed the point. The issue is PROCEDURE. Post released versions. Don't announce releases before a vote. Your email *stated* 1.2.12 is released (present tense.) http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/ states that 1.2.12 is released (development version). So it appears to me, casual user, that 1.2.12 is released. We need three +1's here - and I'm sure you will get them. But I'm objecting to placing carts before horses. Your update to that /dist/ page makes it appear it is done, while it is not. One thought; httpd uses the http://httpd.apache.org/dev/dist/ URL to collect candidates; it makes is a little clearer which tarballs are candidates, and which are actually released. Perhaps we adopt something similar in jakarta-tomcat? You can or can not file your vote for this release. Ack - I look forward to testing - and an informed decision. (I'm finding CHANGES is rather limited, so trawling through the commit logs has taken longer than I expected ;-) I asked for a few weeks that would allow users to adopt 1.2.11, test it, report back from the real-world, and have a really solid release. The last couple releases were scuttled quick due to new bugs, I'd love to see that cycle end. So would you, I know that. Further more you can even be a RM for the next one. I'm really sick an tired of doing that for the last year. A thankless task at that. If I can help back you up with Win32 binaries, I'm happy to offer as my schedule allows. This last three months I've had 9 day weeks of work, which don't fit well into 7 day calendars :) I hope this changes in the next month. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging 1.2.12
At 07:31 AM 5/6/2005, 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? Yes, one. What's the rush? One week is not enough time for folks to really stress 1.2.11, and this sure looks to me, from the pace of supposedly stable releases, as though mod_jk has become much less trustworthy, and much more suspect, for a stable production install. Why not let several weeks worth of bugs shake out, before blessing a 'stable' mod_jk that can hang on, a while? FWIW I haven't yet kicked 1.2.11 at my QA staff but I'm looking forward to validating HP/UX in this next week. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't compile jk nativ connector under Suse 9.3
At 11:02 PM 4/26/2005, Peter Rossbach wrote: here the configure output ... Thank you; but the other half of my question... make[1]: Entering directory `/home/peter/develop/tomcat/jakarta-tomcat-connectors/jk/native/common' /bin/sh /home/peter/server/apache2/build/libtool --silent --mode=compile gcc -I/home/peter/server/apache2/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/home/peter/server/httpd-2.0.54/srclib/apr/include -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /usr/java/jdk1.5.0_02/include -I /usr/java/jdk1.5.0_02/include/ -c jk_connect.c jk_connect.c: In function `jk_shutdown_socket': jk_connect.c:485: error: `SD_SEND' undeclared (first use in this function) jk_connect.c:485: error: (Each undeclared identifier is reported only once jk_connect.c:485: error: for each function it appears in.) William A. Rowe, Jr. schrieb: grep -r SD_SEND /usr/include/* grep -r SD_SEND /usr/local/include/* ? Tell us where it's hidden and it's more likely we can come up with an appropriate patch. You seem to presume I run your version of suse here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't compile jk nativ connector under Suse 9.3
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. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/nt_service jk_nt_service.c
At 02:46 AM 4/27/2005, [EMAIL PROTECTED] wrote:
mturk 2005/04/27 00:46:22
-hEventSource = RegisterEventSource(NULL, Jakrta - Tomcat);
+hEventSource = RegisterEventSource(NULL, Jakarta - Tomcat);
-sprintf(szMsg, %s error: %d, Jakrta - Tomcat, dwErr);
+sprintf(szMsg, %s error: %d, Jakarta - Tomcat, dwErr);
Mladen, we are in the process of graduating. If this is being
tweaked, why not Apache Tomcat {descriptive} Event?
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Releasing 1.2.11/1.2.12
At 06:38 AM 4/25/2005, Mladen Turk wrote: Peter Rossbach wrote: that is a very shot time period for testing. Well, some of the things are really critical, so that's the reason. I think that 1.2.8/1.2.9 proved that haste creates this churn. Once 1.2.11 is ready, isn't it sufficient to point users at that test version for 2 - 4 weeks, until it truly settles out? Nothing but critical/proven bug fixes between .11 and .12? If they couldn't get the code I'd agree with the fast turnaround, but once 1.2.11 exists, the point is, they can. We've burned the users with deprecating mod_jk2. Generating churn in mod_jk (as opposed to solid, stable releases) will only continue to lessen users' faith in jk as a production solution. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Releasing 1.2.11/1.2.12
At 06:01 AM 4/26/2005, Mladen Turk wrote: I wish to make the 1.2.11 as a bugfix release, so where's the churn in that? Nothing, 1.2.11 is wonderful. You proposed releasing 1.2.12/stable a few days afterwards. I don't know if calling 1.2.12/stable in a few days is really such a hot idea. 1.2.4, 1.2.6 worked for most users for a very long time, and with all the new features/development on 1.2, it would be good to see all this effort solidify before being blessed 'stable'. Certainly give the testing community time to stress this. In the case of httpd, the 3-day rule came from www.apache.org itself, it's possible to shove a huge volume of real world traffic at our own web server over three days. In the case of jk, our testers seem to be asking for more time to do a thorough job of testing. 1.2.10 release had a few latent hiccups, so my question is, why the rush from 1.2.11 to 1.2.12? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Releasing 1.2.11/1.2.12
At 09:35 AM 4/26/2005, Mladen Turk wrote: Well, I agree with you that we create a new branch. I wish to deprecate ajp12, jni and ajp14 connectors, as well as isapi, domino and ntservice servers. Reasons: ... ntservice: unmaintained for years. I've used ntservice for years, never had an issue, happy to maintain it. Can you point to a specific issue? The effort might better be spent after conversion to svn, since you attain the ability to have versioned rmdir, without hacking up the raw CVS tree and breaking historical checkouts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Releasing 1.2.11/1.2.12
At 09:48 AM 4/26/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote The effort might better be spent after conversion to svn, since you attain the ability to have versioned rmdir, without hacking up the raw CVS tree and breaking historical checkouts. Hmm, I would like to leave the CVS until the Tomcat switches to the SVN. But of course it's up to the community to decide. CVS supports branches too IIRC? I agree it would be better to see all of Tomcat make the switch at once; and I'm not suggesting this is that moment. But no, CVS doesn't support versioned directory trees. You do have -p(rune) on checkout and export, but svn supports actually removing a directory entity as of an explicit revision. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't compile jk nativ connector under Suse 9.3
grep -r SD_SEND /usr/include/* grep -r SD_SEND /usr/local/include/* ? Tell us where it's hidden and it's more likely we can come up with an appropriate patch. Any ./configure output would also be helpful. At 01:01 PM 4/26/2005, Peter Rossbach wrote: I have a jk native compilation problem at suse 9.3 with the current CVS HEAD. Can't compile jk_connect.c jk_connect.c: In function 'jk_shutdown_socket' : jk_connect.c:485: error 'SD_SEND' undeclared (first use in this function) jk_connect.c:485: error (Each unde ... How can I find the missing SD_SEND declaration? Peter - 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.10 - return code when Tomcat not running
At 02:04 PM 4/18/2005, Mladen Turk wrote: This is bug, and will be fixed. It should return SERVER_BUSY (503) if can not connect to Tomcat. You can try to use the load balancer with the single worker, and it should work like explained. It depends; Connection refused == 503 HTTP_SERVICE_UNAVAILABLE Connection timeout == 504 HTTP_GATEWAY_TIME_OUT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OT: Re: Error
Wow, social engineering on a whole new level. An enigma wrapped in a puzzle, wrapped in a riddle. At 01:26 PM 4/13/2005, [EMAIL PROTECTED] wrote: Content-Type: text/plain; name=warning1.txt Content-Disposition: inline; filename=warning1.txt Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) During a routine email scan at UTC, a file attached to this message was deleted per UTC Security Policy. UTC does not allow emailing several file types due to their potential to transmit viruses. An attachment named sjufp.scr was removed from this message. The body text of the message that included the deleted attachment can be found in the .txt file below. It is safe to open this file. If you believe this message is not business related simply delete it. If the message is business related and you require the file that was deleted, please contact the sender/nand arrange an alternate means of receiving it. The recommended method is to/nhave the sender zip the file before sending it. The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment. - 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: [ANN] JK 1.2.10 Released
At 03:34 AM 3/31/2005, Henri Gomez wrote: 1.2.10, I awaited a 1.2.9 final release. We just add a 1.2.9 beta Kurt and Henri voted yes. I'd presume Mladen's vote was +1 too. Glenn didn't vote yes, he reserved his vote for stress testing. Mladen, could you please slow down long enough to give folks some reasonable time to react to your candidates? (Was 40 hours from tarball to announce.) Some reasonable amount of time, say 72 hours, to give committers time to perform some satisfactory testing. At the least, give folks a timetable to expect :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JK 1.2.9 as stable
At 04:55 AM 3/29/2005, Mladen Turk wrote: Hi, There has been some improvements since 1.2.9 beta version, so I suggest that you test the latest source code and binaries. I was under the impression that it was evens-stable, odds-devel. So is this a vote for 1.2.10? In any case I'll check win32 out tomorrow night. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CVS issue?
cvs up ? native/apache-1.3/Release ? native/apache-1.3/mod_jk.plg cvs update: nothing known about xdocs/common/ajpv13.xml did someone hork xdocs/common/ajpv13.xml in the cvs repository, rather than cvs remove it? Bill - 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
At 02:09 PM 3/14/2005, Jim Jagielski wrote: Henri Gomez wrote: +1 for both of all. Should I understand they will works more on HTTPD related stuff and of course JK ?-) Yep, that's my intent :) Yes - I'm also interested in the AJP 14 implementation from the p.o.v. of ASP.NET backends. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache 2.1.3 may be beta...
At 01:01 PM 3/7/2005, Mladen Turk wrote: Bill Barker wrote: It seems Apache 2.1.3 may became beta, what about the state of ajp code present in CVS ? Well, Gump is still failing to build mod_jk against Apache 2.1.x-dev ;-). Yep, look at the thread at httpd-dev about making 2.1.3 as beta. First, WIN32 build can not be made because APR build is broken, so you'll need to use the version from CVS. For what it's worth, there were issues in both httpd and apr, and cvs HEAD of both should solve them. Hopefully both will be picked up in a 2.1.4 before it goes beta. I've seen nothing at [EMAIL PROTECTED] about gump build failures, it would be nice if folks would forward details about problems that the community is unaware of. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configure list to suitably handle return receipts
At 02:07 PM 2/22/2005, Rahul P Akolkar wrote: My understanding about Delivery Status Notification (DSN) is that if the sender of the original email requests return receipts, then a DSN compliant mail server (such as the one I use), will do the expected thing and provide that notification. But you are ignoring; Precedence: bulk present on all list mails, which should supercede any DSN request. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release policy - was: JK 1.2.9-dev test results
At 04:43 AM 2/19/2005, Remy Maucherat wrote: William A. Rowe, Jr. wrote: It definately seems like j-t-c should be a first candidate for svn conversion. The other jakarta-tomcat repositories are considerabily more complex. But it would be good to have line endings straightened out beforehand. I find svn quite confusing to work with. Especially, the possibility of browsing a revision tree seems unusable (due to the fact that revisions are global, tortoise cannot make a graph in less than 4 hours :( ), and it's an important tool for me. Unfortunately, this means I'll have to veto a move to svn for the time being, until I figure out how to use it. Sadly, I agree with you - my biggest hiccup is the mess that moving from cvs-svn creates if you want to see annotated source files - knowing a line changed in 1.99.3.1 is hugely important to me. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing the Tomcat5 WIN32 service runner
At 06:31 AM 2/21/2005, Mladen Turk wrote: Unlike any other java or java/jni implementations it does not tries to make a java as a service, but rather makes a batch (.bat) file as a service. IIUC, that means; 1. service signals (shutdown etc) aren't recognized by cmd (sh for you linux observers) in any useful manner. 2. it invokes cmd, which invokes the apps. You are stuck with an instance of cmd for the lifetime of the process. Seems like a big leap backwards, IMHO. If anything, a psuedo-sh script interpreter which picked up the envvar assignments (the only thing you want to move to .cmd for, anyways) makes more sense than this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release policy - was: JK 1.2.9-dev test results
At 12:56 PM 2/17/2005, Rainer Jung wrote:
Hi,
first: thanks a lot to Mladen for adding all the beautiful features [and
removing CRLF :) ]. Big leap forward!
Here's a list of all mixed up line endings currently
in jakarta-tomcat-connectors/jk/ ...
The Mismatch'ed files all represent files with mixed line endings
(some cr/lf, some cr/cr/lf.)
Fixed lines ./native/apache-1.3/mod_jk.dsp
Fixed lines ./native/apache-2.0/bldjk.qclsrc
Fixed lines ./native/apache-2.0/mod_jk.dsp
Fixed lines ./native/common/portable.h
Fixed lines ./native/domino/dsapi.dsp
Fixed lines ./native/iis/isapi.dsp
Fixed lines ./native/iis/isapi_redirect.reg
Fixed lines ./native/iis/installer/isapi-redirector-win32-msi.ism
Fixed lines ./native/iis/installer/License.rtf
Fixed lines ./native/isapi/tomcat_redirector.reg
Fixed lines ./native/netscape/nsapi.dsp
Mismatch in ./native2/CHANGES.txt:2 expected 1
Mismatch in ./native2/README.txt:2 expected 1
Mismatch in ./native2/STATUS.txt:2 expected 1
Fixed lines ./support/jk_exec.m4
Mismatch in ./xdocs/changelog.xml:2 expected 1
Mismatch in ./xdocs/index.xml:2 expected 1
Mismatch in ./xdocs/style.css:2 expected 1
Mismatch in ./xdocs/config/iis.xml:2 expected 1
Mismatch in ./xdocs/config/workers.xml:2 expected 1
Mismatch in ./xdocs/install/apache1.xml:2 expected 1
Mismatch in ./xdocs/install/iis.xml:2 expected 1
Mismatch in ./xdocs/news/20041100.xml:2 expected 1
Attached is my current lineendings script, if it's helpful.
Bill
#!/usr/local/bin/perl
#
# Heuristically converts line endings to the current OS's preferred format
#
# All existing line endings must be identical (e.g. lf's only, or even
# the accedental cr.cr.lf sequence.) If some lines end lf, and others as
# cr.lf, the file is presumed binary. If the cr character appears anywhere
# except prefixed to an lf, the file is presumed binary. If there is no
# change in the resulting file size, or the file is binary, the conversion
# is discarded.
#
# Todo: Handle NULL stdin characters gracefully.
#
use IO::File;
use File::Find;
# The ignore list is '-' seperated, with this leading hyphen and
# trailing hyphens in ever concatinated list below.
$ignore = -;
# Image formats
$ignore .= gif-jpg-jpeg-png-ico-bmp-;
# Archive formats
$ignore .= tar-gz-z-zip-jar-war-;
# Many document formats
$ignore .= eps-psd-pdf-ai-;
# Some encodings
$ignore .= ucs2-ucs4-;
# Some binary objects
$ignore .= class-so-dll-exe-obj-;
# Some build env files in NW/Win32
$ignore .= mcp-xdc-ncb-opt-pdb-ilk-sbr-;
$preservedate = 1;
$forceending = 0;
$givenpaths = 0;
$notnative = 0;
while (defined @ARGV[0]) {
if (@ARGV[0] eq '--touch') {
$preservedate = 0;
}
elsif (@ARGV[0] eq '--nocr') {
$notnative = -1;
}
elsif (@ARGV[0] eq '--cr') {
$notnative = 1;
}
elsif (@ARGV[0] eq '--force') {
$forceending = 1;
}
elsif (@ARGV[0] eq '--FORCE') {
$forceending = 2;
}
elsif (@ARGV[0] =~ m/^-/) {
die What is . @ARGV[0] . supposed to mean?\n\n
. Syntax:\t$0 [option()s] [path(s)]\n\n . 'OUTCH'
Where: paths specifies the top level directory to convert (default of '.')
options are;
--cr keep/add one ^M
--nocr remove ^M's
--touch the datestamp (default: keeps date/attribs)
--force mismatched corrections (unbalanced ^M's)
--FORCE all files regardless of file name!
OUTCH
}
else {
find(\totxt, @ARGV[0]);
print scanned . @ARGV[0] . \n;
$givenpaths = 1;
}
shift @ARGV;
}
if (!$givenpaths) {
find(\totxt, '.');
print did .\n;
}
sub totxt {
$oname = $_;
$tname = '.#' . $_;
if (!-f) {
return;
}
@exts = split /\./;
if ($forceending 2) {
while ($#exts ($ext = pop(@exts))) {
if ($ignore =~ m|-$ext-|i) {
return;
}
}
}
if (($File::Find::dir . /) =~ m|/.svn/|i) {
return;
}
if (($File::Find::dir . /) =~ m|/CVS/|i) {
return;
}
@ostat = stat($oname);
$srcfl = new IO::File $oname, r or die;
$dstfl = new IO::File $tname, w or die;
binmode $srcfl;
if ($notnative) {
binmode $dstfl;
}
undef $t;
while ($srcfl) {
if (s/(\r*)\n$/\n/) {
$n = length $1;
if (!defined $t) {
$t = $n;
}
if (!$forceending (($n != $t) || m/\r/)) {
print Mismatch in .$File::Find::dir./.$oname. : .$n.
expected .$t. \n;
undef $t;
last;
}
elsif ($notnative 0) {
s/\n$/\r\n/;
}
}
print $dstfl $_;
}
if (defined $t (tell $srcfl == tell $dstfl)) {
Re: mod_jk release policy - was: JK 1.2.9-dev test results
It definately seems like j-t-c should be a first candidate for svn conversion. The other jakarta-tomcat repositories are considerabily more complex. But it would be good to have line endings straightened out beforehand. This checkout was with the cvs Win32 client. It seems, from all the troubles you have, that you are using the cygwin cvs client? The cygwin client checks out Unix text because it is a unix shell, and shouldn't be expected to check out with Win32 semantics (that combo would be an oxymoron.) One nice advantage of SVN is that you can force an LF checkout on win32, or CRLF checkout on unix, if that is what you desire. Either is predicated on storing text files as (of all things) text files - which the files I mentioned were not conformant. Here are the results from checking out under unix (FYI - you can force win32 or unix semantics with --cr or --nocr using my lineends.pl script, and --force will ignore the mixed up line endings when the file contains a mix of LF, CR/LF and CR/CR/LF line endings); Fixed lines ./jni/native/libtcnative.dsp Fixed lines ./jni/native/libtcnative.dsw Fixed lines ./jni/native/tcnative.dsp Mismatch in ./jni/native/src/pool.c:1 expected 0 Mismatch in ./jni/native/src/shm.c:1 expected 0 Fixed lines ./jni/native/src/ssl.c Fixed lines ./jni/native/build/win32ver.awk Mismatch in ./jni/java/org/apache/tomcat/jni/OS.java:1 expected 0 Mismatch in ./jk/xdocs/changelog.xml:1 expected 0 Mismatch in ./jk/xdocs/index.xml:1 expected 0 Mismatch in ./jk/xdocs/style.css:1 expected 0 Mismatch in ./jk/xdocs/news/20041100.xml:1 expected 0 Mismatch in ./jk/xdocs/install/apache1.xml:1 expected 0 Mismatch in ./jk/xdocs/install/iis.xml:1 expected 0 Mismatch in ./jk/xdocs/config/iis.xml:1 expected 0 Mismatch in ./jk/xdocs/config/workers.xml:1 expected 0 Mismatch in ./jk/native2/CHANGES.txt:1 expected 0 Mismatch in ./jk/native2/README.txt:1 expected 0 Mismatch in ./jk/native2/STATUS.txt:1 expected 0 Fixed lines ./jk/native2/server/isapi/install4iis.js Fixed lines ./jk/native2/server/apache2/bldjk2.qclsrc Fixed lines ./jk/native/nt_service/nt_service.dsp Fixed lines ./jk/native/netscape/nsapi.dsp Fixed lines ./jk/native/isapi/tomcat_redirector.reg Fixed lines ./jk/native/iis/isapi.dsp Fixed lines ./jk/native/iis/isapi_redirect.reg Fixed lines ./jk/native/iis/installer/isapi-redirector-win32-msi.ism Fixed lines ./jk/native/domino/dsapi.dsp Fixed lines ./jk/native/apache-2.0/mod_jk.dsp Fixed lines ./jk/native/apache-1.3/mod_jk.dsp Fixed lines ./ajp/ajplib/test/test.sln Fixed lines ./ajp/ajplib/test/testajp.vcproj (Just to reclarify, 0 expecting 1 means the module first encountered 0 CR's - just an LF, and deeper in the file encountered CR/LF - one CR found.) At 02:52 PM 2/18/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: Here's a list of all mixed up line endings currently in jakarta-tomcat-connectors/jk/ ... The Mismatch'ed files all represent files with mixed line endings (some cr/lf, some cr/cr/lf.) Two things. See no CRLFs for any .h or .c inisde j-t-c. Also Bill, will you be OK and ready to push j-t-c to svn? Regards, Mladen. Fixed lines ./native/apache-1.3/mod_jk.dsp Fixed lines ./native/apache-2.0/bldjk.qclsrc Fixed lines ./native/apache-2.0/mod_jk.dsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] jk 1.2.8 Build failure on linux (1 liner)
Actually, I've noticed another build problem. The declaration of 'test' on HP/UX is actually a posix sh wrapper to the built in sh - which invokes test [EMAIL PROTECTED] Sadly this means that empty arguments to test are dropped, such that test -z results in an 'insufficient arguments' error to the test utility. This causes us to fall into the Apache2 defines path within the apxs test logic which makes building the 1.3 mod_jk quite difficult on a stock HP/UX box. I'm bringing this up instead of simply offering a patch, because I want to determine; should we use Apache 1.3's apxs to link, or continue to abuse libtool for Apache 1.3 modules? I can offer up either patch later this week. Bill At 07:58 PM 1/27/2005, William A. Rowe, Jr. wrote: JFC - you missed something. I'm not speaking of Apache 2.0 ... this is in r.e. Apache 1.3 (native/jk/apache13) :) Bill At 05:38 AM 1/20/2005, jean-frederic clere wrote: William A. Rowe, Jr. wrote: I'm finding that @top_builddir@ isn't resolved when I run ./buildconf / ./configure against apache1.3 apxs, so the libtool isn't resolved. The fix is trivial, use the same fixed top_builddir=.. as all the other /native/ directories used. -0: It would be better to set @top_builddir@ correctly in configure. It still confuses me why, when apxs defined the correct cc / ld for apache 1.3, the apache1.3 module is building with libtool (which might be the wrong compiler, linker, etc.) I'll investigate a complete patch later, but this little one should solve the issue for some. Don't remove libtool otherwise I will have problems: +++ [EMAIL PROTECTED]:/opt/SMAWoIS/apache13 /opt/apache21/sbin/apxs -q LIBTOOL /bin/sh /opt/apache21/build/libtool --silent [EMAIL PROTECTED]:/opt/SMAWoIS/apache13 file /opt/apache21/build/libtool /opt/apache21/build/libtool: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped +++ Attached. 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] - 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]
Bad example (harmful to HP/UX)
Attached is a simple patch to correct the jk_apxs detection
macros. In every case we search for .so (.dylib) we should
also consider the .sl files our HP/UX friends rely on.
BillIndex: jk/support/jk_apxs.m4
===
RCS file:
/var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/support/jk_apxs.m4,v
retrieving revision 1.16
diff -u -r1.16 jk_apxs.m4
--- jk/support/jk_apxs.m4 1 Apr 2004 07:08:20 - 1.16
+++ jk/support/jk_apxs.m4 27 Jan 2005 23:27:46 -
@@ -101,11 +101,17 @@
APR_UTIL_INCDIR=-I`${APXS$1} -q APU_INCLUDEDIR`
APACHE2_LIBDIR=`${APXS$1} -q LIBDIR`
LIBTOOL=`${APXS$1} -q LIBTOOL`
- if ${TEST} -f ${APACHE2_LIBDIR}/libapr-1.so -o -f
${APACHE2_LIBDIR}/libapr-1.dylib; then
+ if ${TEST} -f ${APACHE2_LIBDIR}/libapr-1.so \
+ -o -f ${APACHE2_LIBDIR}/libapr-1.sl \
+ -o -f ${APACHE2_LIBDIR}/libapr-1.dylib; then
APR_LIBS=-L${APACHE2_LIBDIR} -lapr-1
- elif ${TEST} -f ${APACHE2_LIBDIR}/libapr-0.so -o -f
${APACHE2_LIBDIR}/libapr-0.dylib; then
+ elif ${TEST} -f ${APACHE2_LIBDIR}/libapr-0.so \
+-o -f ${APACHE2_LIBDIR}/libapr-0.sl \
+-o -f ${APACHE2_LIBDIR}/libapr-0.dylib; then
APR_LIBS=-L${APACHE2_LIBDIR} -lapr-0
- elif ${TEST} -f ${APACHE2_LIBDIR}/libapr.so -o -f
${APACHE2_LIBDIR}/libapr.dylib; then
+ elif ${TEST} -f ${APACHE2_LIBDIR}/libapr.so \
+-o -f ${APACHE2_LIBDIR}/libapr.sl \
+-o -f ${APACHE2_LIBDIR}/libapr.dylib; then
APR_LIBS=-L${APACHE2_LIBDIR} -lapr
else
AC_MSG_ERROR(can't locate libapr)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] jk 1.2.8 Build failure on linux (1 liner)
JFC - you missed something. I'm not speaking of Apache 2.0 ... this is in r.e. Apache 1.3 (native/jk/apache13) :) Bill At 05:38 AM 1/20/2005, jean-frederic clere wrote: William A. Rowe, Jr. wrote: I'm finding that @top_builddir@ isn't resolved when I run ./buildconf / ./configure against apache1.3 apxs, so the libtool isn't resolved. The fix is trivial, use the same fixed top_builddir=.. as all the other /native/ directories used. -0: It would be better to set @top_builddir@ correctly in configure. It still confuses me why, when apxs defined the correct cc / ld for apache 1.3, the apache1.3 module is building with libtool (which might be the wrong compiler, linker, etc.) I'll investigate a complete patch later, but this little one should solve the issue for some. Don't remove libtool otherwise I will have problems: +++ [EMAIL PROTECTED]:/opt/SMAWoIS/apache13 /opt/apache21/sbin/apxs -q LIBTOOL /bin/sh /opt/apache21/build/libtool --silent [EMAIL PROTECTED]:/opt/SMAWoIS/apache13 file /opt/apache21/build/libtool /opt/apache21/build/libtool: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped +++ Attached. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[patch] jk 1.2.8 Build failure on linux (1 liner)
I'm finding that @top_builddir@ isn't resolved when I
run ./buildconf / ./configure against apache1.3 apxs,
so the libtool isn't resolved. The fix is trivial,
use the same fixed top_builddir=.. as all the other
/native/ directories used.
It still confuses me why, when apxs defined the correct
cc / ld for apache 1.3, the apache1.3 module is building
with libtool (which might be the wrong compiler, linker,
etc.) I'll investigate a complete patch later, but this
little one should solve the issue for some.
Attached.
Bill--- jk/native/apache-1.3/Makefile.in13 Jul 2004 13:31:19 - 1.10
+++ jk/native/apache-1.3/Makefile.in19 Jan 2005 04:36:33 -
@@ -3,7 +3,6 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
@@ -15,6 +14,8 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+
+top_builddir=..
OEXT=.lo
libexecdir=${APACHE_DIR}/libexec
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk connector error on post.
Hi Ryan, fancy meeting up here :) You don't mention, so I'll confirm - you are using mod_jk 1.2.8 (brand new release)? This sure sounds like the (rather obscure) issues with re-piping body content, and taking a simple guess, if you drop back and force http/1.0 (eliminate chunking) the issue goes away? Bill At 06:55 PM 1/17/2005, Ryan Bloom wrote: I am trying to get Apache 1.3 and Tomcat 5.0.27 working together. My site basically works, but any POST request causes the following error with a hex dump: Jan 17, 2005 3:19:23 PM org.apache.jk.common.HandlerRequest invoke SEVERE: Error decoding request java.io.IOException at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:252) at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:500) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:567) I have been unable to get Tomcat to give me more log messages. The web pages are very clear that jk2 is no longer in development, so I really don't want to go to jk2. but I am at a loss as to where to go from here. Can anybody suggest a possible solution? Thanks, Ryan - 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 connector error on post.
At 06:50 PM 1/18/2005, Ryan Bloom wrote: Actually, both 1.2.6 and 1.2.8 of mod_jk. What do you mean re-piping body content? I haven't forced http/1.0 yet, I was about to trace through Apache to find the problem. My initial investigation looks like the problem is in Apache somewhere, looks like ap_setup_client_block/ap_should_client_block. I'm sorry - totally missed the Apache 1.3 bit in your first post (I was thinking 2.0 filtering issues.) This also sort of eliminates chunking as the issue. Have some of my own efforts in Apache 1.3 at the moment, if I see anything I'll follow up again. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
org.apache.apr... ??? If this is private, and you've suggested it should be, don't you mean org.apache.jakarta.apr... ? Bill At 04:25 AM 1/13/2005, Mladen Turk wrote: Hi all, You can find the sources at: http://www.apache.org/~mturk/ File is: http://www.apache.org/~mturk/apr-java.tar.gz My intention is to put that inside: jakarta-tomcat-connectors/apr-java Although OtherBill thinks this is not a proper place to put that code, IMO until we have a generic infrastructure inside APR for OO languages glue code it can be placed here thought. How to build the library: WIN32: 1. You will need system environment variable JAVA_HOME that points to J2SDK installation path 2. Create directory of your choice and unpack apr-1.0.1.tar.gz in directory apr. 3. Unpack apr-java.tar.gz It should look like: some_path\apr some_path\apr-java 4. Build APR 5. Build APR-JAVA 6. cd java\org\apache\apr\jni 7. javac *.java 8. copy libapr-1.dll to java directory 9. copy libaprjava-1.dll to java directory 10. cd java 11. java org.apache.apr.jni.Test UNIX: 1. export JAVA_HOME=/path/to/the/java 2. mkdir work 3. cd work 4. tar zxf /path/to/apr-1.0.1.tar.gz 5. tar zxf /path/to/apr-java.tar.gz Building APR 7. cd apr-1.0.1 8. ./configure 9. make 10. make install 11. cd ../apr-java 12. ./buildconf --with-apr=../apr-1.0.1 13. ./configure --with-apr=../apr-1.0.1 or ./configure --with-apr=/usr/local/apr 14. make 15. make install 16. export LD_LIBRARY_PATH=/usr/local/apr/lib 17. cd java 18. $JAVA_HOME/bin/javac org/apache/apr/jni/*.java 19. $JAVA_HOME/bin/java org.apache.apr.jni.Test That's it. 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: [APR-JAVA] cvs upload
At 01:56 PM 1/13/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: org.apache.apr... ??? If this is private, and you've suggested it should be, don't you mean org.apache.jakarta.apr... ? He he :) I didn't said it should be private to J-T-C nor Jakarta. But the fact is that we don't have OO languages infrastructure for APR glue code. Seems to me that we'll need to go through incubation to create self standing apr-java project, or something like apr-oo/java. Self standing? If apr is borked (and the oo-dev'ers prove it) do you want another layer in the middle? This probably should be closely paired to apr to ensure communications and direction. Having them both under the same pmc ensures that the apr project doesn't go off on some weird tangent that interferes with oo implementations (not that I expect this would happen.) If you think we can make something like that in a reasonable amount of time, count me in. Happy to encourage it and I'll present it (with myself as a list moderator) to the apr project, and invite our modperl friends along with John Sterling and others who have created C++ wrappers. In other case I can rename the package to whatever name desired if it breaks some policy or something like. This sort of surprises me coming from an ASF java developer. I seriously doubt this team would find it amusing to discover org.apache.catalina namespaces populating an xml project's code. -1 on appropriating another ASF project's namespace (the same -1 I should have offered to forking proxy.) +/-0 if you want to build on org.apache.jk.apr namespace. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
At 01:25 AM 1/14/2005, Mladen Turk wrote: Costin Manolache wrote: To be honest, I don't like where this is going. I think access to native functionality for tomcat is great - and starting with functionality provided by apr is ok. But there is a lot outside apr, and if this becomes 'apr - java interface', it won't be easy to add. I agree with you. After all, the main focus is Tomcat support, as APR's main focus is Httpd support. Outch! Hope that isn't the worldwide impression; http://apr.apache.org/projects.html Other portability-related issues are also welcomed, discussed and oftentimes adopted! For example - multicast is fairly useless to http: scheme, but development of multicast is lively and progressing well, and is subject to tcp/ip implementation quirks and deviations. Yes it sprouted from httpd's portability needs, but work continues apace and it's been a -long- time since I heard the refrain We don't need to do that, it's not required by httpd. That train of thought gets slapped down fast :) However, apr isn't a dumping ground. If the concern isn't really portability, but more akin to library wrappers and so on, those items end up in the apr-util (dumping ground) of nice-to-have sorts of features, or sometimes dismissed out of hand. One of the goals is to add openssl support, as well as witting Servlet API four using by legacy applications (like module interface for httpd). Perhaps my posts led to wrong presumption that this is only JNI wrapper over APR library. Probably my confusion. So maybe it would be better to rename it to org.apache.tomcat.jni or something, keep the apr stuff as 'tomcat interface with apr' ( with a comment that when/if apr does have an official binding - we can switch), and keep it open for the other non-apr stuff that may be interesting. Sure, org.apache.tomcat.jni would be fine, and even better reflect the purpose of the package. Clearly, your interface will be broader than apr. When you do encounter the need for abstracting apr specifically, I do hope you consider doing this in a concerted effort. A reply to my post on [EMAIL PROTECTED], that an oo-dev abstraction effort is worthwhile, wanted, or you want to participate in, would be most appreciated. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [INTRODUCE] apr-java
At 12:03 PM 1/11/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: Silly Question - doesn't this proposal fit better in the commons project than Tomcat? Perhaps, but the guys that are interested in both c and Java live inside J-T-C :). Actually, the converse is true - tomcat-dev is modestly high traffic high number of subscribers. The interest in this nitch is probably much lower across tomcat-dev subscribers (the ones who want to be here, not the ones who manage to subscribe post let me out 3 days later :-) And since it will be buildable independent of any connector code, it could be moved to commons or even apr. ??? If you don't have apr - it seems a little problematic to build an apr-jni interface. The reason I suggest this is that we have .pkg and .rpm folks supporting standardized apr 0.9 / 1.x installs. Well that's OK, but the apr-java consists of two parts: native library and .jar file, requires Java SDK installed, etc. Of course. There is glue on both sides. To build an apr xs thunk, one needs perl, to build an apr c++ wrapper, one needs c++ (which apr doesn't require.) Same if there was an apr .NET wrapper. I'm thinking in terms of optional components buildable under the apr tree, when the appropriate choices are made. The point I was making is that it would be a shame to reinvent the object model of APR for several different languages. Any robust APR-wrapper object model should prove exceedingly consistent (to the developer/user) between langauges, although the glue varies wildly. This has all already been accomplished by our devoted modperl developers. Why not fold all such special interests? If this is of little interest to [EMAIL PROTECTED] in general, we can always spin of [EMAIL PROTECTED] for object and glue discussions. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Lingering jk/native/common/ bugs
Although all serious problems seem cleared up, we do still have invalid early declarations of the following two static modules. No patch, since these are either ment to be static (and should -not- be declared in jk_uri_worker_map.h) or they are ment to be shared, exported functions; jk_uri_worker_map.c:514: warning: static declaration for `uri_worker_map_close' follows non-static jk_uri_worker_map.c:530: warning: static declaration for `jk_no2slash' follows non-static - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [INTRODUCE] apr-java
Silly Question - doesn't this proposal fit better in the commons project than Tomcat? For that matter, I'm rolling the dice that the apr project itself would entertain the possibilities of supporting jni / xs / c++ wrappers. The reason I suggest this is that we have .pkg and .rpm folks supporting standardized apr 0.9 / 1.x installs. To keep these in sync would ultimately become quite important. The second reason is that we should truly adopt consistent OO conventions for all of these varied extension schemas. Bill At 08:25 AM 1/7/2005, Mladen Turk wrote: Hi, Here is the work in progress for a new project I named apr-java. It offers a 'thin' layer using JNI over APR library. The initial code that I wrote over a year now had two way api, but I've decided to leave only Java-APR. I also have a working set of configure and make files for unixes, but since this is an overview of the technology, it's only a small subset of entire project, but you can get the picture :) . It will support around 90% of APR API (without things like strings, etc. that are well done inside java itself). The API itself on the Java side is done as close to the APR function call (apr_file_write - File.write) with almost the same function parameters as well. You can see that the wrapping code is very thin in most cases with only a couple of lines for each function, mostly caused by pointer issues. I'm sending the gz file (tried zip but failed) so you can see what the general idea is. Of course the library can be extended with functions that APR doesn't offer (for now or never will). One of the things would be setting user and group for a process, sending data from parent to child process, etc. The question is: Is it acceptable (think that previous discussions say it is) Where to put that in the cvs. Comments? 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: [ANN] JK 1.2.8 Released
This isn't targetted at Mladen, but just want the participants to understand the ramifications. When the Project votes to release software, it becomes the problem of the Foundation to stand behind it. If you release without following this procedure, you own all of the liability, which is a very dangerous position. That said, glad that this got it's +1's (and another +1 here from the peanut gallery.) Congratulations especially to Bill, Jean-Jacques and Mladen for all their efforts! Bill At 06:38 AM 12/24/2004, Mladen Turk wrote: The Apache Jakarta Tomcat team is proud to announce the immediate availability of Jakarta Tomcat Connectors 1.2.8. This new release has passed the very rigorous release process with four beta versions released. Please see the http://jakarta.apache.org/tomcat/connectors-doc/changelog.html for a full list of changes. JK 1.2.8 is considered as stable for the following web servers and platforms: Apache 1.3.33 an up - any Unix or Linux, WIN32. Apache 2.0.52 an up - any Unix or Linux, WIN32 and Netware. IIS 5.0 an up - WIN32. Other web servers like Lotus Domino or Netscape/iPlanet have not been the focus of this release and it's further development will depend on users interest. You can download sources from: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/jk-1.2.8/source The binaries (for WIN32 only at the moment) are available at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/win32/ The Jakarta Tomcat Connectors Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[patch] win32 buildfoo.
This patch has minimal impact but a ton of benefits... The patch [for jk and jk2, not that it matters as much] allows anyone to debug and diagnose stack dumps using windbg or any other debugging tool, and (if they add the .pdb files to their installation) to make sense of dr watson logs. It splits the source from the output binaries' .pdb files (as they aren't compatible under certain configurations) and sets a predictable base address (ascii JK ;-). Feedback welcome, it would be good to have this in 1.2.8 to be able to grok users' backtraces. If you don't mind please add the jk2 stuff as well, seeing as, even unsupported, some users migrating away still require assistance at times. Thanks, BillIndex: jk/native/apache-2.0/mod_jk.dsp === RCS file: /var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/apache-2.0/mod_jk.dsp,v retrieving revision 1.6 diff -u -r1.6 mod_jk.dsp --- jk/native/apache-2.0/mod_jk.dsp 16 Jan 2002 19:46:37 - 1.6 +++ jk/native/apache-2.0/mod_jk.dsp 23 Dec 2004 08:13:04 - @@ -43,7 +43,7 @@ # PROP Ignore_Export_Lib 0 # PROP Target_Dir # ADD BASE CPP /nologo /MD /W3 /O2 /D WIN32 /D NDEBUG /D _WINDOWS /FD /c -# ADD CPP /nologo /MD /W3 /O2 /D NDEBUG /D WIN32 /D _WINDOWS /I ..\common /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I $(APACHE2_HOME)\srclib\apr\include /I $(APACHE2_HOME)\srclib\apr-util\include /FdRelease\mod_jk /FD /c +# ADD CPP /nologo /MD /W3 /Zi /O2 /D NDEBUG /D WIN32 /D _WINDOWS /I ..\common /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I $(APACHE2_HOME)\srclib\apr\include /I $(APACHE2_HOME)\srclib\apr-util\include /FdRelease/mod_jk_src /FD /c # ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d NDEBUG @@ -53,7 +53,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib advapi32.lib /nologo /dll /machine:I386 -# ADD LINK32 libhttpd.lib libapr.lib libaprutil.lib kernel32.lib user32.lib advapi32.lib wsock32.lib /nologo /dll /machine:I386 /libpath:$(APACHE2_HOME)\Release /libpath:$(APACHE2_HOME)\srclib\apr\Release /libpath:$(APACHE2_HOME)\srclib\apr-util\Release /libpath:$(APACHE2_HOME)\lib +# ADD LINK32 libhttpd.lib libapr.lib libaprutil.lib kernel32.lib user32.lib advapi32.lib wsock32.lib /nologo /base:0x6A6B /subsystem:windows /dll /incremental:no /debug /machine:I386 /out:Release/mod_jk.so /opt:ref /libpath:$(APACHE2_HOME)\Release /libpath:$(APACHE2_HOME)\srclib\apr\Release /libpath:$(APACHE2_HOME)\srclib\apr-util\Release /libpath:$(APACHE2_HOME)\lib !ELSEIF $(CFG) == apache - Win32 Debug @@ -69,7 +69,7 @@ # PROP Ignore_Export_Lib 0 # PROP Target_Dir # ADD BASE CPP /nologo /MDd /W3 /GX /Zi /Od /D WIN32 /D _DEBUG /D _WINDOWS /FD /c -# ADD CPP /nologo /MDd /W3 /GX /Zi /Od /D _DEBUG /D WIN32 /D _WINDOWS /I ..\common /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I $(APACHE2_HOME)\srclib\apr\include /I $(APACHE2_HOME)\srclib\apr-util\include /FdDebug\mod_jk /FD /c +# ADD CPP /nologo /MDd /W3 /GX /Zi /Od /D _DEBUG /D WIN32 /D _WINDOWS /I ..\common /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I $(APACHE2_HOME)\include /I $(APACHE2_HOME)\srclib\apr\include /I $(APACHE2_HOME)\srclib\apr-util\include /FdDebug/mod_jk_src /FD /c # ADD BASE MTL /nologo /D _DEBUG /mktyplib203 /win32 # ADD MTL /nologo /D _DEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d _DEBUG @@ -79,7 +79,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept -# ADD LINK32 libhttpd.lib libapr.lib libaprutil.lib kernel32.lib user32.lib advapi32.lib wsock32.lib /nologo /dll /debug /machine:I386 /libpath:$(APACHE2_HOME)/Debug /libpath:$(APACHE2_HOME)\srclib\apr\Debug /libpath:$(APACHE2_HOME)\srclib\apr-util\Debug /libpath:$(APACHE2_HOME)\lib +# ADD LINK32 libhttpd.lib libapr.lib libaprutil.lib kernel32.lib user32.lib advapi32.lib wsock32.lib /nologo /base:0x6A6B /subsystem:windows /dll /incremental:no /debug /machine:I386 /out:Debug/mod_jk2.so /libpath:$(APACHE2_HOME)/Debug /libpath:$(APACHE2_HOME)\srclib\apr\Debug /libpath:$(APACHE2_HOME)\srclib\apr-util\Debug /libpath:$(APACHE2_HOME)\lib !ENDIF Index: jk/native/nt_service/nt_service.dsp === RCS file: /var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/nt_service/nt_service.dsp,v retrieving revision 1.8 diff -u -r1.8 nt_service.dsp --- jk/native/nt_service/nt_service.dsp 12 Mar 2002 19:12:18 - 1.8 +++ jk/native/nt_service/nt_service.dsp 23 Dec 2004 08:13:05 - @@ -41,8 +41,8 @@ # PROP
Re: Tagging JK_1_2_8_RC_1 today 18:00 GMT
At 01:52 AM 12/23/2004, Mladen Turk wrote: That's cool, but the handling of in_addr_t is totally bogus and has been for some time. Some platforms declare struct in_addr_t as a typedef - but others don't. The crossplatform solution is to ignore the typedef and use in_addr_t, but instead, the code currently does some crap with uint for win32 and ignores HP/UX and a host of other platforms. I'll offer a patch in the next 24 hours to handle the in_addr_t data gracefully and without a host of compiler emits and build failures. No functional changes required :) OK. By the way, I agree the code had no emits. It's easy to eliminate compile emits by (cast)ing them away. Yes - the patch keeps one cast, it's necessary due to the bogus definition of the hostent structure which was stillborn, braindead :) However, the code didn't compile on non-win32/netware platforms with no in_addr_t typedef, so it was still quite non-portable. The patch corrects for all platforms, not just one-off cases. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] win32 buildfoo.
At 02:32 AM 12/23/2004, Mladen Turk wrote: William A. Rowe, Jr. wrote: This patch has minimal impact but a ton of benefits... So, it's the /Zi for PDB's and /base:address? Does it mean that we'll need to distribute the pdb files together with .dll's? Oh no! The beauty is, is you can distribute them separately for anyone who actually cares. For everyone who doesn't, the .dll file is entirely identical to the one we used to build. In the Win32 httpd world, we have an optional -symbols.zip file with such .dsp files for those who want to diagnose issues. The patch [for jk and jk2, not that it matters as much] OK for JK, but -1 on JK2. We agreed long time ago to stop JK2 support. I'll keep my local JK2 patches, but 'supporting' JK2 is different than committing fixes. I'm not suggesting anyone in tomcat-dev actually would support it, merely commit a matching patch. Attached is the 1.3 JK 1.2 patch, which is even more broken than the others :) Still /MT? LOL. Please consider this additional patch as well. Bill Index: jk/native/apache-1.3/mod_jk.dsp === RCS file: /var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/apache-1.3/mod_jk.dsp,v retrieving revision 1.5 diff -u -r1.5 mod_jk.dsp --- jk/native/apache-1.3/mod_jk.dsp 20 Jul 2001 15:10:26 - 1.5 +++ jk/native/apache-1.3/mod_jk.dsp 23 Dec 2004 08:43:31 - @@ -42,8 +42,8 @@ # PROP Intermediate_Dir Release # PROP Ignore_Export_Lib 0 # PROP Target_Dir -# ADD BASE CPP /nologo /MT /W3 /GX /O2 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /YX /FD /c -# ADD CPP /nologo /MT /W3 /GX /O2 /I ..\common /I $(APACHE1_HOME)\src\include /I $(APACHE1_HOME)\src\os\win32 /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /YX /FD /c +# ADD BASE CPP /nologo /MD /W3 /O2 /Zi /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /FD /c +# ADD CPP /nologo /MD /W3 /O2 /Zi /I ..\common /I $(APACHE1_HOME)\include /I $(APACHE1_HOME)\src\include /I $(APACHE1_HOME)\src\os\win32 /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /FdRelease\mod_jk_src /FD /c # ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d NDEBUG @@ -53,7 +53,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 -# ADD LINK32 ApacheCore.lib wsock32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 /libpath:$(APACHE1_HOME)\src\CoreR /libpath:$(APACHE1_HOME)\src\Release +# ADD LINK32 ApacheCore.lib wsock32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /base:0x6A6B /subsystem:windows /dll /incremental:no /debug /machine:I386 /out:Release/mod_jk.so /opt:ref /libpath:$(APACHE1_HOME)\libexec /libpath:$(APACHE1_HOME)\src\CoreR /libpath:$(APACHE1_HOME)\src\Release !ELSEIF $(CFG) == mod_jk - Win32 Debug @@ -68,8 +68,8 @@ # PROP Intermediate_Dir Debug # PROP Ignore_Export_Lib 0 # PROP Target_Dir -# ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /YX /FD /GZ /c -# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I ..\common /I $(APACHE1_HOME)\src\include /I $(APACHE1_HOME)\src\os\win32 /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /FR /YX /FD /GZ /c +# ADD BASE CPP /nologo /MDd /W3 /GX /Zi /Od /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /FD /c +# ADD CPP /nologo /MDd /W3 /GX /Zi /Od /I ..\common /I $(APACHE1_HOME)\include /I $(APACHE1_HOME)\src\include /I $(APACHE1_HOME)\src\os\win32 /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_JK_EXPORTS /FdDebug\mod_jk_src /FD /c # ADD BASE MTL /nologo /D _DEBUG /mktyplib203 /win32 # ADD MTL /nologo /D _DEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d _DEBUG @@ -79,7 +79,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept -# ADD LINK32 ApacheCore.lib wsock32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept /libpath
Re: [patch] win32 buildfoo.
At 07:49 AM 12/23/2004, Jerome Jar wrote: Oo, that's very nice of you:) I'll try it as soon as the download finished... Note that diagnosing /O2 files can get tricky (on win32 or on any un*x build, of course.) Hope you enjoy, happy holidays :) At 07:43 AM 12/23/2004, Mladen Turk wrote: William A. Rowe, Jr. wrote: Oh no! The beauty is, is you can distribute them separately for anyone who actually cares. OK seems reasonable. I'll create a zip with all *.pdb and *_src.pdb. It's not necessary to distribute *_src.pdb files. It turns out that the compiler .pdb is a different beast than the linker .pdb. foo_src.pdb is an input file to the creation of foo.pdb for foo.dll. Everything we need is in foo.pdb to debug foo.dll, and it's kept lighter weight and more compatible with the build tools by not having been shared as a compiler database. Attached is the 1.3 JK 1.2 patch, which is even more broken than the others :) Still /MT? LOL. Please consider this additional patch as well. Committed for apache1, apache2 and iis. Thank you - sorry I forgot the iis one myself. Let me note - the only reason we are getting away with sharing the load offset 6A6B (it's still relocatable - but avoids automatic relocation when there isn't a conflict) is that no two of these modules will be loaded into the same server process. And no, it doesn't matter if the iis and apache2 modules are loaded in two different processes at the same time, at the same address. What we'll need eventually is the same for jk/native/jni Same, but load offset 6A6E for example (leaving 192k of pages for mod_jk) since it must be loaded into the same process. See my native2 jni project. Not sure what to do with: jk/native/domino and jk/native/netscape The same should be safe. No idea how far folks would get delving into this (at least with IIS, I believe you can get most of the traceback working by setting up windbg to point at the microsoft symbol server.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[patch] native/jk/nt_service updates
The attached patch fixes the nt_service thunk - for the various
API changes which have occured in recent times (jk_map etc.)
It gets it building again clean, at least.
The only thing I'm not certain - is the -1 arg for timeout really
appropriate? If not, is there something better to use?
This was the end of my build failures, I'm looking at the jk_connect.dsp
issue you raised.
Bill
Index: jk/native/nt_service/jk_nt_service.c
===
RCS file:
/var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/nt_service/jk_nt_service.c,v
retrieving revision 1.11
diff -u -u -3 -r1.11 jk_nt_service.c
--- jk/native/nt_service/jk_nt_service.c5 Nov 2004 15:28:39 -
1.11
+++ jk/native/nt_service/jk_nt_service.c23 Dec 2004 18:12:23 -
@@ -871,7 +871,7 @@
}
if(jk_resolve(localhost, port, in)) {
-int sd = jk_open_socket(in, JK_TRUE, 0, NULL);
+int sd = jk_open_socket(in, JK_TRUE, 0, -1, NULL);
if(sd 0) {
int rc = JK_FALSE;
@@ -954,8 +954,8 @@
sizeof(prp_file))) {
jk_map_t *init_map;
-if(map_alloc(init_map)) {
-if(map_read_properties(init_map, prp_file)) {
+if(jk_map_alloc(init_map)) {
+if(jk_map_read_properties(init_map, prp_file)) {
jk_tomcat_startup_data_t data;
jk_pool_t p;
jk_pool_atom_t buf[HUGE_POOL_SIZE];
@@ -1127,29 +1127,29 @@
/* All this is wrong - you just need to configure cmd_line */
/* Optional - you may have cmd_line defined */
-data-server_file = map_get_string(init_map,
- wrapper.server_xml,
+data-server_file = jk_map_get_string(init_map,
+ wrapper.server_xml,
+ NULL);
+data-classpath = jk_map_get_string(init_map,
+wrapper.class_path,
+NULL);
+data-tomcat_home = jk_map_get_string(init_map,
+ wrapper.tomcat_home,
+ NULL);
+data-java_bin = jk_map_get_string(init_map,
+ wrapper.javabin,
NULL);
-data-classpath = map_get_string(init_map,
- wrapper.class_path,
+data-tomcat_class = jk_map_get_string(init_map,
+ wrapper.startup_class,
+ org.apache.tomcat.startup.Tomcat);
+
+data-cmd_line = jk_map_get_string(init_map,
+ wrapper.cmd_line,
NULL);
-data-tomcat_home = map_get_string(init_map,
- wrapper.tomcat_home,
+
+data-stop_cmd = jk_map_get_string(init_map,
+ wrapper.stop_cmd,
NULL);
-data-java_bin = map_get_string(init_map,
-wrapper.javabin,
-NULL);
-data-tomcat_class = map_get_string(init_map,
-wrapper.startup_class,
-org.apache.tomcat.startup.Tomcat);
-
-data-cmd_line = map_get_string(init_map,
-wrapper.cmd_line,
-NULL);
-
-data-stop_cmd = map_get_string(init_map,
-wrapper.stop_cmd,
-NULL);
if(NULL == data-cmd_line
( (NULL == data-tomcat_class) ||
@@ -1185,24 +1185,25 @@
strcat(data-cmd_line, data-server_file);
}
-data-shutdown_port = map_get_int(init_map,
- wrapper.shutdown_port,
- 8007);
-
-data-shutdown_secret = map_get_string(init_map,
- wrapper.shutdown_secret, NULL );
+data-shutdown_port = jk_map_get_int(init_map,
+ wrapper.shutdown_port,
+ 8007);
+
+data-shutdown_secret = jk_map_get_string(init_map,
+ wrapper.shutdown_secret,
+ NULL);
-data-shutdown_protocol = map_get_string(init_map,
- wrapper.shutdown_protocol,
- AJP12_TAG);
-
-data-extra_path = map_get_string(init_map,
- wrapper.ld_path,
- NULL);
-
-data-stdout_file =
Re: [patch] win32 buildfoo.
At 11:51 AM 12/23/2004, William A. Rowe, Jr. wrote: What we'll need eventually is the same for jk/native/jni Same, but load offset 6A6E for example (leaving 192k of pages for mod_jk) since it must be loaded into the same process. See my native2 jni project. And the attached patch. Happy holidays all, think this wraps it. Bill Index: jk/native/jni/jni_connect.dsp === RCS file: /var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/jni/jni_connect.dsp,v retrieving revision 1.2 diff -u -r1.2 jni_connect.dsp --- jk/native/jni/jni_connect.dsp 25 Aug 2001 00:55:40 - 1.2 +++ jk/native/jni/jni_connect.dsp 23 Dec 2004 18:25:22 - @@ -42,8 +42,8 @@ # PROP Intermediate_Dir release # PROP Ignore_Export_Lib 0 # PROP Target_Dir -# ADD BASE CPP /nologo /MT /W3 /GX /O2 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /YX /FD /c -# ADD CPP /nologo /MT /W3 /GX /O2 /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I ..\common /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /YX /FD /c +# ADD BASE CPP /nologo /MD /W3 /GX /Zi /O2 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /FD /c +# ADD CPP /nologo /MD /W3 /GX /Zi /O2 /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I ..\common /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /FdRelease/jni_connect_src /FD /c # ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d NDEBUG @@ -53,7 +53,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /base:0x6A6E /subsystem:windows /dll /incremental:no /debug /machine:I386 /opt:ref !ELSEIF $(CFG) == jni_connect - Win32 Debug @@ -68,8 +68,8 @@ # PROP Intermediate_Dir debug # PROP Ignore_Export_Lib 0 # PROP Target_Dir -# ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /YX /FD /GZ /c -# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I ..\common /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /YX /FD /GZ /c +# ADD BASE CPP /nologo /MDd /W3 /Gm /GX /Zi /Od /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /FD /c +# ADD CPP /nologo /MDd /W3 /Gm /GX /Zi /Od /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /I ..\common /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D JNI_CONNECT_EXPORTS /FdDebug/jni_connect_src /FD /c # ADD BASE MTL /nologo /D _DEBUG /mktyplib203 /win32 # ADD MTL /nologo /D _DEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d _DEBUG @@ -79,7 +79,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /base:0x6A6E /subsystem:windows /dll /incremental:no /debug /machine:I386 !ENDIF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
still jk2?
http://jakarta.apache.org/tomcat/connectors-doc-archive/jk2/index.html seems a bit dated. Perhaps add some indication that this is no longer the recommended solution? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
Wait - you mean to tell me instead of converting the hostname
once to lower - we are strcasecmp'ing every time? Outch, that
hurts.
Bill
At 09:14 PM 12/16/2004, [EMAIL PROTECTED] wrote:
billbarker2004/12/16 19:14:56
Modified:jk/native/apache-1.3 mod_jk.c
jk/native/apache-2.0 mod_jk.c
Log:
Now that the SC lookup is case-insensitive, don't waste cycles converting
the header names to lower case
Revision ChangesPath
1.60 +2 -6 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- mod_jk.c 13 Dec 2004 09:11:24 - 1.59
+++ mod_jk.c 17 Dec 2004 03:14:56 - 1.60
@@ -592,12 +592,8 @@
char *hname = ap_pstrdup(r-pool, elts[i].key);
s-headers_values[i] = ap_pstrdup(r-pool, elts[i].val);
s-headers_names[i] = hname;
-while (*hname) {
-*hname = tolower(*hname);
-hname++;
-}
if (need_content_length_header
-!strncmp(s-headers_values[i], content-length, 14)) {
+!strcasecmp(s-headers_values[i], content-length)) {
need_content_length_header = JK_FALSE;
}
}
1.110 +2 -6 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.109
retrieving revision 1.110
diff -u -r1.109 -r1.110
--- mod_jk.c 13 Dec 2004 09:10:31 - 1.109
+++ mod_jk.c 17 Dec 2004 03:14:56 - 1.110
@@ -636,12 +636,8 @@
char *hname = apr_pstrdup(r-pool, elts[i].key);
s-headers_values[i] = apr_pstrdup(r-pool, elts[i].val);
s-headers_names[i] = hname;
-while (*hname) {
-*hname = tolower(*hname);
-hname++;
-}
if (need_content_length_header
-!strncmp(s-headers_values[i], content-length, 14)) {
+!strcasecmp(s-headers_values[i], content-length)) {
need_content_length_header = JK_FALSE;
}
}
-
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-site/docs/faq/printer connectors.html
At 06:34 AM 12/20/2004, [EMAIL PROTECTED] wrote: funkman 2004/12/20 04:34:03 Modified:xdocs-faq connectors.xml docs/faq connectors.html docs/faq/printer connectors.html Log: Note that jk2 is deprecated and that mod_ajp is coming. Don't we mean mod_proxy_ajp? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK_1_2_8_RC_1 today 18:00 GMT
At 03:36 AM 12/17/2004, Mladen Turk wrote: The 1.2.7 release has done it's share of work by testing all those new features added. The 1.2.8-rc-1 will add no new features. There are still one potential bug present, reported by Henri Gomez with Tomcat 3.3.2. The other issue is to see the URL rewriting problem reported by Derrick Koes. Since there is the possibility that they are related, I'll leave that for 1.2.8 final. That's cool, but the handling of in_addr_t is totally bogus and has been for some time. Some platforms declare struct in_addr_t as a typedef - but others don't. The crossplatform solution is to ignore the typedef and use in_addr_t, but instead, the code currently does some crap with uint for win32 and ignores HP/UX and a host of other platforms. I'll offer a patch in the next 24 hours to handle the in_addr_t data gracefully and without a host of compiler emits and build failures. No functional changes required :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default Tomcat installation location on Windows
I've answered this at least once before. Apache Group is ancient trivia. Apache Software Foundation is the proper name and will even be used in httpd-2.2 once that is released. There hasn't been an Apache Group since early year 2000 when the foundation was created - Tomcat got it right when they switched names. Apache 2.0 and 1.3 were already there, so they aren't moving until a minor (not subversion) bump. Bill - Original Message - From: Dominik Drzewiecki [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Sent: Sunday, December 28, 2003 3:47 PM Subject: Default Tomcat installation location on Windows Howdy, The default location for Tomcat 5.0 installation on Windows is c:\program Files\Apache Software Foundation\Tomcat 5.0. On the other hand, win32 Apache 2.0 installer suggests c:\Program Files\Apache Group\Apache 2.0. I suggest that these directories should be unified for clarity, let's say the default root directory for Apache softwere should be c:\Program Files\Apache Group. After all it is Apache's httpd that was first to come up with Apache Group directory ;). I think Tomcat 5.0.x as well as 4.1.x should stick with it (Maven does, AFAIK). With all the best wishes for the forthcoming New Year, May it be fruitful and peacefull for all of you and your families, Dominik Drzewiecki - 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: Tagging JK_1_2_8_RC_1 today 18:00 GMT
At 01:13 AM 12/23/2004, William A. Rowe, Jr. wrote:
At 03:36 AM 12/17/2004, Mladen Turk wrote:
The 1.2.8-rc-1 will add no new features.
That's cool, but the handling of in_addr_t is totally bogus and
has been for some time. Some platforms declare struct in_addr_t
as a typedef - but others don't. The crossplatform solution is
to ignore the typedef and use in_addr_t, but instead, the code
currently does some crap with uint for win32 and ignores HP/UX
and a host of other platforms.
I ment use struct in_addr. In any case, attached is the patch
for your perusal - it fixes one other non-conformant typedef
(that didn't match the pattern throughout jk) in jk_pool.h.
Please consider both for a much cleaner source pattern.
Bill
Index: jk/native/common/jk_connect.c
===
RCS file:
/var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/common/jk_connect.c,v
retrieving revision 1.35
diff -u -r1.35 jk_connect.c
--- jk/native/common/jk_connect.c 17 Dec 2004 14:58:37 - 1.35
+++ jk/native/common/jk_connect.c 23 Dec 2004 07:43:30 -
@@ -35,10 +35,6 @@
#include apr_general.h
#endif
-#if defined(WIN32)
-typedef u_long in_addr_t;
-#endif
-
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
#define JK_IS_SOCKET_ERROR(x) ((x) == SOCKET_ERROR)
#define JK_GET_SOCKET_ERRNO() errno = WSAGetLastError() - WSABASEERR
@@ -53,15 +49,7 @@
int jk_resolve(char *host, int port, struct sockaddr_in *rc)
{
int x;
-
-/* TODO: Should be updated for IPV6 support. */
-/* for now use the correct type, in_addr_t */
-/* except on NetWare since the MetroWerks compiler is so strict */
-#if defined(NETWARE)
-u_long laddr;
-#else
-in_addr_t laddr;
-#endif
+struct in_addr laddr;
memset(rc, 0, sizeof(struct sockaddr_in));
@@ -119,13 +107,13 @@
return JK_FALSE;
}
-laddr = ((struct in_addr *)hoste-h_addr_list[0])-s_addr;
+laddr = *((struct in_addr *)hoste-h_addr_list[0]);
#endif /* HAVE_APR */
}
else {
/* If we found only digits we use inet_addr() */
-laddr = inet_addr(host);
+laddr.s_addr = inet_addr(host);
}
memcpy((rc-sin_addr), laddr, sizeof(laddr));
Index: jk/native/common/jk_pool.h
===
RCS file:
/var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/common/jk_pool.h,v
retrieving revision 1.9
diff -u -r1.9 jk_pool.h
--- jk/native/common/jk_pool.h 8 Nov 2004 13:32:56 - 1.9
+++ jk/native/common/jk_pool.h 23 Dec 2004 07:43:30 -
@@ -93,9 +93,8 @@
#define BIG_POOL_SIZE 2*SMALL_POOL_SIZE /* Bigger 1K atom pool. */
#define HUGE_POOL_SIZE 2*BIG_POOL_SIZE /* Huge 2K atom pool. */
-typedef struct jk_pool_t jk_pool_t;
/** jk pool structure */
-struct jk_pool_t
+struct jk_pool
{
size_t size;
size_t pos;
@@ -104,6 +103,8 @@
size_t dyn_pos;
void **dynamic;
};
+
+typedef struct jk_pool jk_pool_t;
void jk_open_pool(jk_pool_t *p, jk_pool_atom_t *buf, size_t size);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Patch, rev 2] Tagging JK_1_2_8_RC_1 today 18:00 GMT
This is a better patch, it also covers the deprecated code
that still exists in the HAVE_APR path.
At 01:46 AM 12/23/2004, William A. Rowe, Jr. wrote:
At 01:13 AM 12/23/2004, William A. Rowe, Jr. wrote:
At 03:36 AM 12/17/2004, Mladen Turk wrote:
The 1.2.8-rc-1 will add no new features.
That's cool, but the handling of in_addr_t is totally bogus and
has been for some time. Some platforms declare struct in_addr_t
as a typedef - but others don't. The crossplatform solution is
to ignore the typedef and use in_addr_t, but instead, the code
currently does some crap with uint for win32 and ignores HP/UX
and a host of other platforms.
I ment use struct in_addr. In any case, attached is the patch
for your perusal - it fixes one other non-conformant typedef
(that didn't match the pattern throughout jk) in jk_pool.h.
Please consider both for a much cleaner source pattern.
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
? .flavour_complete
? foo
? patch
? jk/native/apache-2.0/Debug
? jk/native/apache-2.0/Release
? jk/native/apache-2.0/mod_jk.dsw
? jk/native/apache-2.0/mod_jk.ncb
? jk/native/apache-2.0/mod_jk.opt
? jk/native/apache-2.0/mod_jk.plg
? jk/native/nt_service/Release
? jk/native/nt_service/nt_service.plg
Index: jk/native/common/jk_connect.c
===
RCS file:
/var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/common/jk_connect.c,v
retrieving revision 1.35
diff -u -r1.35 jk_connect.c
--- jk/native/common/jk_connect.c 17 Dec 2004 14:58:37 - 1.35
+++ jk/native/common/jk_connect.c 23 Dec 2004 07:50:22 -
@@ -35,10 +35,6 @@
#include apr_general.h
#endif
-#if defined(WIN32)
-typedef u_long in_addr_t;
-#endif
-
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
#define JK_IS_SOCKET_ERROR(x) ((x) == SOCKET_ERROR)
#define JK_GET_SOCKET_ERRNO() errno = WSAGetLastError() - WSABASEERR
@@ -53,15 +49,7 @@
int jk_resolve(char *host, int port, struct sockaddr_in *rc)
{
int x;
-
-/* TODO: Should be updated for IPV6 support. */
-/* for now use the correct type, in_addr_t */
-/* except on NetWare since the MetroWerks compiler is so strict */
-#if defined(NETWARE)
-u_long laddr;
-#else
-in_addr_t laddr;
-#endif
+struct in_addr laddr;
memset(rc, 0, sizeof(struct sockaddr_in));
@@ -105,7 +93,7 @@
return JK_FALSE;
apr_sockaddr_ip_get(remote_ipaddr, remote_sa);
-laddr = inet_addr(remote_ipaddr);
+laddr.s_addr = inet_addr(remote_ipaddr);
/* May be we could avoid to delete it each time ? */
apr_pool_destroy(context);
@@ -119,13 +107,13 @@
return JK_FALSE;
}
-laddr = ((struct in_addr *)hoste-h_addr_list[0])-s_addr;
+laddr = *((struct in_addr *)hoste-h_addr_list[0]);
#endif /* HAVE_APR */
}
else {
/* If we found only digits we use inet_addr() */
-laddr = inet_addr(host);
+laddr.s_addr = inet_addr(host);
}
memcpy((rc-sin_addr), laddr, sizeof(laddr));
Index: jk/native/common/jk_pool.h
===
RCS file:
/var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/common/jk_pool.h,v
retrieving revision 1.9
diff -u -r1.9 jk_pool.h
--- jk/native/common/jk_pool.h 8 Nov 2004 13:32:56 - 1.9
+++ jk/native/common/jk_pool.h 23 Dec 2004 07:50:22 -
@@ -93,9 +93,8 @@
#define BIG_POOL_SIZE 2*SMALL_POOL_SIZE /* Bigger 1K atom pool. */
#define HUGE_POOL_SIZE 2*BIG_POOL_SIZE /* Huge 2K atom pool. */
-typedef struct jk_pool_t jk_pool_t;
/** jk pool structure */
-struct jk_pool_t
+struct jk_pool
{
size_t size;
size_t pos;
@@ -104,6 +103,8 @@
size_t dyn_pos;
void **dynamic;
};
+
+typedef struct jk_pool jk_pool_t;
void jk_open_pool(jk_pool_t *p, jk_pool_atom_t *buf, size_t size);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: JK 1.2.7 Problem?
At 05:51 AM 12/14/2004, Allistair Crossley wrote: Copying in DEV on this JK issue/solution on Mladen's request. The release build worked fine. Seems that the problem is caused by the fact that beta3 binaries are compiled as 'debug' so tolower function is issuing an assertion. I'll make a release build and sent it to your email directly. Can you check the results with release build? Mladen. FYI - you are familiar with the fact that you do not need to build 'debug' in order to obtain useful info? Refer to any of the httpd module build projects for the semantics of building in release mode, yet extracting all debug symbolic information into a .pdb file. Other side effect is that you have two different malloc'ator schemes going on in a release-httpd and debug-jk combination. This mishmash causes me no end of grief every time I try it with release builds of libssl32 and libeay32 - it blows up in very odd places. Almost worth a whole article '_DEBUG considered harmful' :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default Tomcat installation location on Windows
It most certainly should NOT be Apache Group - that's an entity that no longer exists (it's what the folks called themselves before the foundation was formed.) We won't change in on the httpd side until a brand new Apache comes out (e.g. httpd 2.2) but expect we will move it to the Apache Software Foundation at that time. Bill - Original Message - From: Dominik Drzewiecki [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 28, 2003 3:47 PM Subject: Default Tomcat installation location on Windows The default location for Tomcat 5.0 installation on Windows is c:\program Files\Apache Software Foundation\Tomcat 5.0. On the other hand, win32 Apache 2.0 installer suggests c:\Program Files\Apache Group\Apache 2.0. I suggest that these directories should be unified for clarity, let's say the default root directory for Apache softwere should be c:\Program Files\Apache Group. After all it is Apache's httpd that was first to come up with Apache Group directory ;). I think Tomcat 5.0.x as well as 4.1.x should stick with it (Maven does, AFAIK). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time for 2.0.51 and 2.1.0
At 09:25 AM 9/2/2004, Henri Gomez wrote: Bad news for me and many others since without AJP support included in 2.0.x, users will still require to have mod_jk to link there HTTPD to Tomcats. Could we hope the dev team to relax the situation for mod_proxy/ajp in future 2.0.x release, since Graham, Mladen and Jean-Frederic works hard to make mod_proxy as stable as possible even now with AJP support ? Henri, meaning no disrespect to this team (they have accomplished some fantastic things) ... it took us a very long time to beyond the initial release to get proxy to something resembling the stability of 1.3, and mod_cache is still getting there. Admins understand why n.x - (n+1).0 can sometimes break things. That's the natural aversion to .0 releases. They can even understand if n.x.z - n.(x+1).0 breaks things. But please don't expect them to sympathize when n.x.z - n.x.(z+1) starts breaking things, this undermines the confidence in one of the most successful open source projects in the world. When we say x.even releases are -stable- we mean, don't expect things to break when you upgrade. When we say x.odd releases are development, that means ya - it might break on a point bump, live with it and let us know so the subsequent x.even release is golden. We are trying to move from the 1.3 and early 2.0 models of change this, dabble in that, add this, break that and keep the users chasing a moving target. The beginnings of the 2.0 release were pretty violent in terms of the changes needed to move from 2.0.36 to 2.0.39 to 2.0.43, and it didn't do alot for us in terms of uptake for the httpd-2 server. Since .43 the consistency has changed alot - and we want to continue to improve the quality, and not introduce potentially shaky changes. You have a simple option though - grab 2.0. Replace the modules/proxy/ tree with 2.1-dev and voila - buildconf - configure - make install. Or use 2.1-dev and help the effort of identifying when 2.1-dev reaches release quality. Mladen provided both alternatives in the current mod. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time for 2.0.51 and 2.1.0
At 12:59 PM 9/2/2004, Mladen Turk wrote: William A. Rowe, Jr. wrote: Could we hope the dev team to relax the situation for mod_proxy/ajp in future 2.0.x release [...] please don't expect them to sympathize when n.x.z - n.x.(z+1) starts breaking things, this undermines the confidence in one of the most successful open source projects in the world. Although I'm not very happy with that, I must say that you hold 'all the aces' :). httpd, like Tomcat, is a meritocracy. Jeff and I argued for a stable tree and development effort not to break existing 2.0 users. Others argued against that. The last round of voting our suggestion won. Next vote that could change of course. Just wanted to reinforce, no one individual or even group of devs ever holds all the aces here :) The major problem is how to prove the new proxy stuff is stable Aye - there is the rub. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [AJP] proxy status
At 11:18 PM 8/11/2004, Costin Manolache wrote: William A. Rowe, Jr. wrote: It would be great if we would have at least one or 2 people who are committers in both projects. Since we can't propose Mladen in apache, maybe we can convince Graham to join tomcat :-) Can't propose mturk? Why, because he is already active in httpd space? My point was that it is hard to do development across 2 projects, while none of the developers has CVS access in both. Hopefully that can be addressed... If it is not possible to find a solution to the cvs permissions in either apache or tomcat - then maybe it would be good to have it in a separate repository. It may make it easier to also port it to apache2.0, as a separate standalone module. at one time we had forked mod_proxy development to its own repository, since it was nowhere near ready for 2.0 inclusion. [EMAIL PROTECTED] was created for just this purpose. At least from a development traffic point of view, perhaps it's worth resurrecting that mailing list. As far as code is concerned, Graham, for the moment, is willing to take care of those patches. Although he's subscribed to all three lists, I'd ask that they go either to [EMAIL PROTECTED] or [EMAIL PROTECTED] The history of the discussions is just as important as the actual code commits. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ASF c:\program files location [was Re: Default Tomcat installation location on Windows]
From: Dominik Drzewiecki [EMAIL PROTECTED] Sent: Sunday, December 28, 2003 3:47 PM The default location for Tomcat 5.0 installation on Windows is c:\program Files\Apache Software Foundation\Tomcat 5.0. On the other hand, win32 Apache 2.0 installer suggests c:\Program Files\Apache Group\Apache 2.0. I suggest that these directories should be unified for clarity, let's say the default root directory for Apache softwere should be c:\Program Files\Apache Group. After all it is Apache's httpd that was first to come up with Apache Group directory ;). I think Tomcat 5.0.x as well as 4.1.x should stick with it (Maven does, AFAIK). I'd argue the converse, and suggest the httpd team will change this with the Apache-2.2 installer. It probably should have changed back at 2.0, I don't remember why I didn't make that change at the time. Apache Group as an entity is defunct, replaced by the corporate name Apache Software Foundation. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue and solution with tomcat 5.0.27 service on Windows
If java.home points to the JRE, this 'might' point you at a JDK - but it is
certainly an unwise choice for those who don't dereference a JRE, buried
within a JDK, as JAVA_HOME.
Which brings up a good point, you may have to modify the envvars of the
SYSTEM (LocalSystem) account, or whichever account you ask the
Tomcat service to run-as.
At 04:21 AM 8/12/2004, you wrote:
When I install the tomcat server 5.0.27 as a service, it's not able to compile any
.jsp page.
After some tests I found out, that in the file catalina.xml, the property tools.jar
is set to the location=${java.home}/../lib/tools.jar .
If you change the location to ${java.home}/lib/tools.jar the pages compile without
any problem.
It would be nice if one of the developers can have a look at this issue and apply a
patch.
regards
Jens
-
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] proxy status
At 11:19 AM 8/12/2004, Justin Erenkrantz wrote: --On Thursday, August 12, 2004 12:57 AM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Although he's subscribed to all three lists, I'd ask that they go either to [EMAIL PROTECTED] or [EMAIL PROTECTED] The history of the discussions is just as important as the actual code commits. Can we please not use [EMAIL PROTECTED] As long as the code resides in the main httpd repository, development discussion belongs on [EMAIL PROTECTED], IMHO. That seems rational to me. The reason for proposing [EMAIL PROTECTED] is so that tomcat-dev'ers wouldn't have to swallow the full bandwidth of [EMAIL PROTECTED] (converse of the problem where they asked anyone in [EMAIL PROTECTED] to follow [EMAIL PROTECTED] for the duration of that proxy_ajp development). So I ask our tomcat-dev'ers who are interested in proxy_ajp, proxy_balancer and so on - are you already subscribed/following [EMAIL PROTECTED] Or do you feel a -strong- need for a lower-traffic list? If no one complains loudly, we will keep all proxy traffic on [EMAIL PROTECTED] (cc's to tomcat-dev if you feel a point needs feedback from the tomcat connector folks.) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat build broken with strange javac error(never seen this one before)
At 02:20 PM 8/12/2004, Joshua Paul wrote: Stop sending me e-mail. Don't tell us - you subscribed. See the email headers in this message, specifically the List-Unsubscribe: header, and send a blank email to that address. When you subscribed, there was another email that told you how to unsubscribe later, it was the same email address. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
