DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17193>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17193 java.net.bindException during shutdown in Tomcat 4.1.18 ------- Additional Comments From [EMAIL PROTECTED] 2003-09-08 13:51 ------- Right. This doesn't look like it's been fixed in CVS at all, as far as I can see - Costin, can you remember why you made the comment you did? (The original comment about the cause of the problem is spot on.) I'm using Tomcat 4.1.27, and have modified the source locally just to check whether inet.toString().equals ("0.0.0.0/0.0.0.0") and use 127.0.0.1 if so. That doesn't feel like a good fix to me, however - I don't like comparing the contents of .toString with anything else. Do we know why inet is being set to 0.0.0.0 in the first place? Is there anything wrong with leaving it as null, but using an inet address of 0.0.0.0 in init instead? Really, this is a question of whether other classes will assume that inet is going to have a non-null value. (It's got package protection, so is available from other classes.) I don't think I know enough about jk2 to fix this *properly* myself, though I may well be able to fix it well enough to make do for the installations I'll be using it with (eg no JMX etc). I certainly need to get it cleared up to *some* extent before I can ship Tomcat 4.1 with our product. Does anyone with a bit more knowledge (not saying much :) fancy commenting on this, or shall I implement my own somewhat hacky solution for my own private use? (I really don't think I could come up with one I'd be happy enough to submit as a patch.) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
