tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <hgo...@apache.org>
Subject Re: [VOTE] Release mod_jk 1.2.5
Date Fri, 01 Aug 2003 15:05:49 GMT
Kurt Miller a écrit :

> From: "Henri Gomez" <hgomez@apache.org>
> 
>>Kurt Miller a écrit :
>>
>>
>>>From: "Henri Gomez" <hgomez@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.




Mime
View raw message