RE: Tagging JK_1_2_8_RC_1 today 18:00 GMT
Dear Mladen, We have now recognized that you are the absolute computer-superhero and that no one knows the web better than you do. But WE (as I told you recently) are the students council of a university which means that we just care about REAL knowledge (like philosophy, medicine, law, etc.) and are not interested in playing the webmaster and care about stuff like spamfilters and so on. So would you PLEASE in your greatest wisdom cancel the adress [EMAIL PROTECTED] from your maillist? Would you...? Please...? Merry Christmas and a happy new year! Sebastian Weisenburger Zentrale Studienberatung Ludwig-Maximilians-Universitaet Muenchen Postanschrift: Geschw.-Scholl-Pl. 1 80539 Muenchen Dienstgebäude: Ludwigstr. 27/I fon: ++49-89-2180 2345 fax: ++49-89-2180 2967 mailto: [EMAIL PROTECTED] -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Thursday, December 23, 2004 8:53 AM To: Tomcat Developers List Subject: Re: Tagging JK_1_2_8_RC_1 today 18:00 GMT William A. Rowe, Jr. wrote: There are still one potential bug present, reported by Henri Gomez with Tomcat 3.3.2. The other issue is to see the URL rewriting problem reported by Derrick Koes. Since there is the possibility that they are related, I'll leave that for 1.2.8 final. The later one has been fixed in 1.2.8-RC-1. I have tested the 3.3.2 myself and seen no errors whatsoever, so that one if fixed too AFAICT. That's cool, but the handling of in_addr_t is totally bogus and has been for some time. Some platforms declare struct in_addr_t as a typedef - but others don't. The crossplatform solution is to ignore the typedef and use in_addr_t, but instead, the code currently does some crap with uint for win32 and ignores HP/UX and a host of other platforms. I'll offer a patch in the next 24 hours to handle the in_addr_t data gracefully and without a host of compiler emits and build failures. No functional changes required :) OK. I'm also waiting Jean-Jaques Clar for a Netware threading patch. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tagging JK_1_2_8_RC_1 today 18:00 GMT
Dear Mladen, We have now recognized that you are the absolute computer-superhero and that no one knows the web better than you do. But WE (as I told you recently) are the students council of a university which means that we just care about REAL knowledge (like philosophy, medicine, law, etc.) and are not interested in playing the webmaster and care about stuff like spamfilters and so on. So would you PLEASE in your greatest wisdom cancel the adress [EMAIL PROTECTED] from your maillist? Would you...? Please...? Merry Christmas and a happy new year! Sebastian Weisenburger Zentrale Studienberatung Ludwig-Maximilians-Universitaet Muenchen Postanschrift: Geschw.-Scholl-Pl. 1 80539 Muenchen Dienstgebäude: Ludwigstr. 27/I fon: ++49-89-2180 2345 fax: ++49-89-2180 2967 mailto: [EMAIL PROTECTED] -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Thursday, December 23, 2004 8:53 AM To: Tomcat Developers List Subject: Re: Tagging JK_1_2_8_RC_1 today 18:00 GMT William A. Rowe, Jr. wrote: There are still one potential bug present, reported by Henri Gomez with Tomcat 3.3.2. The other issue is to see the URL rewriting problem reported by Derrick Koes. Since there is the possibility that they are related, I'll leave that for 1.2.8 final. The later one has been fixed in 1.2.8-RC-1. I have tested the 3.3.2 myself and seen no errors whatsoever, so that one if fixed too AFAICT. That's cool, but the handling of in_addr_t is totally bogus and has been for some time. Some platforms declare struct in_addr_t as a typedef - but others don't. The crossplatform solution is to ignore the typedef and use in_addr_t, but instead, the code currently does some crap with uint for win32 and ignores HP/UX and a host of other platforms. I'll offer a patch in the next 24 hours to handle the in_addr_t data gracefully and without a host of compiler emits and build failures. No functional changes required :) OK. I'm also waiting Jean-Jaques Clar for a Netware threading patch. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK_1_2_8_RC_1 today 18:00 GMT
At 01:52 AM 12/23/2004, Mladen Turk wrote: That's cool, but the handling of in_addr_t is totally bogus and has been for some time. Some platforms declare struct in_addr_t as a typedef - but others don't. The crossplatform solution is to ignore the typedef and use in_addr_t, but instead, the code currently does some crap with uint for win32 and ignores HP/UX and a host of other platforms. I'll offer a patch in the next 24 hours to handle the in_addr_t data gracefully and without a host of compiler emits and build failures. No functional changes required :) OK. By the way, I agree the code had no emits. It's easy to eliminate compile emits by (cast)ing them away. Yes - the patch keeps one cast, it's necessary due to the bogus definition of the hostent structure which was stillborn, braindead :) However, the code didn't compile on non-win32/netware platforms with no in_addr_t typedef, so it was still quite non-portable. The patch corrects for all platforms, not just one-off cases. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK_1_2_8_RC_1 today 18:00 GMT
ZentraleStudienberatung wrote: Dear Mladen, We have now recognized that you are the absolute computer-superhero and that no one knows the web better than you do. At first mail you said Stop spamming us, or we'll call the police!!! Now, I'm superhero, cool :). But WE (as I told you recently) are the students council of a university which means that we just care about REAL knowledge (like philosophy, medicine, law, etc.) and are not interested in playing the webmaster and care about stuff like spamfilters and so on. So would you PLEASE in your greatest wisdom cancel the adress [EMAIL PROTECTED] from your maillist? How many times do I have to tell you that this is not mine maillist. If you wish to unsubscribe from the 'Tomcat Developers List' you can do that on the same page YOU subscribed in. http://jakarta.apache.org/site/mail2.html#Tomcat Would you...? Please...? Can not do that. I'm not the list admin. - To unsubscribe, e-mail: [EMAIL PROTECTED] See? Each mail contains the unsubscribe info. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK_1_2_8_RC_1 today 18:00 GMT
At 03:36 AM 12/17/2004, Mladen Turk wrote: The 1.2.7 release has done it's share of work by testing all those new features added. The 1.2.8-rc-1 will add no new features. There are still one potential bug present, reported by Henri Gomez with Tomcat 3.3.2. The other issue is to see the URL rewriting problem reported by Derrick Koes. Since there is the possibility that they are related, I'll leave that for 1.2.8 final. That's cool, but the handling of in_addr_t is totally bogus and has been for some time. Some platforms declare struct in_addr_t as a typedef - but others don't. The crossplatform solution is to ignore the typedef and use in_addr_t, but instead, the code currently does some crap with uint for win32 and ignores HP/UX and a host of other platforms. I'll offer a patch in the next 24 hours to handle the in_addr_t data gracefully and without a host of compiler emits and build failures. No functional changes required :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK_1_2_8_RC_1 today 18:00 GMT
At 01:13 AM 12/23/2004, William A. Rowe, Jr. wrote:
At 03:36 AM 12/17/2004, Mladen Turk wrote:
The 1.2.8-rc-1 will add no new features.
That's cool, but the handling of in_addr_t is totally bogus and
has been for some time. Some platforms declare struct in_addr_t
as a typedef - but others don't. The crossplatform solution is
to ignore the typedef and use in_addr_t, but instead, the code
currently does some crap with uint for win32 and ignores HP/UX
and a host of other platforms.
I ment use struct in_addr. In any case, attached is the patch
for your perusal - it fixes one other non-conformant typedef
(that didn't match the pattern throughout jk) in jk_pool.h.
Please consider both for a much cleaner source pattern.
Bill
Index: jk/native/common/jk_connect.c
===
RCS file:
/var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/common/jk_connect.c,v
retrieving revision 1.35
diff -u -r1.35 jk_connect.c
--- jk/native/common/jk_connect.c 17 Dec 2004 14:58:37 - 1.35
+++ jk/native/common/jk_connect.c 23 Dec 2004 07:43:30 -
@@ -35,10 +35,6 @@
#include apr_general.h
#endif
-#if defined(WIN32)
-typedef u_long in_addr_t;
-#endif
-
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
#define JK_IS_SOCKET_ERROR(x) ((x) == SOCKET_ERROR)
#define JK_GET_SOCKET_ERRNO() errno = WSAGetLastError() - WSABASEERR
@@ -53,15 +49,7 @@
int jk_resolve(char *host, int port, struct sockaddr_in *rc)
{
int x;
-
-/* TODO: Should be updated for IPV6 support. */
-/* for now use the correct type, in_addr_t */
-/* except on NetWare since the MetroWerks compiler is so strict */
-#if defined(NETWARE)
-u_long laddr;
-#else
-in_addr_t laddr;
-#endif
+struct in_addr laddr;
memset(rc, 0, sizeof(struct sockaddr_in));
@@ -119,13 +107,13 @@
return JK_FALSE;
}
-laddr = ((struct in_addr *)hoste-h_addr_list[0])-s_addr;
+laddr = *((struct in_addr *)hoste-h_addr_list[0]);
#endif /* HAVE_APR */
}
else {
/* If we found only digits we use inet_addr() */
-laddr = inet_addr(host);
+laddr.s_addr = inet_addr(host);
}
memcpy((rc-sin_addr), laddr, sizeof(laddr));
Index: jk/native/common/jk_pool.h
===
RCS file:
/var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/common/jk_pool.h,v
retrieving revision 1.9
diff -u -r1.9 jk_pool.h
--- jk/native/common/jk_pool.h 8 Nov 2004 13:32:56 - 1.9
+++ jk/native/common/jk_pool.h 23 Dec 2004 07:43:30 -
@@ -93,9 +93,8 @@
#define BIG_POOL_SIZE 2*SMALL_POOL_SIZE /* Bigger 1K atom pool. */
#define HUGE_POOL_SIZE 2*BIG_POOL_SIZE /* Huge 2K atom pool. */
-typedef struct jk_pool_t jk_pool_t;
/** jk pool structure */
-struct jk_pool_t
+struct jk_pool
{
size_t size;
size_t pos;
@@ -104,6 +103,8 @@
size_t dyn_pos;
void **dynamic;
};
+
+typedef struct jk_pool jk_pool_t;
void jk_open_pool(jk_pool_t *p, jk_pool_atom_t *buf, size_t size);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Patch, rev 2] Tagging JK_1_2_8_RC_1 today 18:00 GMT
This is a better patch, it also covers the deprecated code
that still exists in the HAVE_APR path.
At 01:46 AM 12/23/2004, William A. Rowe, Jr. wrote:
At 01:13 AM 12/23/2004, William A. Rowe, Jr. wrote:
At 03:36 AM 12/17/2004, Mladen Turk wrote:
The 1.2.8-rc-1 will add no new features.
That's cool, but the handling of in_addr_t is totally bogus and
has been for some time. Some platforms declare struct in_addr_t
as a typedef - but others don't. The crossplatform solution is
to ignore the typedef and use in_addr_t, but instead, the code
currently does some crap with uint for win32 and ignores HP/UX
and a host of other platforms.
I ment use struct in_addr. In any case, attached is the patch
for your perusal - it fixes one other non-conformant typedef
(that didn't match the pattern throughout jk) in jk_pool.h.
Please consider both for a much cleaner source pattern.
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
? .flavour_complete
? foo
? patch
? jk/native/apache-2.0/Debug
? jk/native/apache-2.0/Release
? jk/native/apache-2.0/mod_jk.dsw
? jk/native/apache-2.0/mod_jk.ncb
? jk/native/apache-2.0/mod_jk.opt
? jk/native/apache-2.0/mod_jk.plg
? jk/native/nt_service/Release
? jk/native/nt_service/nt_service.plg
Index: jk/native/common/jk_connect.c
===
RCS file:
/var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/common/jk_connect.c,v
retrieving revision 1.35
diff -u -r1.35 jk_connect.c
--- jk/native/common/jk_connect.c 17 Dec 2004 14:58:37 - 1.35
+++ jk/native/common/jk_connect.c 23 Dec 2004 07:50:22 -
@@ -35,10 +35,6 @@
#include apr_general.h
#endif
-#if defined(WIN32)
-typedef u_long in_addr_t;
-#endif
-
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
#define JK_IS_SOCKET_ERROR(x) ((x) == SOCKET_ERROR)
#define JK_GET_SOCKET_ERRNO() errno = WSAGetLastError() - WSABASEERR
@@ -53,15 +49,7 @@
int jk_resolve(char *host, int port, struct sockaddr_in *rc)
{
int x;
-
-/* TODO: Should be updated for IPV6 support. */
-/* for now use the correct type, in_addr_t */
-/* except on NetWare since the MetroWerks compiler is so strict */
-#if defined(NETWARE)
-u_long laddr;
-#else
-in_addr_t laddr;
-#endif
+struct in_addr laddr;
memset(rc, 0, sizeof(struct sockaddr_in));
@@ -105,7 +93,7 @@
return JK_FALSE;
apr_sockaddr_ip_get(remote_ipaddr, remote_sa);
-laddr = inet_addr(remote_ipaddr);
+laddr.s_addr = inet_addr(remote_ipaddr);
/* May be we could avoid to delete it each time ? */
apr_pool_destroy(context);
@@ -119,13 +107,13 @@
return JK_FALSE;
}
-laddr = ((struct in_addr *)hoste-h_addr_list[0])-s_addr;
+laddr = *((struct in_addr *)hoste-h_addr_list[0]);
#endif /* HAVE_APR */
}
else {
/* If we found only digits we use inet_addr() */
-laddr = inet_addr(host);
+laddr.s_addr = inet_addr(host);
}
memcpy((rc-sin_addr), laddr, sizeof(laddr));
Index: jk/native/common/jk_pool.h
===
RCS file:
/var/covalent/.CVS/apache-cvs/jakarta-tomcat-connectors-cvs/jk/native/common/jk_pool.h,v
retrieving revision 1.9
diff -u -r1.9 jk_pool.h
--- jk/native/common/jk_pool.h 8 Nov 2004 13:32:56 - 1.9
+++ jk/native/common/jk_pool.h 23 Dec 2004 07:50:22 -
@@ -93,9 +93,8 @@
#define BIG_POOL_SIZE 2*SMALL_POOL_SIZE /* Bigger 1K atom pool. */
#define HUGE_POOL_SIZE 2*BIG_POOL_SIZE /* Huge 2K atom pool. */
-typedef struct jk_pool_t jk_pool_t;
/** jk pool structure */
-struct jk_pool_t
+struct jk_pool
{
size_t size;
size_t pos;
@@ -104,6 +103,8 @@
size_t dyn_pos;
void **dynamic;
};
+
+typedef struct jk_pool jk_pool_t;
void jk_open_pool(jk_pool_t *p, jk_pool_atom_t *buf, size_t size);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK_1_2_8_RC_1 today 18:00 GMT
William A. Rowe, Jr. wrote: There are still one potential bug present, reported by Henri Gomez with Tomcat 3.3.2. The other issue is to see the URL rewriting problem reported by Derrick Koes. Since there is the possibility that they are related, I'll leave that for 1.2.8 final. The later one has been fixed in 1.2.8-RC-1. I have tested the 3.3.2 myself and seen no errors whatsoever, so that one if fixed too AFAICT. That's cool, but the handling of in_addr_t is totally bogus and has been for some time. Some platforms declare struct in_addr_t as a typedef - but others don't. The crossplatform solution is to ignore the typedef and use in_addr_t, but instead, the code currently does some crap with uint for win32 and ignores HP/UX and a host of other platforms. I'll offer a patch in the next 24 hours to handle the in_addr_t data gracefully and without a host of compiler emits and build failures. No functional changes required :) OK. I'm also waiting Jean-Jaques Clar for a Netware threading patch. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tagging JK_1_2_8_RC_1 today 18:00 GMT
Hi, Just to keep the rhythm of releases :). The 1.2.7 release has done it's share of work by testing all those new features added. The 1.2.8-rc-1 will add no new features. There are still one potential bug present, reported by Henri Gomez with Tomcat 3.3.2. The other issue is to see the URL rewriting problem reported by Derrick Koes. Since there is the possibility that they are related, I'll leave that for 1.2.8 final. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
