Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

2005-09-21 Thread William A. Rowe, Jr.

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

2005-09-20 Thread William A. Rowe, Jr.

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

2005-09-16 Thread William A. Rowe, Jr.

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

2005-09-12 Thread William A. Rowe, Jr.

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

2005-09-12 Thread William A. Rowe, Jr.

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

2005-09-12 Thread William A. Rowe, Jr.

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]

2005-09-12 Thread William A. Rowe, Jr.

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?)

2005-09-12 Thread William A. Rowe, Jr.

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?

2005-09-08 Thread William A. Rowe, Jr.

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?

2005-09-08 Thread William A. Rowe, Jr.

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

2005-08-11 Thread William A. Rowe, Jr.
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

2005-08-10 Thread William A. Rowe, Jr.
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

2005-07-15 Thread William A. Rowe, Jr.
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

2005-07-12 Thread William A. Rowe, Jr.
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

2005-07-12 Thread William A. Rowe, Jr.
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

2005-07-12 Thread William A. Rowe, Jr.
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

2005-07-12 Thread William A. Rowe, Jr.
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

2005-07-12 Thread William A. Rowe, Jr.
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

2005-07-11 Thread William A. Rowe, Jr.
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 ?

2005-07-11 Thread William A. Rowe, Jr.
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

2005-07-06 Thread William A. Rowe, Jr.
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

2005-07-06 Thread William A. Rowe, Jr.
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

2005-06-29 Thread William A. Rowe, Jr.
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

2005-06-23 Thread William A. Rowe, Jr.
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

2005-06-20 Thread William A. Rowe, Jr.
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

2005-06-13 Thread William A. Rowe, Jr.
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?]

2005-06-07 Thread William A. Rowe, Jr.
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?]

2005-06-01 Thread William A. Rowe, Jr.
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

2005-05-12 Thread William A. Rowe, Jr.
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

2005-05-12 Thread William A. Rowe, Jr.

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/native2/server/isapi

2005-05-12 Thread William A. Rowe, Jr.

wrowe   2005/05/12 11:37:14

  Modified:jk/native2 README.txt CHANGES.txt STATUS.txt
   jk/native2/server/isapi install4iis.js
  Log:
Whitespace changes only to this inactive repository - fix all ^M bogosity
  
  Revision  ChangesPath
  1.7   +5 -5  jakarta-tomcat-connectors/jk/native2/README.txt
  
  Index: README.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/README.txt,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- README.txt7 Dec 2004 12:03:48 -   1.6
  +++ README.txt12 May 2005 18:37:14 -  1.7
  @@ -1,12 +1,12 @@
   README for JK2
   --
   
  -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.
   
   
  
  
  
  1.18  +1 -1  jakarta-tomcat-connectors/jk/native2/CHANGES.txt
  
  
  
  
  1.7   +6 -6  jakarta-tomcat-connectors/jk/native2/STATUS.txt
  
  Index: STATUS.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/STATUS.txt,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- STATUS.txt7 Dec 2004 12:03:48 -   1.6
  +++ STATUS.txt12 May 2005 18:37:14 -  1.7
  @@ -1,12 +1,12 @@
   JAKARTA TOMCAT CONNECTORS 2 (JK2) STATUS:-*-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.
   
   Release:
  
  
  
  1.7   +516 -516  
 jakarta-tomcat-connectors/jk/native2/server/isapi/install4iis.js
  
  Index: install4iis.js
  ===
  RCS file: 
 /home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/install4iis.js,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- install4iis.js7 Jun 2004 23:58:17 -   1.6
  +++ install4iis.js12 May 2005 18:37:14 -  1.7
  @@ -1,516 +1,516 @@
  -/*
  - *  Copyright 1999-2004 The Apache Software Foundation
  - *
  - *  Licensed under the Apache License, Version 2.0 (the License);
  - *  you may not use this file except in compliance with the License.
  - *  You may obtain a copy of the License at
  - *
  - *  http://www.apache.org/licenses/LICENSE-2.0
  - *
  - *  Unless required by applicable law or agreed to in writing, software
  - *  distributed under the License is distributed on an AS IS BASIS,
  - *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  - *  See the License for the specific language governing permissions and
  - *  limitations under the License.
  - */
  -
  -/**
  - * Description: Install script for Tomcat JK2 ISAPI redirector
  - * Author:  Mladen Turk [EMAIL PROTECTED]   
  - * Version: $Revision$   
  - */
  -
  -
  -/**
  - * Global variables
  - */
  -//var IIsWebService;
  -//var IIsWebServer;
  -//var IIsROOT;
  -//var AppParams;
  -
  -/**
  - * Defaults
  - */
  -_DEFAULT_SERVER_NAME = Default Web Site;
  -_DEFAULT_DESCRIPTION = JK2 ISAPI Redirector;
  -_DEFAULT_FILTER_NAME = jakarta;
  -_DEFAULT_HEADERS = X-Powered-By: Apache Software Foundation
  -_DEFAULT_OPTIONS = rbdi;
  -_DEFAULT_REGISTRY= HKLM\\SOFTWARE\\Apache Software Foundation\\Jakarta 
 Isapi Redirector\\2.0;
  -_DEFAULT_FILTERLIB   = isapi_redirector2.dll;
  -_DEFAULT_WORKERS2= \\conf\\workers2.properties;
  -
  -/**
  - * Set this to false to disable TRACE messages;
  - */
  -_DEBUG = true;
  -_TRACE_COUNTER = 1;
  -
  -/**
  - * Constants variables
  - */
  -_APP_INPROC  = 0;
  -_APP_OUTPROC = 1;
  -_APP_POOLED  = 2
  -_IIS_OBJECT  = IIS://LocalHost/W3SVC;
  -_IIS_SERVER  = IIsWebServer;
  -_IIS_WEBDIR  = IIsWebVirtualDir;
  -_IIS_FILTERS = IIsFilters;
  

