You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rainer Jung <rj...@apache.org> on 2006/07/12 02:24:10 UTC
Next try: mod_jk 1.2.17 release candidate ready to test
Hi,
thanks to everyone who tested 1.2.16. Unfortunately we had one
regression bug in the status worker (hanging update request because of
double locking). For full results please see:
http://marc.theaimsgroup.com/?l=tomcat-dev&m=115234851210076&w=2
Today version 1.2.17 of the Apache Tomcat mod_jk web server connector
has been tagged. This version fixes the new bugs from 1.2.16 and adds
one improvement. Please test and share your experience.
If no critical bugs will be found, we will have a formal release vote
starting at Saturday, July 15th.
The source distribution can be downloaded from:
http://tomcat.apache.org/dev/dist/
The updated documentation can be found at
http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/
Please see
http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/changelog.html
for a complete list of changes.
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.18
Posted by Rainer Jung <ra...@kippdata.de>.
Hello,
since we've already got 4 "stable" votes I would like to close the vote
early and publish the release.
So if anyone is still testing and wants to participate in the vote,
please let me know. Otherwise I'll post the results tomorrow at about 5
p.m. GMT and publish the release.
Thank's for your participation in the vote!
Rainer
Rainer Jung schrieb:
> Hello to all Tomcat project members,
>
> after 2 unsuccessful release attempts for mod_jk it looks like 1.2.18
> doesn't get any bug reports. All known bugs related to 1.2.16 and 1.2.17
> have been fixed in 1.2.18. About 20 users downloaded 1.2.16 and 1.2.17
> each, and 11 downloads happened for 1.2.18 (until yesterday). I think we
> got good feedback from the community.
>
> Although I announced the availability of the 1.2.18 release candidate
> only 4 days ago (see
> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115336261231270&w=2 ), I
> would like to start a release vote. Somehow I partially count the days
> of 1.2.16 and 1.2.17 testing, because changes for 1.2.18 have been very
> small.
>
> If you want to take a look, the source distribution can be downloaded from:
>
> http://tomcat.apache.org/dev/dist/
>
> The updated documentation can be found at
>
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/
>
> Please see
>
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html
>
> for a complete list of changes.
>
> So here's the vote, which will be open until Friday July 28th, 24:00 GMT.
>
> Apache Tomcat Connectors 1.2.18 is:
> [ ] Stable - no major issues, no regressions
> [ ] Beta - at least one significant issue -- tell us what it is
> [ ] Alpha - multiple significant issues -- tell us what they are
>
> Thank you,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.18
Posted by Jean-frederic Clere <jf...@gmail.com>.
Stable.
Cheers
Jean-Frederic
Rainer Jung wrote:
> Hello to all Tomcat project members,
>
> after 2 unsuccessful release attempts for mod_jk it looks like 1.2.18
> doesn't get any bug reports. All known bugs related to 1.2.16 and
> 1.2.17 have been fixed in 1.2.18. About 20 users downloaded 1.2.16 and
> 1.2.17 each, and 11 downloads happened for 1.2.18 (until yesterday). I
> think we got good feedback from the community.
>
> Although I announced the availability of the 1.2.18 release candidate
> only 4 days ago (see
> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115336261231270&w=2 ), I
> would like to start a release vote. Somehow I partially count the days
> of 1.2.16 and 1.2.17 testing, because changes for 1.2.18 have been
> very small.
>
> If you want to take a look, the source distribution can be downloaded
> from:
>
> http://tomcat.apache.org/dev/dist/
>
> The updated documentation can be found at
>
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/
>
> Please see
>
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html
>
> for a complete list of changes.
>
> So here's the vote, which will be open until Friday July 28th, 24:00 GMT.
>
> Apache Tomcat Connectors 1.2.18 is:
> [ ] Stable - no major issues, no regressions
> [ ] Beta - at least one significant issue -- tell us what it is
> [ ] Alpha - multiple significant issues -- tell us what they are
>
> Thank you,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.18
Posted by Rainer Jung <ra...@kippdata.de>.
> Apache Tomcat Connectors 1.2.18 is:
> [X] Stable - no major issues, no regressions
> [ ] Beta - at least one significant issue -- tell us what it is
> [ ] Alpha - multiple significant issues -- tell us what they are
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.18
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
> So here's the vote, which will be open until Friday July 28th, 24:00 GMT.
>
> Apache Tomcat Connectors 1.2.18 is:
> [ X ] Stable - no major issues, no regressions
> [ ] Beta - at least one significant issue -- tell us what it is
> [ ] Alpha - multiple significant issues -- tell us what they are
I did much more limited testing than other people, but it seems to
compile and run fine (under light load) on Fedora Core 5.
Also great job Rainer steering this through.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.18
Posted by Henri Gomez <he...@gmail.com>.
Stable
2006/7/24, Mladen Turk <mt...@apache.org>:
> Rainer Jung wrote:
> > Apache Tomcat Connectors 1.2.18 is:
> > [X] Stable - no major issues, no regressions
> > [ ] Beta - at least one significant issue -- tell us what it is
> > [ ] Alpha - multiple significant issues -- tell us what they are
> >
>
> BTW, excellent job Rainer!
>
> --
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.18
Posted by Rainer Jung <ra...@kippdata.de>.
In case of further questions, please start a new thread, this one is
only for the voting.
In short: 1.2.17 had a subtle build problem e.g. on AS400 platform.
There is no known trouble on Linux. Glad to hear it also worked for you,
but you should nevertheless take the next opportunity and move to the
official release. 1.2.17 will never be officially released. Furthermore
1.2.18 added a new minor enhancement, the recovery time is now allowed
below 60 seconds.
Rainer
Mohan Wickramasinghe wrote:
> Please tell what the issue was with 1.2.17 ?
> Have being using it in linux from time of release.
>
> Thanks
>
> On Mon, 2006-07-24 at 13:07 +0200, Peter Rossbach wrote:
>
>>Stable,
>>
>>really cool community driven release. :-)
>>
>>Peter
>>
>>Am 24.07.2006 um 12:13 schrieb Mladen Turk:
>>
>>
>>>Rainer Jung wrote:
>>>
>>>>Apache Tomcat Connectors 1.2.18 is:
>>>>[X] Stable - no major issues, no regressions
>>>>[ ] Beta - at least one significant issue -- tell us what it is
>>>>[ ] Alpha - multiple significant issues -- tell us what they are
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.18
Posted by Mohan Wickramasinghe <mo...@roomsnet.com>.
Please tell what the issue was with 1.2.17 ?
Have being using it in linux from time of release.
Thanks
On Mon, 2006-07-24 at 13:07 +0200, Peter Rossbach wrote:
> Stable,
>
> really cool community driven release. :-)
>
> Peter
>
> Am 24.07.2006 um 12:13 schrieb Mladen Turk:
>
> > Rainer Jung wrote:
> >> Apache Tomcat Connectors 1.2.18 is:
> >> [X] Stable - no major issues, no regressions
> >> [ ] Beta - at least one significant issue -- tell us what it is
> >> [ ] Alpha - multiple significant issues -- tell us what they are
> >
>
--
Mohan Wickramasinghe <mo...@roomsnet.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.18
Posted by Peter Rossbach <pr...@objektpark.de>.
Stable,
really cool community driven release. :-)
Peter
Am 24.07.2006 um 12:13 schrieb Mladen Turk:
> Rainer Jung wrote:
>> Apache Tomcat Connectors 1.2.18 is:
>> [X] Stable - no major issues, no regressions
>> [ ] Beta - at least one significant issue -- tell us what it is
>> [ ] Alpha - multiple significant issues -- tell us what they are
>
Re: [VOTE] Releasing Tomcat Connectors 1.2.18
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
> Apache Tomcat Connectors 1.2.18 is:
> [X] Stable - no major issues, no regressions
> [ ] Beta - at least one significant issue -- tell us what it is
> [ ] Alpha - multiple significant issues -- tell us what they are
>
BTW, excellent job Rainer!
--
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[VOTE] Releasing Tomcat Connectors 1.2.18
Posted by Rainer Jung <ra...@kippdata.de>.
Hello to all Tomcat project members,
after 2 unsuccessful release attempts for mod_jk it looks like 1.2.18
doesn't get any bug reports. All known bugs related to 1.2.16 and 1.2.17
have been fixed in 1.2.18. About 20 users downloaded 1.2.16 and 1.2.17
each, and 11 downloads happened for 1.2.18 (until yesterday). I think we
got good feedback from the community.
Although I announced the availability of the 1.2.18 release candidate
only 4 days ago (see
http://marc.theaimsgroup.com/?l=tomcat-dev&m=115336261231270&w=2 ), I
would like to start a release vote. Somehow I partially count the days
of 1.2.16 and 1.2.17 testing, because changes for 1.2.18 have been very
small.
If you want to take a look, the source distribution can be downloaded from:
http://tomcat.apache.org/dev/dist/
The updated documentation can be found at
http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/
Please see
http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html
for a complete list of changes.
So here's the vote, which will be open until Friday July 28th, 24:00 GMT.
Apache Tomcat Connectors 1.2.18 is:
[ ] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are
Thank you,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Steve,
>> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html
>>
>> for a complete list of changes.
>> This link appears to be broken (404 Not Found) :(
> Works fine for me, the url does wrap so make sure you have the entire url copy/pasted.
Hmm... wasn't working before, but now it is. I even tried moving up the
URL / by / and I didn't find anything until here:
http://tomcat.apache.org/dev/
Perhaps I just looked before the site was re-built or something.
<shrug>
-chris
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Steve Ochani <oc...@ncc.edu>.
Date sent: Thu, 20 Jul 2006 08:16:41 -0400
From: Christopher Schultz <ch...@christopherschultz.net>
Subject: Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
To: Tomcat Users List <us...@tomcat.apache.org>
Send reply to: Tomcat Users List <us...@tomcat.apache.org>
> Rainer,
>
> > Please see
> >
> > http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog
> > .html
> >
> > for a complete list of changes.
>
> This link appears to be broken (404 Not Found) :(
>
Works fine for me, the url does wrap so make sure you have the entire url copy/pasted.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
Whops: we had some hassle with the files and it looks like the docs has
been unintentionally erased by myself. It's there on the source web
server now, thanks for the information.
It might take an hour or two to replicate to the public web server. If
you need it earlier: the docs are included in the download as well.
Regards,
Rainer
Christopher Schultz wrote:
> Rainer,
>
>
>>Please see
>>
>>http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html
>>
>>for a complete list of changes.
>
>
> This link appears to be broken (404 Not Found) :(
>
> -chris
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Rainer,
> Please see
>
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html
>
> for a complete list of changes.
This link appears to be broken (404 Not Found) :(
-chris
Re: Mod_JK / Tomcat : How does Tomcat know its name in mod_jk side?
Posted by ga...@free.fr.
Thanks
Quoting Rainer Jung <ra...@kippdata.de>:
> The name associated with each worker must match the one used for the
> jvmRoute attribute specified on the Engine element of the corresponding
> node's server.xml.
>
> It's not explicitely passed via AJP. You need to keep the names in
> workers.properties/server.xml in sync by yourself.
>
> Rainer
>
> gaston.azerty@free.fr wrote:
> > Hi,
> >
> > I'm always working on mod_jk and I have got a question about cookie
> generation
> > on the Tomcat side.
> > When a request has been send by a new client, he obtains a Cookie, this
> cookie
> > has been generated by Tomcat (worker). In this cookie, we find the route to
> the
> > correct worker for the next request (JSESSIONID=EF45..B01.worker1, worker1
> is
> > the route) (if sticky_session is on), but how Tomcat knows that his name in
> > mod_jk side is "worker1"?
> > Where this information has been sent in the ajp protocol?
> >
> > Regards,
> >
> > Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Mod_JK / Tomcat : How does Tomcat know its name in mod_jk side?
Posted by Rainer Jung <ra...@kippdata.de>.
The name associated with each worker must match the one used for the
jvmRoute attribute specified on the Engine element of the corresponding
node's server.xml.
It's not explicitely passed via AJP. You need to keep the names in
workers.properties/server.xml in sync by yourself.
Rainer
gaston.azerty@free.fr wrote:
> Hi,
>
> I'm always working on mod_jk and I have got a question about cookie generation
> on the Tomcat side.
> When a request has been send by a new client, he obtains a Cookie, this cookie
> has been generated by Tomcat (worker). In this cookie, we find the route to the
> correct worker for the next request (JSESSIONID=EF45..B01.worker1, worker1 is
> the route) (if sticky_session is on), but how Tomcat knows that his name in
> mod_jk side is "worker1"?
> Where this information has been sent in the ajp protocol?
>
> Regards,
>
> Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Mod_JK / Tomcat : How does Tomcat know its name in mod_jk side?
Posted by ga...@free.fr.
Hi,
I'm always working on mod_jk and I have got a question about cookie generation
on the Tomcat side.
When a request has been send by a new client, he obtains a Cookie, this cookie
has been generated by Tomcat (worker). In this cookie, we find the route to the
correct worker for the next request (JSESSIONID=EF45..B01.worker1, worker1 is
the route) (if sticky_session is on), but how Tomcat knows that his name in
mod_jk side is "worker1"?
Where this information has been sent in the ajp protocol?
Regards,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Henri Gomez <he...@gmail.com>.
It build without problem on iSeries V5R3.
2006/7/20, Rainer Jung <ra...@kippdata.de>:
> Thanks a lot! The lineends.pl looks nice, because it does a lot of the
> heuristics one needs to make it a little more stable.
>
> I added md5 and sha, because I followed some ASF discussions that
> suggested keeping the hashes. The signature file will only be used by
> people who really want to find out about the correctness and origin of
> the file, but because it needs a little knowledge about pgp/gpg many
> people only check hashes. And md5 seems to be a little outdated, that's
> why I added sha1 and sha256.
>
> Thanks again for fixing the zip. I'll add the fix later to the jkrelease.sh.
>
> Rainer
>
> Mladen Turk wrote:
> > Rainer Jung wrote:
> >
> >> To find out, why this is so: did you get the same VStudio complains
> >> for 1.2.16 or 17? I tought you built those?
> >> I would suggest to just repack the zip, since there is no change in
> >> repository and no official release yet.
> >>
> >
> > OK.
> > I have used your zip file and simply run
> > the perl lineends.pl
> > It's inside /dev/dist instead the old one.
> >
> > Also, think we only need the .asc signature
> > for files.
> >
> > Regards,
> > Mladen.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
Thanks a lot! The lineends.pl looks nice, because it does a lot of the
heuristics one needs to make it a little more stable.
I added md5 and sha, because I followed some ASF discussions that
suggested keeping the hashes. The signature file will only be used by
people who really want to find out about the correctness and origin of
the file, but because it needs a little knowledge about pgp/gpg many
people only check hashes. And md5 seems to be a little outdated, that's
why I added sha1 and sha256.
Thanks again for fixing the zip. I'll add the fix later to the jkrelease.sh.
Rainer
Mladen Turk wrote:
> Rainer Jung wrote:
>
>> To find out, why this is so: did you get the same VStudio complains
>> for 1.2.16 or 17? I tought you built those?
>> I would suggest to just repack the zip, since there is no change in
>> repository and no official release yet.
>>
>
> OK.
> I have used your zip file and simply run
> the perl lineends.pl
> It's inside /dev/dist instead the old one.
>
> Also, think we only need the .asc signature
> for files.
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
> To find out, why this is so: did you get the same VStudio complains for
> 1.2.16 or 17? I tought you built those?
> I would suggest to just repack the zip, since there is no change in
> repository and no official release yet.
>
OK.
I have used your zip file and simply run
the perl lineends.pl
It's inside /dev/dist instead the old one.
Also, think we only need the .asc signature
for files.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
> To find out, why this is so: did you get the same VStudio complains for
> 1.2.16 or 17? I tought you built those?
> I would suggest to just repack the zip, since there is no change in
> repository and no official release yet.
>
Well, it's just packing, and its RM responsibility :)
I didn't compile from the .zip file, but from the SVN Tag,
and it has correct line endings when checkedout on win.
You can simply use something like:
svn export "${JK_SVN_URL}/jk" --native-eol CRLF ${JK_DIST}.tmp/jk
for DOS line endings, and use that as base
for the .zip file.
Or simple use the lineends.pl from apr/build
perl lineends.pl tomcat-connectors-1.2.18-src/
and then create the .zip.
Think that the later is more simple.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
To find out, why this is so: did you get the same VStudio complains for
1.2.16 or 17? I tought you built those?
I would suggest to just repack the zip, since there is no change in
repository and no official release yet.
Mladen Turk wrote:
> Rainer Jung wrote:
>> Hi,
>>
>> http://tomcat.apache.org/dev/dist/
>>
>
> The .zip files have Unix line endings.
> At least all .dsp and .dsw files *needs* to
> have the DOS line endings, because VStudio
> complains about corrupted project files.
>
> This is only needed for .zip files.
>
>
> Also,
> http://tomcat.apache.org/dev/dist/win32/
> contains binaries.
>
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
--
kippdata informationstechnologie GmbH
Bornheimer Str. 33a
53111 Bonn
Tel.: 0228/98549-0
Fax: 0228/98549-50
www.kippdata.de
=======================
kippdata informationstechnologie GmbH
Bornheimer Str. 33a
D-53111 Bonn
Tel.: +49/0228/98549-0
Fax: +49/0228/98549-50
www.kippdata.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
I think I need to change the script for the Win case:
- export with CRLF endings
- fix auto*-generated files with unix2dos
- maybe (need to check) fix all generated docs files/NEWS/CHANGES except
images
- zip it
Using "-l" on the zip would be easier, but might break:
- gif, ico
- ./native/iis/installer/License.rtf
- ./native/iis/installer/isapi-redirector-win32-msi.ism
So we would need to maintain a list, which files need to be excluded in
the "-l". I think it ill be easier to rely on svn and keep the eol
information there.
Mladen Turk wrote:
> Rainer Jung wrote:
>> Hi,
>>
>> http://tomcat.apache.org/dev/dist/
>>
>
> The .zip files have Unix line endings.
> At least all .dsp and .dsw files *needs* to
> have the DOS line endings, because VStudio
> complains about corrupted project files.
>
> This is only needed for .zip files.
>
>
> Also,
> http://tomcat.apache.org/dev/dist/win32/
> contains binaries.
>
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
--
kippdata informationstechnologie GmbH
Bornheimer Str. 33a
53111 Bonn
Tel.: 0228/98549-0
Fax: 0228/98549-50
www.kippdata.de
=======================
kippdata informationstechnologie GmbH
Bornheimer Str. 33a
D-53111 Bonn
Tel.: +49/0228/98549-0
Fax: +49/0228/98549-50
www.kippdata.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
> Hi,
>
> http://tomcat.apache.org/dev/dist/
>
The .zip files have Unix line endings.
At least all .dsp and .dsw files *needs* to
have the DOS line endings, because VStudio
complains about corrupted project files.
This is only needed for .zip files.
Also,
http://tomcat.apache.org/dev/dist/win32/
contains binaries.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by GB Developer <gb...@globallyboundless.com>.
Any reason the section titling on that page is so confusing?
"Changes from the released JK 1.2.18" makes me think I'm looking at the
changes that have been made *since* 1.2.18 and will be included in some, as
yet un-numbered, future release. If that's actually correct... you mean I
have to make the mental calcuation "I want to know what changed in version
x, therefore look for a title that says version x-1" every time I look at a
changelog?
I'd suggest a tile like "JK 1.2.18 Changes" or even just "JK 1.2.18" (as it
is for TC).
Just a nit, thought I'd pick it.
----- Original Message -----
From: "Rainer Jung" <ra...@kippdata.de>
To: "Tomcat Developers List" <de...@tomcat.apache.org>
Cc: <us...@tomcat.apache.org>
Sent: Wednesday, July 19, 2006 9:32 PM
Subject: Yet another try: mod_jk 1.2.18 release candidate ready to test
> Hi,
>
> thanks to everyone who tested 1.2.17. We had one bug related to special
> types used in the networking code. Furthermore there was one request for
> enhancement we included in the next version 1.2.18.
>
> Today this version 1.2.18 of the Apache Tomcat mod_jk web server connector
> has been tagged. This version fixes the found bugs from 1.2.17. Please
> test and share your experience.
>
> If no critical bugs will be found, we will have a formal release vote
> starting at Monday, July 24th.
>
> The source distribution can be downloaded from:
>
> http://tomcat.apache.org/dev/dist/
>
> The updated documentation can be found at
>
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/
>
> Please see
>
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html
>
> for a complete list of changes.
>
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
Hi,
thanks to everyone who tested 1.2.17. We had one bug related to special
types used in the networking code. Furthermore there was one request for
enhancement we included in the next version 1.2.18.
Today this version 1.2.18 of the Apache Tomcat mod_jk web server
connector has been tagged. This version fixes the found bugs from
1.2.17. Please test and share your experience.
If no critical bugs will be found, we will have a formal release vote
starting at Monday, July 24th.
The source distribution can be downloaded from:
http://tomcat.apache.org/dev/dist/
The updated documentation can be found at
http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/
Please see
http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html
for a complete list of changes.
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Yet another try: mod_jk 1.2.18 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
Hi,
thanks to everyone who tested 1.2.17. We had one bug related to special
types used in the networking code. Furthermore there was one request for
enhancement we included in the next version 1.2.18.
Today this version 1.2.18 of the Apache Tomcat mod_jk web server
connector has been tagged. This version fixes the found bugs from
1.2.17. Please test and share your experience.
If no critical bugs will be found, we will have a formal release vote
starting at Monday, July 24th.
The source distribution can be downloaded from:
http://tomcat.apache.org/dev/dist/
The updated documentation can be found at
http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/
Please see
http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html
for a complete list of changes.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.19
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 20, 2006, at 6:19 PM, Rainer Jung wrote:
> Apache Tomcat Connectors 1.2.19 is:
> [X] Stable - no major issues, no regressions
> [ ] Beta - at least one significant issue -- tell us what it is
> [ ] Alpha - multiple significant issues -- tell us what they are
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.19
Posted by Rainer Jung <ra...@kippdata.de>.
> Apache Tomcat Connectors 1.2.19 is:
> [X] Stable - no major issues, no regressions
> [ ] Beta - at least one significant issue -- tell us what it is
> [ ] Alpha - multiple significant issues -- tell us what they are
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.19
Posted by "William L. Thomson Jr." <wl...@gentoo.org>.
Apache Tomcat Connectors 1.2.19 is:
[X] Stable - no major issues, no regressions
--
William L. Thomson Jr.
Gentoo/Java
Re: [VOTE] Releasing Tomcat Connectors 1.2.19
Posted by Peter Rossbach <pr...@objektpark.de>.
Am 21.09.2006 um 00:19 schrieb Rainer Jung:
> Apache Tomcat Connectors 1.2.19 is:
> [x ] Stable - no major issues, no regressions
Yeap, works for me..
Tested with Suse Linux, Windows and MAC OSX Apache 2.0.58, Tomcat
5.5.17, 5.5.20, 4.1.34
Peter
Re: [VOTE] Releasing Tomcat Connectors 1.2.19
Posted by Henri Gomez <he...@gmail.com>.
[X] Stable - no major issues, no regressions
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Releasing Tomcat Connectors 1.2.19
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
>
> Apache Tomcat Connectors 1.2.19 is:
> [X] Stable - no major issues, no regressions
Regards,
Mladen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[VOTE] Releasing Tomcat Connectors 1.2.19
Posted by Rainer Jung <ra...@kippdata.de>.
Hello to all Tomcat project members,
mod_jk 1.2.19 has been available for testing for nearly 4 days now.
For those interested, these are the download numbers for the first three
days:
10 source/jk-1.2.19/tomcat-connectors-1.2.19-src.tar.gz
1 source/jk-1.2.19/tomcat-connectors-1.2.19-src.zip
17 win32/jk-1.2.19/mod_jk-apache-1.3.37.so
56 win32/jk-1.2.19/mod_jk-apache-2.0.58.so
77 win32/jk-1.2.19/mod_jk-apache-2.2.3.so
53 win32/jk-1.2.19/isapi_redirect.dll
2 win64/jk-1.2.19/amd64/isapi_redirect.dll
33 win32/jk-1.2.19/jk_symbols.zip
14 win32/jk-1.2.19/nsapi_redirect.dll
1 iseries/jk-1.2.19/MOD_JK1219.SAVF.gz
(iseries was a googlebot :) )
and we had 33 views at the changelog.
No new bugs have been reported so far, so I would like to proceed with
the release vote.
If you want to take a look, the source distribution can be downloaded from:
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/
The updated documentation can be found at
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.19/docs/
So here's the vote, which will be open until Saturday September 23rd,
24:00 GMT.
Apache Tomcat Connectors 1.2.19 is:
[ ] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are
Thank you,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Henri Gomez <he...@gmail.com>.
Thanks !
2006/7/17, Mladen Turk <mt...@apache.org>:
> Henri Gomez wrote:
> > What the status of mod_jk 1.2.17 ?
> >
> > It would be usefull to get some binaries to help users check against
> > their platform, for instance win32.
> >
>
> http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/
> Wait for a while until synced.
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
>
> IF 1.2.17 sources aren't at www. then, well, the binaries don't belong
> there either.
>
Simply used the current method.
Was not aware of the new repo inside tomcat.
Should I delete them or what?
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Mladen Turk wrote:
>> Rainer Jung wrote:
>>> Hi Mladen,
>>>
>>> would you mind putting it on
>>>
>>> http://tomcat.apache.org/dev/dist/
>>>
>>> first?
>>>
>>
>> Nope. There is no version/platform directory
>> structure inside.
>
> Uhm - then create one? /dev/dist/ has the distinction of containing
> anything any RM wants to create. www.apache.org has the distinction
> of containing only apache.org released code.
>
> I'm happy to see tomcat picked the /dev/dist/ tree to distinguish
> the candidates! Binaries have got to obey the same process as source.
Actually, deserves further clarification... IF 1.2.17 is moved to www.
then all is well, the person who rolls the binaries chooses if they want
folks to test it first in /dev/dist/, or they are putting it straight
into the www. tree. E.g., after major changes to the windows installer,
even with a released package, I'll drop these to /dev/dist/ and ask folks
to check out the installer changes before they get swept up by the mirrors
and widely used.
IF 1.2.17 sources aren't at www. then, well, the binaries don't belong
there either.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
> Rainer Jung wrote:
>> Hi Mladen,
>>
>> would you mind putting it on
>>
>> http://tomcat.apache.org/dev/dist/
>>
>> first?
>>
>
> Nope. There is no version/platform directory
> structure inside.
Uhm - then create one? /dev/dist/ has the distinction of containing
anything any RM wants to create. www.apache.org has the distinction
of containing only apache.org released code.
I'm happy to see tomcat picked the /dev/dist/ tree to distinguish
the candidates! Binaries have got to obey the same process as source.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
> Hi Mladen,
>
> would you mind putting it on
>
> http://tomcat.apache.org/dev/dist/
>
> first?
>
Nope. There is no version/platform directory
structure inside.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Mladen,
would you mind putting it on
http://tomcat.apache.org/dev/dist/
first?
Many thanks for the Win-Builds!
Regards,
Rainer
Mladen Turk wrote:
> Henri Gomez wrote:
>
>> What the status of mod_jk 1.2.17 ?
>>
>> It would be usefull to get some binaries to help users check against
>> their platform, for instance win32.
>>
>
> http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/
> Wait for a while until synced.
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> What the status of mod_jk 1.2.17 ?
>
> It would be usefull to get some binaries to help users check against
> their platform, for instance win32.
>
http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/
Wait for a while until synced.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Henri Gomez <he...@gmail.com>.
What the status of mod_jk 1.2.17 ?
It would be usefull to get some binaries to help users check against
their platform, for instance win32.
Regards
2006/7/13, Henri Gomez <he...@gmail.com>:
> 2006/7/13, Jean-frederic Clere <jf...@gmail.com>:
> > Henri Gomez wrote:
> >
> > > I don't know if we could called it a regression but the API spec is to
> > > used a socklen_t not an int or unsigned int.
> > >
> > > iSeries compiler is very strict on such 'cast' and probably some
> > > others. gcc is a little more conciliant :)
> > >
> > > BTW, I think next major version of mod_jk (1.3 / 3.x ?) should use APR
> > > to be simpler and better integrated in Apache 2.x
> >
> > Use mod_proxy for that ;-)
>
> There was discussion about next version / evolution of mod_jk, and I
> feel we should make use of APR to stop battling about OS dependencies
> on all IO/SYS system calls.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Henri Gomez <he...@gmail.com>.
2006/7/13, Jean-frederic Clere <jf...@gmail.com>:
> Henri Gomez wrote:
>
> > I don't know if we could called it a regression but the API spec is to
> > used a socklen_t not an int or unsigned int.
> >
> > iSeries compiler is very strict on such 'cast' and probably some
> > others. gcc is a little more conciliant :)
> >
> > BTW, I think next major version of mod_jk (1.3 / 3.x ?) should use APR
> > to be simpler and better integrated in Apache 2.x
>
> Use mod_proxy for that ;-)
There was discussion about next version / evolution of mod_jk, and I
feel we should make use of APR to stop battling about OS dependencies
on all IO/SYS system calls.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Jean-frederic Clere <jf...@gmail.com>.
Henri Gomez wrote:
> I don't know if we could called it a regression but the API spec is to
> used a socklen_t not an int or unsigned int.
>
> iSeries compiler is very strict on such 'cast' and probably some
> others. gcc is a little more conciliant :)
>
> BTW, I think next major version of mod_jk (1.3 / 3.x ?) should use APR
> to be simpler and better integrated in Apache 2.x
Use mod_proxy for that ;-)
Cheers
Jean-Frederic
>
>
> 2006/7/13, Rainer Jung <ra...@kippdata.de>:
>
>> Hi Henri,
>>
>> thanks for reporting this. This has already been part of 1.2.16. I
>> thought you found only one bug for that platform, which we fixed
>> (unixd.h).
>>
>> I can build 1.2.17 on solaris 64 bit sparc, and on linux 32 bit and 64
>> bit AMD (both times SuSE Enterprise 9).
>>
>> I get a couple of warnings, but not for this line.
>>
>> Of course you are riht, that we should be more careful here with types,
>> especially since we use two different types for rclen ind the same file.
>>
>> But is it a regression?
>>
>> Rainer
>>
>> Henri Gomez schrieb:
>> > jk 1.2.17 build failed on iSeries v5R3.
>> >
>> > /home/apache/jk/native/common/jk_connect.c, 198.38: CZM0280(30)
>> Function
>> > argument assignment between types "int*" and "unsigned int*" is not
>> > allowed.
>> >
>> > getsockopt on Linux is defined like this :
>> >
>> > int getsockopt(int s, int level, int optname, void *optval,
>> > socklen_t *optlen);
>> >
>> >
>> > rclen should be socklen_t instead of unsigned int...
>> >
>> > With this iSeries build without problems...
>> >
>> >> 2006/7/12, Rainer Jung <rj...@apache.org>:
>> >> Hi,
>> >>
>> >> thanks to everyone who tested 1.2.16. Unfortunately we had one
>> >> regression bug in the status worker (hanging update request
>> because of
>> >> double locking). For full results please see:
>> >>
>> >> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115234851210076&w=2
>> >>
>> >> Today version 1.2.17 of the Apache Tomcat mod_jk web server connector
>> >> has been tagged. This version fixes the new bugs from 1.2.16 and adds
>> >> one improvement. Please test and share your experience.
>> >>
>> >> If no critical bugs will be found, we will have a formal release vote
>> >> starting at Saturday, July 15th.
>> >>
>> >> The source distribution can be downloaded from:
>> >>
>> >> http://tomcat.apache.org/dev/dist/
>> >>
>> >> The updated documentation can be found at
>> >>
>> >> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/
>> >>
>> >> Please see
>> >>
>> >>
>> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/changelog.html
>>
>> >>
>> >> for a complete list of changes.
>> >>
>> >> Regards,
>> >>
>> >> Rainer
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> >> For additional commands, e-mail: dev-help@tomcat.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> > For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
How come, it worked for 1.2.16?
Henri Gomez schrieb:
> I don't know if we could called it a regression but the API spec is to
> used a socklen_t not an int or unsigned int.
>
> iSeries compiler is very strict on such 'cast' and probably some
> others. gcc is a little more conciliant :)
>
> BTW, I think next major version of mod_jk (1.3 / 3.x ?) should use APR
> to be simpler and better integrated in Apache 2.x
>
>
> 2006/7/13, Rainer Jung <ra...@kippdata.de>:
>> Hi Henri,
>>
>> thanks for reporting this. This has already been part of 1.2.16. I
>> thought you found only one bug for that platform, which we fixed
>> (unixd.h).
>>
>> I can build 1.2.17 on solaris 64 bit sparc, and on linux 32 bit and 64
>> bit AMD (both times SuSE Enterprise 9).
>>
>> I get a couple of warnings, but not for this line.
>>
>> Of course you are riht, that we should be more careful here with types,
>> especially since we use two different types for rclen ind the same file.
>>
>> But is it a regression?
>>
>> Rainer
>>
>> Henri Gomez schrieb:
>> > jk 1.2.17 build failed on iSeries v5R3.
>> >
>> > /home/apache/jk/native/common/jk_connect.c, 198.38: CZM0280(30)
>> Function
>> > argument assignment between types "int*" and "unsigned int*" is not
>> > allowed.
>> >
>> > getsockopt on Linux is defined like this :
>> >
>> > int getsockopt(int s, int level, int optname, void *optval,
>> > socklen_t *optlen);
>> >
>> >
>> > rclen should be socklen_t instead of unsigned int...
>> >
>> > With this iSeries build without problems...
>> >
>> >> 2006/7/12, Rainer Jung <rj...@apache.org>:
>> >> Hi,
>> >>
>> >> thanks to everyone who tested 1.2.16. Unfortunately we had one
>> >> regression bug in the status worker (hanging update request because of
>> >> double locking). For full results please see:
>> >>
>> >> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115234851210076&w=2
>> >>
>> >> Today version 1.2.17 of the Apache Tomcat mod_jk web server connector
>> >> has been tagged. This version fixes the new bugs from 1.2.16 and adds
>> >> one improvement. Please test and share your experience.
>> >>
>> >> If no critical bugs will be found, we will have a formal release vote
>> >> starting at Saturday, July 15th.
>> >>
>> >> The source distribution can be downloaded from:
>> >>
>> >> http://tomcat.apache.org/dev/dist/
>> >>
>> >> The updated documentation can be found at
>> >>
>> >> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/
>> >>
>> >> Please see
>> >>
>> >>
>> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/changelog.html
>> >>
>> >> for a complete list of changes.
>> >>
>> >> Regards,
>> >>
>> >> Rainer
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> >> For additional commands, e-mail: dev-help@tomcat.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> > For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Henri Gomez <he...@gmail.com>.
I don't know if we could called it a regression but the API spec is to
used a socklen_t not an int or unsigned int.
iSeries compiler is very strict on such 'cast' and probably some
others. gcc is a little more conciliant :)
BTW, I think next major version of mod_jk (1.3 / 3.x ?) should use APR
to be simpler and better integrated in Apache 2.x
2006/7/13, Rainer Jung <ra...@kippdata.de>:
> Hi Henri,
>
> thanks for reporting this. This has already been part of 1.2.16. I
> thought you found only one bug for that platform, which we fixed (unixd.h).
>
> I can build 1.2.17 on solaris 64 bit sparc, and on linux 32 bit and 64
> bit AMD (both times SuSE Enterprise 9).
>
> I get a couple of warnings, but not for this line.
>
> Of course you are riht, that we should be more careful here with types,
> especially since we use two different types for rclen ind the same file.
>
> But is it a regression?
>
> Rainer
>
> Henri Gomez schrieb:
> > jk 1.2.17 build failed on iSeries v5R3.
> >
> > /home/apache/jk/native/common/jk_connect.c, 198.38: CZM0280(30) Function
> > argument assignment between types "int*" and "unsigned int*" is not
> > allowed.
> >
> > getsockopt on Linux is defined like this :
> >
> > int getsockopt(int s, int level, int optname, void *optval,
> > socklen_t *optlen);
> >
> >
> > rclen should be socklen_t instead of unsigned int...
> >
> > With this iSeries build without problems...
> >
> >> 2006/7/12, Rainer Jung <rj...@apache.org>:
> >> Hi,
> >>
> >> thanks to everyone who tested 1.2.16. Unfortunately we had one
> >> regression bug in the status worker (hanging update request because of
> >> double locking). For full results please see:
> >>
> >> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115234851210076&w=2
> >>
> >> Today version 1.2.17 of the Apache Tomcat mod_jk web server connector
> >> has been tagged. This version fixes the new bugs from 1.2.16 and adds
> >> one improvement. Please test and share your experience.
> >>
> >> If no critical bugs will be found, we will have a formal release vote
> >> starting at Saturday, July 15th.
> >>
> >> The source distribution can be downloaded from:
> >>
> >> http://tomcat.apache.org/dev/dist/
> >>
> >> The updated documentation can be found at
> >>
> >> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/
> >>
> >> Please see
> >>
> >> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/changelog.html
> >>
> >> for a complete list of changes.
> >>
> >> Regards,
> >>
> >> Rainer
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Henri,
thanks for reporting this. This has already been part of 1.2.16. I
thought you found only one bug for that platform, which we fixed (unixd.h).
I can build 1.2.17 on solaris 64 bit sparc, and on linux 32 bit and 64
bit AMD (both times SuSE Enterprise 9).
I get a couple of warnings, but not for this line.
Of course you are riht, that we should be more careful here with types,
especially since we use two different types for rclen ind the same file.
But is it a regression?
Rainer
Henri Gomez schrieb:
> jk 1.2.17 build failed on iSeries v5R3.
>
> /home/apache/jk/native/common/jk_connect.c, 198.38: CZM0280(30) Function
> argument assignment between types "int*" and "unsigned int*" is not
> allowed.
>
> getsockopt on Linux is defined like this :
>
> int getsockopt(int s, int level, int optname, void *optval,
> socklen_t *optlen);
>
>
> rclen should be socklen_t instead of unsigned int...
>
> With this iSeries build without problems...
>
>> 2006/7/12, Rainer Jung <rj...@apache.org>:
>> Hi,
>>
>> thanks to everyone who tested 1.2.16. Unfortunately we had one
>> regression bug in the status worker (hanging update request because of
>> double locking). For full results please see:
>>
>> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115234851210076&w=2
>>
>> Today version 1.2.17 of the Apache Tomcat mod_jk web server connector
>> has been tagged. This version fixes the new bugs from 1.2.16 and adds
>> one improvement. Please test and share your experience.
>>
>> If no critical bugs will be found, we will have a formal release vote
>> starting at Saturday, July 15th.
>>
>> The source distribution can be downloaded from:
>>
>> http://tomcat.apache.org/dev/dist/
>>
>> The updated documentation can be found at
>>
>> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/
>>
>> Please see
>>
>> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/changelog.html
>>
>> for a complete list of changes.
>>
>> Regards,
>>
>> Rainer
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> Good, so we're ready for a 1.2.18 release ?
>
Sure if the Rainer still has the energy
for another run :)
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Rainer Jung <rj...@apache.org>.
Batteries loaded, on for another run.
I'll prepare 1.2.18 until tomorrow. Thanks for testing and I hope we
don't overwhelm our users. At least it looks like we will end up with a
good release.
I knew, why I talked about release candidates...
Mladen Turk wrote:
> Henri Gomez wrote:
>
>> Good, so we're ready for a 1.2.18 release ?
>>
>
> Sure if the Rainer still has the energy
> for another run :)
>
> Regards,
> Mladen.
Jim Jagielski wrote:
> I haven't done exhaustive testing yet, but it's looking
> good :)
>
> On Jul 18, 2006, at 10:44 AM, Henri Gomez wrote:
>
>> Good, so we're ready for a 1.2.18 release ?
>>
>> 2006/7/18, Jim Jagielski <ji...@jagunet.com>:
>>
>>>
>>> On Jul 18, 2006, at 8:46 AM, Mladen Turk wrote:
>>>
>>> > Rainer Jung wrote:
>>> >> Then let Peter try it on Mac OS X, if he only gets a warning or a
>>> >> real error.
>>> >>
>>> >
>>> > Sure, but since
>>> > http://www.hmug.org/man/2/getsockopt.php
>>> > says that the OS/X uses socklen_t as well, we should be fine.
>>> >
>>>
>>> I get no build error...
>>>
>>> % gcc --version
>>> powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
>>> build 5247)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Jim Jagielski <ji...@jaguNET.com>.
Testing complete: +1
On Jul 18, 2006, at 12:48 PM, Jim Jagielski wrote:
> I haven't done exhaustive testing yet, but it's looking
> good :)
>
> On Jul 18, 2006, at 10:44 AM, Henri Gomez wrote:
>
>> Good, so we're ready for a 1.2.18 release ?
>>
>> 2006/7/18, Jim Jagielski <ji...@jagunet.com>:
>>>
>>> On Jul 18, 2006, at 8:46 AM, Mladen Turk wrote:
>>>
>>> > Rainer Jung wrote:
>>> >> Then let Peter try it on Mac OS X, if he only gets a warning or a
>>> >> real error.
>>> >>
>>> >
>>> > Sure, but since
>>> > http://www.hmug.org/man/2/getsockopt.php
>>> > says that the OS/X uses socklen_t as well, we should be fine.
>>> >
>>>
>>> I get no build error...
>>>
>>> % gcc --version
>>> powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
>>> build 5247)
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Jim Jagielski <ji...@jaguNET.com>.
I haven't done exhaustive testing yet, but it's looking
good :)
On Jul 18, 2006, at 10:44 AM, Henri Gomez wrote:
> Good, so we're ready for a 1.2.18 release ?
>
> 2006/7/18, Jim Jagielski <ji...@jagunet.com>:
>>
>> On Jul 18, 2006, at 8:46 AM, Mladen Turk wrote:
>>
>> > Rainer Jung wrote:
>> >> Then let Peter try it on Mac OS X, if he only gets a warning or a
>> >> real error.
>> >>
>> >
>> > Sure, but since
>> > http://www.hmug.org/man/2/getsockopt.php
>> > says that the OS/X uses socklen_t as well, we should be fine.
>> >
>>
>> I get no build error...
>>
>> % gcc --version
>> powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
>> build 5247)
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Henri Gomez <he...@gmail.com>.
Good, so we're ready for a 1.2.18 release ?
2006/7/18, Jim Jagielski <ji...@jagunet.com>:
>
> On Jul 18, 2006, at 8:46 AM, Mladen Turk wrote:
>
> > Rainer Jung wrote:
> >> Then let Peter try it on Mac OS X, if he only gets a warning or a
> >> real error.
> >>
> >
> > Sure, but since
> > http://www.hmug.org/man/2/getsockopt.php
> > says that the OS/X uses socklen_t as well, we should be fine.
> >
>
> I get no build error...
>
> % gcc --version
> powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
> build 5247)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jul 18, 2006, at 8:46 AM, Mladen Turk wrote:
> Rainer Jung wrote:
>> Then let Peter try it on Mac OS X, if he only gets a warning or a
>> real error.
>>
>
> Sure, but since
> http://www.hmug.org/man/2/getsockopt.php
> says that the OS/X uses socklen_t as well, we should be fine.
>
I get no build error...
% gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
build 5247)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
> Then let Peter try it on Mac OS X, if he only gets a warning or a real
> error.
>
Sure, but since
http://www.hmug.org/man/2/getsockopt.php
says that the OS/X uses socklen_t as well, we should be fine.
--
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: *SPAM* Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Peter Rossbach <pr...@objektpark.de>.
+1
Great!
Works for me without error or warnings. apache 2.0.55 and 2.0.58
works at my Powerbook G4 MAC OS X 10.4.6 with darwin ports.
I can test it also at my intel mac and G5 tomorrow.
Many thanks,
Peter
Am 18.07.2006 um 14:42 schrieb Rainer Jung:
> Then let Peter try it on Mac OS X, if he only gets a warning or a
> real error.
>
> Henri Gomez wrote:
>> Ok, build against the latest from SVN (thanks Mladen), and build
>> without any problem on iSeries.
>> A strong 1.2.18 candidate
>> 2006/7/18, Mladen Turk <mt...@apache.org>:
>>> Henri Gomez wrote:
>>> > Well on iSeries the C compiler is very strict about these kind of
>>> > typecast so the socklen_t should be used (and the build works with
>>> > it).
>>> >
>>>
>>> Can you check the current head?
>>> I committed the fix.
>>>
>>> --
>>> Mladen.
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
Then let Peter try it on Mac OS X, if he only gets a warning or a real
error.
Henri Gomez wrote:
> Ok, build against the latest from SVN (thanks Mladen), and build
> without any problem on iSeries.
>
> A strong 1.2.18 candidate
>
> 2006/7/18, Mladen Turk <mt...@apache.org>:
>
>> Henri Gomez wrote:
>> > Well on iSeries the C compiler is very strict about these kind of
>> > typecast so the socklen_t should be used (and the build works with
>> > it).
>> >
>>
>> Can you check the current head?
>> I committed the fix.
>>
>> --
>> Mladen.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Henri Gomez <he...@gmail.com>.
Ok, build against the latest from SVN (thanks Mladen), and build
without any problem on iSeries.
A strong 1.2.18 candidate
2006/7/18, Mladen Turk <mt...@apache.org>:
> Henri Gomez wrote:
> > Well on iSeries the C compiler is very strict about these kind of
> > typecast so the socklen_t should be used (and the build works with
> > it).
> >
>
> Can you check the current head?
> I committed the fix.
>
> --
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> Well on iSeries the C compiler is very strict about these kind of
> typecast so the socklen_t should be used (and the build works with
> it).
>
Can you check the current head?
I committed the fix.
--
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Henri Gomez <he...@gmail.com>.
Well on iSeries the C compiler is very strict about these kind of
typecast so the socklen_t should be used (and the build works with
it).
If you're using JK_SOCKLEN_T via configure, since the iSeries didn't
use it, please define it with #ifdef AS400 to 'link' it to socklen_t.
2006/7/18, Jean-frederic Clere <jf...@gmail.com>:
> Rainer Jung wrote:
>
> > Mladen Turk wrote:
> >
> >> Anyhow, I suppose it should be neither int nor unsigned int,
> >> but rather size_t, at least that's the retval from sizeof, right?
> >> Of course its used by getsockopt that OTOH requires socklen_t.
> >
> >
> > Since it's only use is putting it into getsockopt(), I would suggest
> > the use of socklen_t and explicitely cast the return from sizeof().
>
> I would suggest to have a JK_SOCKLEN_T as we have the JK_INT*, just in
> case a platform does not have socklen_t. (See configure.in)
>
>
> Cheers
>
> Jean-Frederic
>
> >
> >> I just wonder who is the genius that invented something that
> >> stupid as socklen_t :)
> >> I suppose it should be some sort of a size, correct?
> >
> >
> > Found some interesting pieces:
> >
> > 1) http://www.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html
> >
> > Says:
> >
> > <sys/socket.h> makes available a type, socklen_t, which is an unsigned
> > opaque integral type of length of at least 32 bits. To forestall
> > portability problems, it is recommended that applications should not
> > use values larger than 2^32 - 1.
> >
> > 2) http://www.opengroup.org/austin/docs/austin_76r1.txt
> >
> > has interesting comments (...The type socklen_t is an unfortunate
> > historical accident...):
> >
> > The type socklen_t was invented to cover the range of implementations
> > seen in the field. The intent of socklen_t is to be the type for all
> > lengths that are naturally bounded in size, that is, that they are the
> > length of a buffer which cannot sensibly become of massive size: network
> > addresses, hostnames, string representations of these, ancillary data,
> > control messages, and socket options are examples. Truly boundless
> > sizes are represented by size_t as in read(), write(), etc.
> >
> > All socklen_t types were originally (in BSD UNIX) of type int.
> > During the development of the document it was decided to change
> > all buffer lengths to size_t, which appears at face value to make sense.
> > When dual mode 32/64 bit systems came along, this choice unnecessarily
> > complicated system interfaces because size_t (with long) was a different
> > size under ILP32 and LP64 models. Reverting to int would have happened
> > except that some systems had already shipped 64-bit only interfaces. The
> > compromise was a type which could be defined to be any size by the
> > implementation: socklen_t.
> >
> > and
> >
> >
> > People are continually confused about socklen_t.
> >
> > The type socklen_t is an unfortunate historical accident, and needed to
> > be invented to cover the range of implementations seen in the field.
> > The intent of socklen_t is to be the type for all lengths that are
> > naturally bounded in size, that is, that they are the length of a
> > buffer which cannot sensibly become of massive size: network addresses,
> > hostnames, string representations of these, ancillary data, control
> > messages, and socket options are examples. Truly boundless sizes are
> > represented by size_t as in read(), write(), etc.
> >
> > All socklen_t types were originally (in BSD UNIX) of type int.
> > An overzealous unknown decided without significant review to "correct"
> > all buffer lengths to size_t, which appears on its face to make sense.
> > When dual mode 32/64 bit systems came along, this choice unnecessarily
> > complicated system interfaces because size_t (with long) was a different
> > size under ILP32 and LP64 models. Reverting to int would have happened
> > except that some systems had already shipped 64-bit only interfaces. The
> > compromise was a type which could be defined to be any size by the
> > implementation: socklen_t.
> >
> > Rainer
> >
> >>
> >> --
> >> Mladen.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Jean-frederic Clere <jf...@gmail.com>.
Rainer Jung wrote:
> Mladen Turk wrote:
>
>> Anyhow, I suppose it should be neither int nor unsigned int,
>> but rather size_t, at least that's the retval from sizeof, right?
>> Of course its used by getsockopt that OTOH requires socklen_t.
>
>
> Since it's only use is putting it into getsockopt(), I would suggest
> the use of socklen_t and explicitely cast the return from sizeof().
I would suggest to have a JK_SOCKLEN_T as we have the JK_INT*, just in
case a platform does not have socklen_t. (See configure.in)
Cheers
Jean-Frederic
>
>> I just wonder who is the genius that invented something that
>> stupid as socklen_t :)
>> I suppose it should be some sort of a size, correct?
>
>
> Found some interesting pieces:
>
> 1) http://www.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html
>
> Says:
>
> <sys/socket.h> makes available a type, socklen_t, which is an unsigned
> opaque integral type of length of at least 32 bits. To forestall
> portability problems, it is recommended that applications should not
> use values larger than 2^32 - 1.
>
> 2) http://www.opengroup.org/austin/docs/austin_76r1.txt
>
> has interesting comments (...The type socklen_t is an unfortunate
> historical accident...):
>
> The type socklen_t was invented to cover the range of implementations
> seen in the field. The intent of socklen_t is to be the type for all
> lengths that are naturally bounded in size, that is, that they are the
> length of a buffer which cannot sensibly become of massive size: network
> addresses, hostnames, string representations of these, ancillary data,
> control messages, and socket options are examples. Truly boundless
> sizes are represented by size_t as in read(), write(), etc.
>
> All socklen_t types were originally (in BSD UNIX) of type int.
> During the development of the document it was decided to change
> all buffer lengths to size_t, which appears at face value to make sense.
> When dual mode 32/64 bit systems came along, this choice unnecessarily
> complicated system interfaces because size_t (with long) was a different
> size under ILP32 and LP64 models. Reverting to int would have happened
> except that some systems had already shipped 64-bit only interfaces. The
> compromise was a type which could be defined to be any size by the
> implementation: socklen_t.
>
> and
>
>
> People are continually confused about socklen_t.
>
> The type socklen_t is an unfortunate historical accident, and needed to
> be invented to cover the range of implementations seen in the field.
> The intent of socklen_t is to be the type for all lengths that are
> naturally bounded in size, that is, that they are the length of a
> buffer which cannot sensibly become of massive size: network addresses,
> hostnames, string representations of these, ancillary data, control
> messages, and socket options are examples. Truly boundless sizes are
> represented by size_t as in read(), write(), etc.
>
> All socklen_t types were originally (in BSD UNIX) of type int.
> An overzealous unknown decided without significant review to "correct"
> all buffer lengths to size_t, which appears on its face to make sense.
> When dual mode 32/64 bit systems came along, this choice unnecessarily
> complicated system interfaces because size_t (with long) was a different
> size under ILP32 and LP64 models. Reverting to int would have happened
> except that some systems had already shipped 64-bit only interfaces. The
> compromise was a type which could be defined to be any size by the
> implementation: socklen_t.
>
> Rainer
>
>>
>> --
>> Mladen.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
Mladen Turk wrote:
> Anyhow, I suppose it should be neither int nor unsigned int,
> but rather size_t, at least that's the retval from sizeof, right?
> Of course its used by getsockopt that OTOH requires socklen_t.
Since it's only use is putting it into getsockopt(), I would suggest the
use of socklen_t and explicitely cast the return from sizeof().
> I just wonder who is the genius that invented something that
> stupid as socklen_t :)
> I suppose it should be some sort of a size, correct?
Found some interesting pieces:
1) http://www.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html
Says:
<sys/socket.h> makes available a type, socklen_t, which is an unsigned
opaque integral type of length of at least 32 bits. To forestall
portability problems, it is recommended that applications should not use
values larger than 2^32 - 1.
2) http://www.opengroup.org/austin/docs/austin_76r1.txt
has interesting comments (...The type socklen_t is an unfortunate
historical accident...):
The type socklen_t was invented to cover the range of implementations
seen in the field. The intent of socklen_t is to be the type for all
lengths that are naturally bounded in size, that is, that they are the
length of a buffer which cannot sensibly become of massive size: network
addresses, hostnames, string representations of these, ancillary data,
control messages, and socket options are examples. Truly boundless
sizes are represented by size_t as in read(), write(), etc.
All socklen_t types were originally (in BSD UNIX) of type int.
During the development of the document it was decided to change
all buffer lengths to size_t, which appears at face value to make sense.
When dual mode 32/64 bit systems came along, this choice unnecessarily
complicated system interfaces because size_t (with long) was a different
size under ILP32 and LP64 models. Reverting to int would have happened
except that some systems had already shipped 64-bit only interfaces. The
compromise was a type which could be defined to be any size by the
implementation: socklen_t.
and
People are continually confused about socklen_t.
The type socklen_t is an unfortunate historical accident, and needed to
be invented to cover the range of implementations seen in the field.
The intent of socklen_t is to be the type for all lengths that are
naturally bounded in size, that is, that they are the length of a
buffer which cannot sensibly become of massive size: network addresses,
hostnames, string representations of these, ancillary data, control
messages, and socket options are examples. Truly boundless sizes are
represented by size_t as in read(), write(), etc.
All socklen_t types were originally (in BSD UNIX) of type int.
An overzealous unknown decided without significant review to "correct"
all buffer lengths to size_t, which appears on its face to make sense.
When dual mode 32/64 bit systems came along, this choice unnecessarily
complicated system interfaces because size_t (with long) was a different
size under ILP32 and LP64 models. Reverting to int would have happened
except that some systems had already shipped 64-bit only interfaces. The
compromise was a type which could be defined to be any size by the
implementation: socklen_t.
Rainer
>
> --
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
> Be careful:
>
> I understand Henri problem report as getsockopt complaining about the
> *last* argument. So it has been introduced between 1.2.15 and 1.2.16:
>
> ------------------------------------------------------------------------
> r386629 | pero | 2006-03-17 13:36:04 +0100 (Fri, 17 Mar 2006) | 1 line
>
> Fix gcc 4.0.1 compiler warning at mac os x!
Right, one fix breaks other :)
Anyhow, I suppose it should be neither int nor unsigned int,
but rather size_t, at least that's the retval from sizeof, right?
Of course its used by getsockopt that OTOH requires socklen_t.
I just wonder who is the genius that invented something that
stupid as socklen_t :)
I suppose it should be some sort of a size, correct?
--
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Rainer Jung <ra...@kippdata.de>.
Be careful:
I understand Henri problem report as getsockopt complaining about the
*last* argument. So it has been introduced between 1.2.15 and 1.2.16:
------------------------------------------------------------------------
r386629 | pero | 2006-03-17 13:36:04 +0100 (Fri, 17 Mar 2006) | 1 line
Fix gcc 4.0.1 compiler warning at mac os x!
------------------------------------------------------------------------
svn diff -r 386628:386629 jk_connect.c
Index: jk_connect.c
===================================================================
--- jk_connect.c (revision 386628)
+++ jk_connect.c (revision 386629)
@@ -177,7 +177,7 @@
&& (timeout > 0)) {
fd_set wfdset;
struct timeval tv;
- int rclen = sizeof(rc);
+ unsigned int rclen = sizeof(rc);
FD_ZERO(&wfdset);
FD_SET(sock, &wfdset);
Since it actually build OK for Linux 32 and 64Bit I would also like to
go forward with 1.2.17. Is it possible to make this error a warning on
iSeries and fix for 1.2.18?
We set rclen only in the line
unsigned int rclen = sizeof(rc);
and rc itself is an int, there is no way, how rclen could behave
differently as an argument (sign extensions). Furthermore we never read
from rclen after passing &rclen to getsockopt(), so it really should be
save using either of both ways (unsigned int and int).
Rainer
Mladen Turk wrote:
> Henri Gomez wrote:
>
>> jk 1.2.17 build failed on iSeries v5R3.
>>
>> /home/apache/jk/native/common/jk_connect.c, 198.38: CZM0280(30) Function
>> argument assignment between types "int*" and "unsigned int*" is not
>> allowed.
>>
>
> Henri, can you commit the working version?
> Seems that the 'unsigned int' is present for ages,
> and unless there is actual reason that would break
> the functionality if you force your compiler to
> treat this as warning instead as error,
> we should go with 1.2.17.
>
> OTOH, the same might apply to SOCKET<->int types
> for windows, where we simply disregard the warnings
> although I don't know how that behaves on win64, cause
> SOCKET is defined as 'unsigned int *' (UINT_PTR)
>
> Perhaps we could fix that socklen_t and add jk_sock_t
> type all at once if you guys think this bug breaks
> the 1.2.17.
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> jk 1.2.17 build failed on iSeries v5R3.
>
> /home/apache/jk/native/common/jk_connect.c, 198.38: CZM0280(30) Function
> argument assignment between types "int*" and "unsigned int*" is not
> allowed.
>
Henri, can you commit the working version?
Seems that the 'unsigned int' is present for ages,
and unless there is actual reason that would break
the functionality if you force your compiler to
treat this as warning instead as error,
we should go with 1.2.17.
OTOH, the same might apply to SOCKET<->int types
for windows, where we simply disregard the warnings
although I don't know how that behaves on win64, cause
SOCKET is defined as 'unsigned int *' (UINT_PTR)
Perhaps we could fix that socklen_t and add jk_sock_t
type all at once if you guys think this bug breaks
the 1.2.17.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Next try: mod_jk 1.2.17 release candidate ready to test
Posted by Henri Gomez <he...@gmail.com>.
jk 1.2.17 build failed on iSeries v5R3.
/home/apache/jk/native/common/jk_connect.c, 198.38: CZM0280(30) Function
argument assignment between types "int*" and "unsigned int*" is not
allowed.
getsockopt on Linux is defined like this :
int getsockopt(int s, int level, int optname, void *optval,
socklen_t *optlen);
rclen should be socklen_t instead of unsigned int...
With this iSeries build without problems...
>2006/7/12, Rainer Jung <rj...@apache.org>:
> Hi,
>
> thanks to everyone who tested 1.2.16. Unfortunately we had one
> regression bug in the status worker (hanging update request because of
> double locking). For full results please see:
>
> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115234851210076&w=2
>
> Today version 1.2.17 of the Apache Tomcat mod_jk web server connector
> has been tagged. This version fixes the new bugs from 1.2.16 and adds
> one improvement. Please test and share your experience.
>
> If no critical bugs will be found, we will have a formal release vote
> starting at Saturday, July 15th.
>
> The source distribution can be downloaded from:
>
> http://tomcat.apache.org/dev/dist/
>
> The updated documentation can be found at
>
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/
>
> Please see
>
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.17/changelog.html
>
> for a complete list of changes.
>
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org