You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Glenn Nielsen <gl...@mail.more.net> on 2003/08/01 12:39:27 UTC
[VOTE] Release mod_jk 1.2.5
No problems have been reported since the last test source distribution
of mod_jk 1.2.5 was made available for testing July 26.
<ballot>
Please vote on a release of mod_jk 1.2.5:
[ ] +1 release, and I will help build binaries for _________ os/web server
[ ] +0 ok to release
[ ] -0 release, but I still have a problem with _____
[ ] -1 don't release, there is a problem with _____
</ballot>
The votes will be counted Monday August 4 and the source dist
release made if the vote passes.
Regards,
Glenn
Re: [VOTE] Release mod_jk 1.2.5
Posted by Glenn Nielsen <gl...@mail.more.net>.
I can confirm what Henri said, laddr had always been a ulong and
was only type in_addr_t for a short period of time.
Does mod_jk 1.2.4 build and work correctly? It used a ulong for laddr.
What web server are you building this for?
If you are building for Apache 2 it may be a problem with the APR code.
Regards,
Glenn
Kurt Miller wrote:
> From: "Glenn Nielsen" <gl...@mail.more.net>
> To: <to...@jakarta.apache.org>
> Sent: Friday, August 01, 2003 6:39 AM
> Subject: [VOTE] Release mod_jk 1.2.5
>
>
>
>>No problems have been reported since the last test source distribution
>>of mod_jk 1.2.5 was made available for testing July 26.
>>
>
>
> I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The
> recent change of the datatype of laddr from in_addr_t to u_long has broken
> this function. Could this be reverted back before release? Below is a copy
> of the commit that caused the problem:
>
> hgomez 2003/07/25 07:58:22
>
> Modified: jk/native/common jk_connect.c
> Log:
> Use u_long instead of in_addr_t which make unhappy some platforms like
> iSeries
>
>
> Revision Changes Path
> 1.10 +2 -3
> jakarta-tomcat-connectors/jk/native/common/jk_connect.c
>
> Index: jk_connect.c
> ===================================================================
> RCS file:
> /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- jk_connect.c 24 Jul 2003 08:17:10 -0000 1.9
> +++ jk_connect.c 25 Jul 2003 14:58:22 -0000 1.10
> @@ -110,8 +110,7 @@
> int x;
>
> /* TODO: Should be updated for IPV6 support. */
> - /* for now use the correct type, in_addr_t */
> - in_addr_t laddr;
> + u_long laddr;
>
> rc->sin_port = htons((short)port);
> rc->sin_family = AF_INET;
>
> -Kurt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Glenn Nielsen <gl...@mail.more.net>.
Kurt Miller wrote:
> From: "Henri Gomez" <hg...@apache.org>
>
>>It was u_long before I change it in in_addr_t and then change
>>it back to u_long.
>
>
> Oh. I guess I should have done a bit more research.;-) I just started
> attempting to get mod_jk going on sparc64 a few days ago. However, using a
> u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The
> memcpy at the end copies all zeros into rc->sin_addr when u_long is used.
>
> There are some other issues going on with mod_jk OpenBSD/sparc64, so its not
> yet working even with this corrected. Given that, it may not make sense to
> hold up the release for this. I will need to put in more time to investigate
> the next issue.
>
> OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new
> APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all
> don't work. It wasn't until recently that I had time to start investigating
> it. I'll post patches here as I make progress.
>
Yes, please send us the patches when they are available. The more OS/web servers,
the better. :-)
Thanks Kurt
Glenn
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Glenn Nielsen <gl...@mail.more.net>.
Kurt Miller wrote:
> From: "Henri Gomez" <hg...@apache.org>
>
>>It was u_long before I change it in in_addr_t and then change
>>it back to u_long.
>
>
> Oh. I guess I should have done a bit more research.;-) I just started
> attempting to get mod_jk going on sparc64 a few days ago. However, using a
> u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The
> memcpy at the end copies all zeros into rc->sin_addr when u_long is used.
>
> There are some other issues going on with mod_jk OpenBSD/sparc64, so its not
> yet working even with this corrected. Given that, it may not make sense to
> hold up the release for this. I will need to put in more time to investigate
> the next issue.
>
> OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new
> APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all
> don't work. It wasn't until recently that I had time to start investigating
> it. I'll post patches here as I make progress.
>
Yes, please send us the patches when they are available. The more OS/web servers,
the better. :-)
Thanks Kurt
Glenn
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Henri Gomez a écrit :
> Kurt Miller a écrit :
>
>> From: "Henri Gomez" <hg...@apache.org>
>>
>>> It was u_long before I change it in in_addr_t and then change
>>> it back to u_long.
>>
>>
>>
>> Oh. I guess I should have done a bit more research.;-) I just started
>> attempting to get mod_jk going on sparc64 a few days ago. However,
>> using a
>> u_long for laddr is the cause of jk_resolve failing on
>> OpenBSD/sparc64. The
>> memcpy at the end copies all zeros into rc->sin_addr when u_long is used.
>>
>> There are some other issues going on with mod_jk OpenBSD/sparc64, so
>> its not
>> yet working even with this corrected. Given that, it may not make
>> sense to
>> hold up the release for this. I will need to put in more time to
>> investigate
>> the next issue.
>>
>> OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with
>> the new
>> APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all
>> don't work. It wasn't until recently that I had time to start
>> investigating
>> it. I'll post patches here as I make progress.
>
>
> The correct behaviour will be to use in_addr_t, but it don't works on
> iSeries (even if it's defined, I couldn't find the correct include).
>
> To fix the problem we could use a #define BSD64 ? to make use of
> in_addr_t until we make more works ?
>
> Just provide the correct defined var for BSD/SPARC64
From my Linux manual :
INET(3) Manuel du programmeur Linux
INET(3)
NOM
inet_aton, inet_addr, inet_network, inet_ntoa,
inet_makeaddr,
inet_lnaof, inet_netof - Routines de manipulation d’adresses
Internet.
SYNOPSIS
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
int inet_aton (const char *cp, struct in_addr *inp);
in_addr_t inet_addr (const char * cp);
in_addr_t inet_network (const char * cp);
char * inet_ntoa (struct in_addr in);
struct in_addr inet_makeaddr (int net, int host);
in_addr_t inet_lnaof (struct in_addr in);
We're using inet_addr()...
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by David Rees <db...@greenhydrant.com>.
Henri Gomez said:
>
> The correct behaviour will be to use in_addr_t, but it don't works on
> iSeries (even if it's defined, I couldn't find the correct include).
>
> To fix the problem we could use a #define BSD64 ? to make use of
> in_addr_t until we make more works ?
>
> Just provide the correct defined var for BSD/SPARC64
If that's the case, wouldn't it be better to provide a #define for iSeries
since in_addr_t works for most platforms?
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Henri Gomez a écrit :
> Kurt Miller a écrit :
>
>> From: "Henri Gomez" <hg...@apache.org>
>>
>>> It was u_long before I change it in in_addr_t and then change
>>> it back to u_long.
>>
>>
>>
>> Oh. I guess I should have done a bit more research.;-) I just started
>> attempting to get mod_jk going on sparc64 a few days ago. However,
>> using a
>> u_long for laddr is the cause of jk_resolve failing on
>> OpenBSD/sparc64. The
>> memcpy at the end copies all zeros into rc->sin_addr when u_long is used.
>>
>> There are some other issues going on with mod_jk OpenBSD/sparc64, so
>> its not
>> yet working even with this corrected. Given that, it may not make
>> sense to
>> hold up the release for this. I will need to put in more time to
>> investigate
>> the next issue.
>>
>> OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with
>> the new
>> APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all
>> don't work. It wasn't until recently that I had time to start
>> investigating
>> it. I'll post patches here as I make progress.
>
>
> The correct behaviour will be to use in_addr_t, but it don't works on
> iSeries (even if it's defined, I couldn't find the correct include).
>
> To fix the problem we could use a #define BSD64 ? to make use of
> in_addr_t until we make more works ?
>
> Just provide the correct defined var for BSD/SPARC64
From my Linux manual :
INET(3) Manuel du programmeur Linux
INET(3)
NOM
inet_aton, inet_addr, inet_network, inet_ntoa,
inet_makeaddr,
inet_lnaof, inet_netof - Routines de manipulation d’adresses
Internet.
SYNOPSIS
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
int inet_aton (const char *cp, struct in_addr *inp);
in_addr_t inet_addr (const char * cp);
in_addr_t inet_network (const char * cp);
char * inet_ntoa (struct in_addr in);
struct in_addr inet_makeaddr (int net, int host);
in_addr_t inet_lnaof (struct in_addr in);
We're using inet_addr()...
Re: [VOTE] Release mod_jk 1.2.5
Posted by David Rees <db...@greenhydrant.com>.
Henri Gomez said:
>
> The correct behaviour will be to use in_addr_t, but it don't works on
> iSeries (even if it's defined, I couldn't find the correct include).
>
> To fix the problem we could use a #define BSD64 ? to make use of
> in_addr_t until we make more works ?
>
> Just provide the correct defined var for BSD/SPARC64
If that's the case, wouldn't it be better to provide a #define for iSeries
since in_addr_t works for most platforms?
-Dave
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Kurt Miller a écrit :
> From: "Henri Gomez" <hg...@apache.org>
>
>>>>The future will be mod_jk2, and I think we should focus on it after the
>>>>1.2.5 release.
>>>>
>>>
>>>
>>>Ok. I jumped in on this thread because I thought that a new problem was
>>>introduced, but that is how it was in prior releases. I can report 1.2.5
>>>works fine on OpenBSD-current/i386. I will keep working on
>
> OpenBSD/sparc64
>
>>>and post patches here when it is working. If there's a 1.2.6 release
>
> maybe
>
>>>they can be incorporated then.
>>
>>Surely, jk 1.2.6 could be the release with OpenBSD/sparc64 support, we
>>should fix this hack around the in_addr_t and of course add the Ipv6
>>support since an IP adress won't fix into a 32 bits integer for too long.
>>
>>Work on patch and we'll see how to make them useable for other OS,
>>I think the rigth way is via in_addr_t
>
>
> I done more testing this morning and have determined that the u_long is the
> only bug preventing mod_jk from working on OpenBSD/sparc64. The other issues
> on OpenBSD/sparc64 that I was referring to seem to be related to my install
> of tomcat 4.0.6. I setup a new tomcat 4.1.27 install on a different box and
> mod_jk on OpenBSD/sparc64 works fine with it (with the datatype change).
>
> Is it too late to incorporate a change for the 1.2.5 release? You and David
> Rees have pointed out the in_addr_t is the correct type to use for
> inet_addr. Would it not make sense to change it to that and have a define
> for the iSeries? I would supply a patch, but I don't have an iSeries
> available.
If it works on all platform (except iSeries), it should be changed to
in_addr_t. I'll take a look to see where the type is defined to add the
missing include. Stay tuned
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Henri Gomez" <hg...@apache.org>
> >>The future will be mod_jk2, and I think we should focus on it after the
> >>1.2.5 release.
> >>
> >
> >
> > Ok. I jumped in on this thread because I thought that a new problem was
> > introduced, but that is how it was in prior releases. I can report 1.2.5
> > works fine on OpenBSD-current/i386. I will keep working on
OpenBSD/sparc64
> > and post patches here when it is working. If there's a 1.2.6 release
maybe
> > they can be incorporated then.
>
> Surely, jk 1.2.6 could be the release with OpenBSD/sparc64 support, we
> should fix this hack around the in_addr_t and of course add the Ipv6
> support since an IP adress won't fix into a 32 bits integer for too long.
>
> Work on patch and we'll see how to make them useable for other OS,
> I think the rigth way is via in_addr_t
I done more testing this morning and have determined that the u_long is the
only bug preventing mod_jk from working on OpenBSD/sparc64. The other issues
on OpenBSD/sparc64 that I was referring to seem to be related to my install
of tomcat 4.0.6. I setup a new tomcat 4.1.27 install on a different box and
mod_jk on OpenBSD/sparc64 works fine with it (with the datatype change).
Is it too late to incorporate a change for the 1.2.5 release? You and David
Rees have pointed out the in_addr_t is the correct type to use for
inet_addr. Would it not make sense to change it to that and have a define
for the iSeries? I would supply a patch, but I don't have an iSeries
available.
-Kurt
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Henri Gomez" <hg...@apache.org>
> >>The future will be mod_jk2, and I think we should focus on it after the
> >>1.2.5 release.
> >>
> >
> >
> > Ok. I jumped in on this thread because I thought that a new problem was
> > introduced, but that is how it was in prior releases. I can report 1.2.5
> > works fine on OpenBSD-current/i386. I will keep working on
OpenBSD/sparc64
> > and post patches here when it is working. If there's a 1.2.6 release
maybe
> > they can be incorporated then.
>
> Surely, jk 1.2.6 could be the release with OpenBSD/sparc64 support, we
> should fix this hack around the in_addr_t and of course add the Ipv6
> support since an IP adress won't fix into a 32 bits integer for too long.
>
> Work on patch and we'll see how to make them useable for other OS,
> I think the rigth way is via in_addr_t
I done more testing this morning and have determined that the u_long is the
only bug preventing mod_jk from working on OpenBSD/sparc64. The other issues
on OpenBSD/sparc64 that I was referring to seem to be related to my install
of tomcat 4.0.6. I setup a new tomcat 4.1.27 install on a different box and
mod_jk on OpenBSD/sparc64 works fine with it (with the datatype change).
Is it too late to incorporate a change for the 1.2.5 release? You and David
Rees have pointed out the in_addr_t is the correct type to use for
inet_addr. Would it not make sense to change it to that and have a define
for the iSeries? I would supply a patch, but I don't have an iSeries
available.
-Kurt
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
>>The future will be mod_jk2, and I think we should focus on it after the
>>1.2.5 release.
>>
>
>
> Ok. I jumped in on this thread because I thought that a new problem was
> introduced, but that is how it was in prior releases. I can report 1.2.5
> works fine on OpenBSD-current/i386. I will keep working on OpenBSD/sparc64
> and post patches here when it is working. If there's a 1.2.6 release maybe
> they can be incorporated then.
Surely, jk 1.2.6 could be the release with OpenBSD/sparc64 support, we
should fix this hack around the in_addr_t and of course add the Ipv6
support since an IP adress won't fix into a 32 bits integer for too long.
Work on patch and we'll see how to make them useable for other OS,
I think the rigth way is via in_addr_t
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
>>The future will be mod_jk2, and I think we should focus on it after the
>>1.2.5 release.
>>
>
>
> Ok. I jumped in on this thread because I thought that a new problem was
> introduced, but that is how it was in prior releases. I can report 1.2.5
> works fine on OpenBSD-current/i386. I will keep working on OpenBSD/sparc64
> and post patches here when it is working. If there's a 1.2.6 release maybe
> they can be incorporated then.
Surely, jk 1.2.6 could be the release with OpenBSD/sparc64 support, we
should fix this hack around the in_addr_t and of course add the Ipv6
support since an IP adress won't fix into a 32 bits integer for too long.
Work on patch and we'll see how to make them useable for other OS,
I think the rigth way is via in_addr_t
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Henri Gomez" <hg...@apache.org>
> Kurt Miller a écrit :
>
> > From: "Henri Gomez" <hg...@apache.org>
> >
> >>Kurt Miller a écrit :
> >>
> >>
> >>>From: "Henri Gomez" <hg...@apache.org>
> >>>
> >>>>It was u_long before I change it in in_addr_t and then change
> >>>>it back to u_long.
> >>>
> >>>
> >>>Oh. I guess I should have done a bit more research.;-) I just started
> >>>attempting to get mod_jk going on sparc64 a few days ago. However,
using
> >
> > a
> >
> >>>u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64.
> >
> > The
> >
> >>>memcpy at the end copies all zeros into rc->sin_addr when u_long is
> >
> > used.
> >
> >>>There are some other issues going on with mod_jk OpenBSD/sparc64, so
its
> >
> > not
> >
> >>>yet working even with this corrected. Given that, it may not make sense
> >
> > to
> >
> >>>hold up the release for this. I will need to put in more time to
> >
> > investigate
> >
> >>>the next issue.
> >>>
> >>>OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the
> >
> > new
> >
> >>>APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they
> >
> > all
> >
> >>>don't work. It wasn't until recently that I had time to start
> >
> > investigating
> >
> >>>it. I'll post patches here as I make progress.
> >>
> >>The correct behaviour will be to use in_addr_t, but it don't works on
> >>iSeries (even if it's defined, I couldn't find the correct include).
> >>
> >>To fix the problem we could use a #define BSD64 ? to make use of
> >>in_addr_t until we make more works ?
> >>
> >>Just provide the correct defined var for BSD/SPARC64
> >>
> >
> >
> > I'm thinking a define may not be needed. I mischaracterized the problem
> > slightly... u_long on OpenBSD/sparc64 is 8 bytes long, so the memcpy
copies
> > 8 bytes into rc->sin_addr. The first four bytes are zeros the next four
> > overwrite some of the rest of the struct.
> >
> > Would it fix the problem if laddr was defined as a datatype that is 4
bytes
> > long on all arches? Maybe u_int32_t or struct in_addr (same as
> > rc->sin_addr)?
>
> Hum trying to play with bytes is not a good idea, we should stay with
> socket API and types.
>
> BTW, the current code is not compatible with IPv6, and we may have to
> use APR supports API, which could break the consensus that JK should
> works without requiring APR (or Apache 2.0).
>
> The future will be mod_jk2, and I think we should focus on it after the
> 1.2.5 release.
>
Ok. I jumped in on this thread because I thought that a new problem was
introduced, but that is how it was in prior releases. I can report 1.2.5
works fine on OpenBSD-current/i386. I will keep working on OpenBSD/sparc64
and post patches here when it is working. If there's a 1.2.6 release maybe
they can be incorporated then.
-Kurt
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Henri Gomez" <hg...@apache.org>
> Kurt Miller a écrit :
>
> > From: "Henri Gomez" <hg...@apache.org>
> >
> >>Kurt Miller a écrit :
> >>
> >>
> >>>From: "Henri Gomez" <hg...@apache.org>
> >>>
> >>>>It was u_long before I change it in in_addr_t and then change
> >>>>it back to u_long.
> >>>
> >>>
> >>>Oh. I guess I should have done a bit more research.;-) I just started
> >>>attempting to get mod_jk going on sparc64 a few days ago. However,
using
> >
> > a
> >
> >>>u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64.
> >
> > The
> >
> >>>memcpy at the end copies all zeros into rc->sin_addr when u_long is
> >
> > used.
> >
> >>>There are some other issues going on with mod_jk OpenBSD/sparc64, so
its
> >
> > not
> >
> >>>yet working even with this corrected. Given that, it may not make sense
> >
> > to
> >
> >>>hold up the release for this. I will need to put in more time to
> >
> > investigate
> >
> >>>the next issue.
> >>>
> >>>OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the
> >
> > new
> >
> >>>APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they
> >
> > all
> >
> >>>don't work. It wasn't until recently that I had time to start
> >
> > investigating
> >
> >>>it. I'll post patches here as I make progress.
> >>
> >>The correct behaviour will be to use in_addr_t, but it don't works on
> >>iSeries (even if it's defined, I couldn't find the correct include).
> >>
> >>To fix the problem we could use a #define BSD64 ? to make use of
> >>in_addr_t until we make more works ?
> >>
> >>Just provide the correct defined var for BSD/SPARC64
> >>
> >
> >
> > I'm thinking a define may not be needed. I mischaracterized the problem
> > slightly... u_long on OpenBSD/sparc64 is 8 bytes long, so the memcpy
copies
> > 8 bytes into rc->sin_addr. The first four bytes are zeros the next four
> > overwrite some of the rest of the struct.
> >
> > Would it fix the problem if laddr was defined as a datatype that is 4
bytes
> > long on all arches? Maybe u_int32_t or struct in_addr (same as
> > rc->sin_addr)?
>
> Hum trying to play with bytes is not a good idea, we should stay with
> socket API and types.
>
> BTW, the current code is not compatible with IPv6, and we may have to
> use APR supports API, which could break the consensus that JK should
> works without requiring APR (or Apache 2.0).
>
> The future will be mod_jk2, and I think we should focus on it after the
> 1.2.5 release.
>
Ok. I jumped in on this thread because I thought that a new problem was
introduced, but that is how it was in prior releases. I can report 1.2.5
works fine on OpenBSD-current/i386. I will keep working on OpenBSD/sparc64
and post patches here when it is working. If there's a 1.2.6 release maybe
they can be incorporated then.
-Kurt
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Kurt Miller a écrit :
> From: "Henri Gomez" <hg...@apache.org>
>
>>Kurt Miller a écrit :
>>
>>
>>>From: "Henri Gomez" <hg...@apache.org>
>>>
>>>>It was u_long before I change it in in_addr_t and then change
>>>>it back to u_long.
>>>
>>>
>>>Oh. I guess I should have done a bit more research.;-) I just started
>>>attempting to get mod_jk going on sparc64 a few days ago. However, using
>
> a
>
>>>u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64.
>
> The
>
>>>memcpy at the end copies all zeros into rc->sin_addr when u_long is
>
> used.
>
>>>There are some other issues going on with mod_jk OpenBSD/sparc64, so its
>
> not
>
>>>yet working even with this corrected. Given that, it may not make sense
>
> to
>
>>>hold up the release for this. I will need to put in more time to
>
> investigate
>
>>>the next issue.
>>>
>>>OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the
>
> new
>
>>>APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they
>
> all
>
>>>don't work. It wasn't until recently that I had time to start
>
> investigating
>
>>>it. I'll post patches here as I make progress.
>>
>>The correct behaviour will be to use in_addr_t, but it don't works on
>>iSeries (even if it's defined, I couldn't find the correct include).
>>
>>To fix the problem we could use a #define BSD64 ? to make use of
>>in_addr_t until we make more works ?
>>
>>Just provide the correct defined var for BSD/SPARC64
>>
>
>
> I'm thinking a define may not be needed. I mischaracterized the problem
> slightly... u_long on OpenBSD/sparc64 is 8 bytes long, so the memcpy copies
> 8 bytes into rc->sin_addr. The first four bytes are zeros the next four
> overwrite some of the rest of the struct.
>
> Would it fix the problem if laddr was defined as a datatype that is 4 bytes
> long on all arches? Maybe u_int32_t or struct in_addr (same as
> rc->sin_addr)?
Hum trying to play with bytes is not a good idea, we should stay with
socket API and types.
BTW, the current code is not compatible with IPv6, and we may have to
use APR supports API, which could break the consensus that JK should
works without requiring APR (or Apache 2.0).
The future will be mod_jk2, and I think we should focus on it after the
1.2.5 release.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Kurt Miller a écrit :
> From: "Henri Gomez" <hg...@apache.org>
>
>>Kurt Miller a écrit :
>>
>>
>>>From: "Henri Gomez" <hg...@apache.org>
>>>
>>>>It was u_long before I change it in in_addr_t and then change
>>>>it back to u_long.
>>>
>>>
>>>Oh. I guess I should have done a bit more research.;-) I just started
>>>attempting to get mod_jk going on sparc64 a few days ago. However, using
>
> a
>
>>>u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64.
>
> The
>
>>>memcpy at the end copies all zeros into rc->sin_addr when u_long is
>
> used.
>
>>>There are some other issues going on with mod_jk OpenBSD/sparc64, so its
>
> not
>
>>>yet working even with this corrected. Given that, it may not make sense
>
> to
>
>>>hold up the release for this. I will need to put in more time to
>
> investigate
>
>>>the next issue.
>>>
>>>OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the
>
> new
>
>>>APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they
>
> all
>
>>>don't work. It wasn't until recently that I had time to start
>
> investigating
>
>>>it. I'll post patches here as I make progress.
>>
>>The correct behaviour will be to use in_addr_t, but it don't works on
>>iSeries (even if it's defined, I couldn't find the correct include).
>>
>>To fix the problem we could use a #define BSD64 ? to make use of
>>in_addr_t until we make more works ?
>>
>>Just provide the correct defined var for BSD/SPARC64
>>
>
>
> I'm thinking a define may not be needed. I mischaracterized the problem
> slightly... u_long on OpenBSD/sparc64 is 8 bytes long, so the memcpy copies
> 8 bytes into rc->sin_addr. The first four bytes are zeros the next four
> overwrite some of the rest of the struct.
>
> Would it fix the problem if laddr was defined as a datatype that is 4 bytes
> long on all arches? Maybe u_int32_t or struct in_addr (same as
> rc->sin_addr)?
Hum trying to play with bytes is not a good idea, we should stay with
socket API and types.
BTW, the current code is not compatible with IPv6, and we may have to
use APR supports API, which could break the consensus that JK should
works without requiring APR (or Apache 2.0).
The future will be mod_jk2, and I think we should focus on it after the
1.2.5 release.
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Henri Gomez" <hg...@apache.org>
> Kurt Miller a écrit :
>
> > From: "Henri Gomez" <hg...@apache.org>
> >
> >>It was u_long before I change it in in_addr_t and then change
> >>it back to u_long.
> >
> >
> > Oh. I guess I should have done a bit more research.;-) I just started
> > attempting to get mod_jk going on sparc64 a few days ago. However, using
a
> > u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64.
The
> > memcpy at the end copies all zeros into rc->sin_addr when u_long is
used.
> >
> > There are some other issues going on with mod_jk OpenBSD/sparc64, so its
not
> > yet working even with this corrected. Given that, it may not make sense
to
> > hold up the release for this. I will need to put in more time to
investigate
> > the next issue.
> >
> > OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the
new
> > APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they
all
> > don't work. It wasn't until recently that I had time to start
investigating
> > it. I'll post patches here as I make progress.
>
> The correct behaviour will be to use in_addr_t, but it don't works on
> iSeries (even if it's defined, I couldn't find the correct include).
>
> To fix the problem we could use a #define BSD64 ? to make use of
> in_addr_t until we make more works ?
>
> Just provide the correct defined var for BSD/SPARC64
>
I'm thinking a define may not be needed. I mischaracterized the problem
slightly... u_long on OpenBSD/sparc64 is 8 bytes long, so the memcpy copies
8 bytes into rc->sin_addr. The first four bytes are zeros the next four
overwrite some of the rest of the struct.
Would it fix the problem if laddr was defined as a datatype that is 4 bytes
long on all arches? Maybe u_int32_t or struct in_addr (same as
rc->sin_addr)?
-Kurt
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Henri Gomez" <hg...@apache.org>
> Kurt Miller a écrit :
>
> > From: "Henri Gomez" <hg...@apache.org>
> >
> >>It was u_long before I change it in in_addr_t and then change
> >>it back to u_long.
> >
> >
> > Oh. I guess I should have done a bit more research.;-) I just started
> > attempting to get mod_jk going on sparc64 a few days ago. However, using
a
> > u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64.
The
> > memcpy at the end copies all zeros into rc->sin_addr when u_long is
used.
> >
> > There are some other issues going on with mod_jk OpenBSD/sparc64, so its
not
> > yet working even with this corrected. Given that, it may not make sense
to
> > hold up the release for this. I will need to put in more time to
investigate
> > the next issue.
> >
> > OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the
new
> > APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they
all
> > don't work. It wasn't until recently that I had time to start
investigating
> > it. I'll post patches here as I make progress.
>
> The correct behaviour will be to use in_addr_t, but it don't works on
> iSeries (even if it's defined, I couldn't find the correct include).
>
> To fix the problem we could use a #define BSD64 ? to make use of
> in_addr_t until we make more works ?
>
> Just provide the correct defined var for BSD/SPARC64
>
I'm thinking a define may not be needed. I mischaracterized the problem
slightly... u_long on OpenBSD/sparc64 is 8 bytes long, so the memcpy copies
8 bytes into rc->sin_addr. The first four bytes are zeros the next four
overwrite some of the rest of the struct.
Would it fix the problem if laddr was defined as a datatype that is 4 bytes
long on all arches? Maybe u_int32_t or struct in_addr (same as
rc->sin_addr)?
-Kurt
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Kurt Miller a écrit :
> From: "Henri Gomez" <hg...@apache.org>
>
>>It was u_long before I change it in in_addr_t and then change
>>it back to u_long.
>
>
> Oh. I guess I should have done a bit more research.;-) I just started
> attempting to get mod_jk going on sparc64 a few days ago. However, using a
> u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The
> memcpy at the end copies all zeros into rc->sin_addr when u_long is used.
>
> There are some other issues going on with mod_jk OpenBSD/sparc64, so its not
> yet working even with this corrected. Given that, it may not make sense to
> hold up the release for this. I will need to put in more time to investigate
> the next issue.
>
> OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new
> APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all
> don't work. It wasn't until recently that I had time to start investigating
> it. I'll post patches here as I make progress.
The correct behaviour will be to use in_addr_t, but it don't works on
iSeries (even if it's defined, I couldn't find the correct include).
To fix the problem we could use a #define BSD64 ? to make use of
in_addr_t until we make more works ?
Just provide the correct defined var for BSD/SPARC64
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Kurt Miller a écrit :
> From: "Henri Gomez" <hg...@apache.org>
>
>>It was u_long before I change it in in_addr_t and then change
>>it back to u_long.
>
>
> Oh. I guess I should have done a bit more research.;-) I just started
> attempting to get mod_jk going on sparc64 a few days ago. However, using a
> u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The
> memcpy at the end copies all zeros into rc->sin_addr when u_long is used.
>
> There are some other issues going on with mod_jk OpenBSD/sparc64, so its not
> yet working even with this corrected. Given that, it may not make sense to
> hold up the release for this. I will need to put in more time to investigate
> the next issue.
>
> OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new
> APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all
> don't work. It wasn't until recently that I had time to start investigating
> it. I'll post patches here as I make progress.
The correct behaviour will be to use in_addr_t, but it don't works on
iSeries (even if it's defined, I couldn't find the correct include).
To fix the problem we could use a #define BSD64 ? to make use of
in_addr_t until we make more works ?
Just provide the correct defined var for BSD/SPARC64
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Henri Gomez" <hg...@apache.org>
> It was u_long before I change it in in_addr_t and then change
> it back to u_long.
Oh. I guess I should have done a bit more research.;-) I just started
attempting to get mod_jk going on sparc64 a few days ago. However, using a
u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The
memcpy at the end copies all zeros into rc->sin_addr when u_long is used.
There are some other issues going on with mod_jk OpenBSD/sparc64, so its not
yet working even with this corrected. Given that, it may not make sense to
hold up the release for this. I will need to put in more time to investigate
the next issue.
OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new
APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all
don't work. It wasn't until recently that I had time to start investigating
it. I'll post patches here as I make progress.
-Kurt
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Henri Gomez" <hg...@apache.org>
> It was u_long before I change it in in_addr_t and then change
> it back to u_long.
Oh. I guess I should have done a bit more research.;-) I just started
attempting to get mod_jk going on sparc64 a few days ago. However, using a
u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The
memcpy at the end copies all zeros into rc->sin_addr when u_long is used.
There are some other issues going on with mod_jk OpenBSD/sparc64, so its not
yet working even with this corrected. Given that, it may not make sense to
hold up the release for this. I will need to put in more time to investigate
the next issue.
OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new
APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all
don't work. It wasn't until recently that I had time to start investigating
it. I'll post patches here as I make progress.
-Kurt
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Kurt Miller a écrit :
> From: "Glenn Nielsen" <gl...@mail.more.net>
> To: <to...@jakarta.apache.org>
> Sent: Friday, August 01, 2003 6:39 AM
> Subject: [VOTE] Release mod_jk 1.2.5
>
>
>
>>No problems have been reported since the last test source distribution
>>of mod_jk 1.2.5 was made available for testing July 26.
>>
>
>
> I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The
> recent change of the datatype of laddr from in_addr_t to u_long has broken
> this function. Could this be reverted back before release? Below is a copy
> of the commit that caused the problem:
>
> hgomez 2003/07/25 07:58:22
>
> Modified: jk/native/common jk_connect.c
> Log:
> Use u_long instead of in_addr_t which make unhappy some platforms like
> iSeries
>
>
> Revision Changes Path
> 1.10 +2 -3
> jakarta-tomcat-connectors/jk/native/common/jk_connect.c
>
> Index: jk_connect.c
> ===================================================================
> RCS file:
> /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- jk_connect.c 24 Jul 2003 08:17:10 -0000 1.9
> +++ jk_connect.c 25 Jul 2003 14:58:22 -0000 1.10
> @@ -110,8 +110,7 @@
> int x;
>
> /* TODO: Should be updated for IPV6 support. */
> - /* for now use the correct type, in_addr_t */
> - in_addr_t laddr;
> + u_long laddr;
>
> rc->sin_port = htons((short)port);
> rc->sin_family = AF_INET;
>
> -Kurt
>
It was u_long before I change it in in_addr_t and then change
it back to u_long.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Glenn Nielsen <gl...@mail.more.net>.
I can confirm what Henri said, laddr had always been a ulong and
was only type in_addr_t for a short period of time.
Does mod_jk 1.2.4 build and work correctly? It used a ulong for laddr.
What web server are you building this for?
If you are building for Apache 2 it may be a problem with the APR code.
Regards,
Glenn
Kurt Miller wrote:
> From: "Glenn Nielsen" <gl...@mail.more.net>
> To: <to...@jakarta.apache.org>
> Sent: Friday, August 01, 2003 6:39 AM
> Subject: [VOTE] Release mod_jk 1.2.5
>
>
>
>>No problems have been reported since the last test source distribution
>>of mod_jk 1.2.5 was made available for testing July 26.
>>
>
>
> I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The
> recent change of the datatype of laddr from in_addr_t to u_long has broken
> this function. Could this be reverted back before release? Below is a copy
> of the commit that caused the problem:
>
> hgomez 2003/07/25 07:58:22
>
> Modified: jk/native/common jk_connect.c
> Log:
> Use u_long instead of in_addr_t which make unhappy some platforms like
> iSeries
>
>
> Revision Changes Path
> 1.10 +2 -3
> jakarta-tomcat-connectors/jk/native/common/jk_connect.c
>
> Index: jk_connect.c
> ===================================================================
> RCS file:
> /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- jk_connect.c 24 Jul 2003 08:17:10 -0000 1.9
> +++ jk_connect.c 25 Jul 2003 14:58:22 -0000 1.10
> @@ -110,8 +110,7 @@
> int x;
>
> /* TODO: Should be updated for IPV6 support. */
> - /* for now use the correct type, in_addr_t */
> - in_addr_t laddr;
> + u_long laddr;
>
> rc->sin_port = htons((short)port);
> rc->sin_family = AF_INET;
>
> -Kurt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Kurt Miller a écrit :
> From: "Glenn Nielsen" <gl...@mail.more.net>
> To: <to...@jakarta.apache.org>
> Sent: Friday, August 01, 2003 6:39 AM
> Subject: [VOTE] Release mod_jk 1.2.5
>
>
>
>>No problems have been reported since the last test source distribution
>>of mod_jk 1.2.5 was made available for testing July 26.
>>
>
>
> I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The
> recent change of the datatype of laddr from in_addr_t to u_long has broken
> this function. Could this be reverted back before release? Below is a copy
> of the commit that caused the problem:
>
> hgomez 2003/07/25 07:58:22
>
> Modified: jk/native/common jk_connect.c
> Log:
> Use u_long instead of in_addr_t which make unhappy some platforms like
> iSeries
>
>
> Revision Changes Path
> 1.10 +2 -3
> jakarta-tomcat-connectors/jk/native/common/jk_connect.c
>
> Index: jk_connect.c
> ===================================================================
> RCS file:
> /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- jk_connect.c 24 Jul 2003 08:17:10 -0000 1.9
> +++ jk_connect.c 25 Jul 2003 14:58:22 -0000 1.10
> @@ -110,8 +110,7 @@
> int x;
>
> /* TODO: Should be updated for IPV6 support. */
> - /* for now use the correct type, in_addr_t */
> - in_addr_t laddr;
> + u_long laddr;
>
> rc->sin_port = htons((short)port);
> rc->sin_family = AF_INET;
>
> -Kurt
>
It was u_long before I change it in in_addr_t and then change
it back to u_long.
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Glenn Nielsen" <gl...@mail.more.net>
To: <to...@jakarta.apache.org>
Sent: Friday, August 01, 2003 6:39 AM
Subject: [VOTE] Release mod_jk 1.2.5
> No problems have been reported since the last test source distribution
> of mod_jk 1.2.5 was made available for testing July 26.
>
I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The
recent change of the datatype of laddr from in_addr_t to u_long has broken
this function. Could this be reverted back before release? Below is a copy
of the commit that caused the problem:
hgomez 2003/07/25 07:58:22
Modified: jk/native/common jk_connect.c
Log:
Use u_long instead of in_addr_t which make unhappy some platforms like
iSeries
Revision Changes Path
1.10 +2 -3
jakarta-tomcat-connectors/jk/native/common/jk_connect.c
Index: jk_connect.c
===================================================================
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- jk_connect.c 24 Jul 2003 08:17:10 -0000 1.9
+++ jk_connect.c 25 Jul 2003 14:58:22 -0000 1.10
@@ -110,8 +110,7 @@
int x;
/* TODO: Should be updated for IPV6 support. */
- /* for now use the correct type, in_addr_t */
- in_addr_t laddr;
+ u_long laddr;
rc->sin_port = htons((short)port);
rc->sin_family = AF_INET;
-Kurt
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Henri Gomez a écrit :
> Glenn Nielsen a écrit :
>
>> No problems have been reported since the last test source distribution
>> of mod_jk 1.2.5 was made available for testing July 26.
>>
>> <ballot>
>> Please vote on a release of mod_jk 1.2.5:
>>
>> [X] +1 release, and I will help build binaries for _________ os/web
>> server
>> [ ] +0 ok to release
>> [ ] -0 release, but I still have a problem with _____
>> [ ] -1 don't release, there is a problem with _____
>> </ballot>
>
>
> BTW, I'll be on holidays for 3 weeks starting tomorrow,
> so you should some helps for Linux binaries ;)
For help on Linux binaries, you should contact my friend
at www.jpackage.org which allready produce jk binaries for
many Linux distribution, take a look at :
http://dl.sf.net/jpackage/direct_download/1.5/
Regards
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Henri Gomez a écrit :
> Glenn Nielsen a écrit :
>
>> No problems have been reported since the last test source distribution
>> of mod_jk 1.2.5 was made available for testing July 26.
>>
>> <ballot>
>> Please vote on a release of mod_jk 1.2.5:
>>
>> [X] +1 release, and I will help build binaries for _________ os/web
>> server
>> [ ] +0 ok to release
>> [ ] -0 release, but I still have a problem with _____
>> [ ] -1 don't release, there is a problem with _____
>> </ballot>
>
>
> BTW, I'll be on holidays for 3 weeks starting tomorrow,
> so you should some helps for Linux binaries ;)
For help on Linux binaries, you should contact my friend
at www.jpackage.org which allready produce jk binaries for
many Linux distribution, take a look at :
http://dl.sf.net/jpackage/direct_download/1.5/
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Glenn Nielsen a écrit :
> No problems have been reported since the last test source distribution
> of mod_jk 1.2.5 was made available for testing July 26.
>
> <ballot>
> Please vote on a release of mod_jk 1.2.5:
>
> [X] +1 release, and I will help build binaries for _________ os/web server
> [ ] +0 ok to release
> [ ] -0 release, but I still have a problem with _____
> [ ] -1 don't release, there is a problem with _____
> </ballot>
BTW, I'll be on holidays for 3 weeks starting tomorrow,
so you should some helps for Linux binaries ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Glenn Nielsen a écrit :
> No problems have been reported since the last test source distribution
> of mod_jk 1.2.5 was made available for testing July 26.
>
> <ballot>
> Please vote on a release of mod_jk 1.2.5:
>
> [X] +1 release, and I will help build binaries for _________ os/web server
> [ ] +0 ok to release
> [ ] -0 release, but I still have a problem with _____
> [ ] -1 don't release, there is a problem with _____
> </ballot>
BTW, I'll be on holidays for 3 weeks starting tomorrow,
so you should some helps for Linux binaries ;)
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Glenn Nielsen" <gl...@mail.more.net>
> Henri Gomez wrote:
> > Joseph Shraibman a écrit :
> >
> >> Glenn Nielsen wrote:
> >>
> >>> No problems have been reported since the last test source distribution
> >>> of mod_jk 1.2.5 was made available for testing July 26.
> >>>
> >>> <ballot>
> >>> Please vote on a release of mod_jk 1.2.5:
> >>>
> >>> [ ] +1 release, and I will help build binaries for _________ os/web
> >>> server
> >>> [ ] +0 ok to release
> >>> [ ] -0 release, but I still have a problem with _____
> >>> [ ] -1 don't release, there is a problem with _____
> >>> </ballot>
> >>>
> >>> The votes will be counted Monday August 4 and the source dist
> >>> release made if the vote passes.
> >>
> >>
> >>
> >> So whatever happened? Why wasn't 1.2.5 released?
> >
> >
> > Glenn could you tag jk (with my latest jk_connect.c patch) for jk 1.2.5
> > and make the release ?
> >
> > It will make jk compatible with OpenBSD/64
> >
>
> Yeah, I was waiting on that. Plus there is that recent thread safe
> issue which was raised with the uri mapping.
>
Thank you Glenn and Henri.
-Kurt
Re: [VOTE] Release mod_jk 1.2.5
Posted by Glenn Nielsen <gl...@mail.more.net>.
Henri Gomez wrote:
> Joseph Shraibman a écrit :
>
>> Glenn Nielsen wrote:
>>
>>> No problems have been reported since the last test source distribution
>>> of mod_jk 1.2.5 was made available for testing July 26.
>>>
>>> <ballot>
>>> Please vote on a release of mod_jk 1.2.5:
>>>
>>> [ ] +1 release, and I will help build binaries for _________ os/web
>>> server
>>> [ ] +0 ok to release
>>> [ ] -0 release, but I still have a problem with _____
>>> [ ] -1 don't release, there is a problem with _____
>>> </ballot>
>>>
>>> The votes will be counted Monday August 4 and the source dist
>>> release made if the vote passes.
>>
>>
>>
>> So whatever happened? Why wasn't 1.2.5 released?
>
>
> Glenn could you tag jk (with my latest jk_connect.c patch) for jk 1.2.5
> and make the release ?
>
> It will make jk compatible with OpenBSD/64
>
Yeah, I was waiting on that. Plus there is that recent thread safe
issue which was raised with the uri mapping.
Glenn
Re: [VOTE] Release mod_jk 1.2.5
Posted by Henri Gomez <hg...@apache.org>.
Joseph Shraibman a écrit :
> Glenn Nielsen wrote:
>
>> No problems have been reported since the last test source distribution
>> of mod_jk 1.2.5 was made available for testing July 26.
>>
>> <ballot>
>> Please vote on a release of mod_jk 1.2.5:
>>
>> [ ] +1 release, and I will help build binaries for _________ os/web
>> server
>> [ ] +0 ok to release
>> [ ] -0 release, but I still have a problem with _____
>> [ ] -1 don't release, there is a problem with _____
>> </ballot>
>>
>> The votes will be counted Monday August 4 and the source dist
>> release made if the vote passes.
>
>
> So whatever happened? Why wasn't 1.2.5 released?
Glenn could you tag jk (with my latest jk_connect.c patch) for jk 1.2.5
and make the release ?
It will make jk compatible with OpenBSD/64
Re: [VOTE] Release mod_jk 1.2.5
Posted by Joseph Shraibman <jk...@selectacast.net>.
Glenn Nielsen wrote:
> No problems have been reported since the last test source distribution
> of mod_jk 1.2.5 was made available for testing July 26.
>
> <ballot>
> Please vote on a release of mod_jk 1.2.5:
>
> [ ] +1 release, and I will help build binaries for _________ os/web server
> [ ] +0 ok to release
> [ ] -0 release, but I still have a problem with _____
> [ ] -1 don't release, there is a problem with _____
> </ballot>
>
> The votes will be counted Monday August 4 and the source dist
> release made if the vote passes.
So whatever happened? Why wasn't 1.2.5 released?
Re: [VOTE] Release mod_jk 1.2.5
Posted by Kurt Miller <tr...@optonline.net>.
From: "Glenn Nielsen" <gl...@mail.more.net>
To: <to...@jakarta.apache.org>
Sent: Friday, August 01, 2003 6:39 AM
Subject: [VOTE] Release mod_jk 1.2.5
> No problems have been reported since the last test source distribution
> of mod_jk 1.2.5 was made available for testing July 26.
>
I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The
recent change of the datatype of laddr from in_addr_t to u_long has broken
this function. Could this be reverted back before release? Below is a copy
of the commit that caused the problem:
hgomez 2003/07/25 07:58:22
Modified: jk/native/common jk_connect.c
Log:
Use u_long instead of in_addr_t which make unhappy some platforms like
iSeries
Revision Changes Path
1.10 +2 -3
jakarta-tomcat-connectors/jk/native/common/jk_connect.c
Index: jk_connect.c
===================================================================
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- jk_connect.c 24 Jul 2003 08:17:10 -0000 1.9
+++ jk_connect.c 25 Jul 2003 14:58:22 -0000 1.10
@@ -110,8 +110,7 @@
int x;
/* TODO: Should be updated for IPV6 support. */
- /* for now use the correct type, in_addr_t */
- in_addr_t laddr;
+ u_long laddr;
rc->sin_port = htons((short)port);
rc->sin_family = AF_INET;
-Kurt