cvs commit: jakarta-tomcat-connectors/jk/native/nt_service nt_service.dsp

2005-05-12 Thread William A. Rowe, Jr.

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

2005-05-12 Thread William A. Rowe, Jr.

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

2005-05-12 Thread William A. Rowe, Jr.

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

2005-05-12 Thread William A. Rowe, Jr.

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

2005-05-12 Thread William A. Rowe, Jr.
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?

2005-05-11 Thread William A. Rowe, Jr.
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?

2005-05-11 Thread William A. Rowe, Jr.
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?

2005-05-11 Thread William A. Rowe, Jr.
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?

2005-05-11 Thread William A. Rowe, Jr.
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

2005-05-10 Thread William A. Rowe, Jr.
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

2005-05-09 Thread William A. Rowe, Jr.
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

2005-05-09 Thread William A. Rowe, Jr.
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

2005-05-07 Thread William A. Rowe, Jr.
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

2005-05-07 Thread William A. Rowe, Jr.
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

2005-05-06 Thread William A. Rowe, Jr.
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

2005-04-27 Thread William A. Rowe, Jr.
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

2005-04-27 Thread William A. Rowe, Jr.
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

2005-04-27 Thread William A. Rowe, Jr.
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

2005-04-26 Thread William A. Rowe, Jr.
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

2005-04-26 Thread William A. Rowe, Jr.
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

2005-04-26 Thread William A. Rowe, Jr.
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

2005-04-26 Thread William A. Rowe, Jr.
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

2005-04-26 Thread William A. Rowe, Jr.
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

2005-04-18 Thread William A. Rowe, Jr.
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

2005-04-13 Thread William A. Rowe, Jr.
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

2005-03-31 Thread William A. Rowe, Jr.
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

2005-03-29 Thread William A. Rowe, Jr.
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?

2005-03-29 Thread William A. Rowe, Jr.
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

2005-03-14 Thread William A. Rowe, Jr.
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...

2005-03-07 Thread William A. Rowe, Jr.
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

2005-02-22 Thread William A. Rowe, Jr.
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

2005-02-21 Thread William A. Rowe, Jr.
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

2005-02-21 Thread William A. Rowe, Jr.
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

2005-02-18 Thread William A. Rowe, Jr.
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

2005-02-18 Thread William A. Rowe, Jr.
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)

2005-02-01 Thread William A. Rowe, Jr.
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)

2005-01-27 Thread William A. Rowe, Jr.
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)

2005-01-27 Thread William A. Rowe, Jr.
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)

2005-01-19 Thread William A. Rowe, Jr.
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.

2005-01-18 Thread William A. Rowe, Jr.
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.

2005-01-18 Thread William A. Rowe, Jr.
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

2005-01-13 Thread William A. Rowe, Jr.
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

2005-01-13 Thread William A. Rowe, Jr.
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

2005-01-13 Thread William A. Rowe, Jr.
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

2005-01-12 Thread William A. Rowe, Jr.
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

2005-01-12 Thread William A. Rowe, Jr.
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

2005-01-11 Thread William A. Rowe, Jr.
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

2005-01-11 Thread William A. Rowe, Jr.
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.

2004-12-23 Thread William A. Rowe, Jr.
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

2004-12-23 Thread William A. Rowe, Jr.
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.

2004-12-23 Thread William A. Rowe, Jr.
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.

2004-12-23 Thread William A. Rowe, Jr.
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

2004-12-23 Thread William A. Rowe, Jr.
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.

2004-12-23 Thread William A. Rowe, Jr.
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?

2004-12-23 Thread William A. Rowe, Jr.
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

2004-12-22 Thread William A. Rowe, Jr.
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

2004-12-22 Thread William A. Rowe, Jr.
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

2004-12-22 Thread William A. Rowe, Jr.
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

2004-12-22 Thread William A. Rowe, Jr.
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

2004-12-22 Thread William A. Rowe, Jr.
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

2004-12-22 Thread William A. Rowe, Jr.
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?

2004-12-16 Thread William A. Rowe, Jr.
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

2004-11-18 Thread William A. Rowe, Jr.
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

2004-09-02 Thread William A. Rowe, Jr.
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

2004-09-02 Thread William A. Rowe, Jr.
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

2004-08-12 Thread William A. Rowe, Jr.
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]

2004-08-12 Thread William A. Rowe, Jr.

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

2004-08-12 Thread William A. Rowe, Jr.
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

2004-08-12 Thread William A. Rowe, Jr.
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]



  1   2   >