Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
My priorities are kinda right... Get laid off by Sun in november, go on a long vacation in December (basically trying to get all my stuff toghether), find a new job in January, and start working on February... Sorry... It's ok. ;-) No, I didn't, but I'm sure that my inbox will start to be polluted by questions like how do I do that? WA_VERSION is not defined... Just to keep spam low, and if someone wants to port it, well, I'm not here to prevent them... You provide a good way and an option to other guy who want to support it. That is a way cool. Pier Punky -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Punky Tse [EMAIL PROTECTED] wrote: I had been make this patch for a very long time (3/4/5 months). And send to this list several times... If you like, just grap my patch and comit. (wa_version.h must be placed in include/ dir, and change to *whatever* version you like!) Punky, I appreciate your effort, but IMO, wa_version.h is way too utterly complicated. I'd add -DWEBAPP_VERSION=x to CFLAGS from the autoconf magicness, and go from there... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Pier Fumagalli wrote: Punky Tse [EMAIL PROTECTED] wrote: I had been make this patch for a very long time (3/4/5 months). And send to this list several times... If you like, just grap my patch and comit. (wa_version.h must be placed in include/ dir, and change to *whatever* version you like!) Punky, I appreciate your effort, but IMO, wa_version.h is way too utterly complicated. I'd add -DWEBAPP_VERSION=x to CFLAGS from the autoconf magicness, and go from there... Sorry man, when I saw Henri commited my version patch also this morning, and you've commited VERSION file. I had seen some conflicts. Hum what do you think? 1. incorporate VERSION file to (modified and clean) wa_version.h through configure? 2. delete wa_version.h and patch mod_webapp.c in apache-1.3 and apache-2.0 currently in CVS? 3. other ways? Sorry, I had made confusion to you guys. Pier Punky -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Sorry man, when I saw Henri commited my version patch also this morning, and you've commited VERSION file. I had seen some conflicts. I'll be +1 to keep wa_version.h : - it's the same way in mod_jk (merge merge said Jon) - it's the same way in httpd server And it works rigth now -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
GOMEZ Henri [EMAIL PROTECTED] wrote: Punky, I appreciate your effort, but IMO, wa_version.h is way too utterly complicated. I'd add -DWEBAPP_VERSION=x to CFLAGS from the autoconf magicness, and go from there... Hum, I just commited wa_version.h and it's really similar to what Jean-Frederic proposed and commited to mod_jk. And it's what httpd 2.0 (ap_release.h) use Well, it seriously look ugly though... Ok, I admit it might be a PITA cuz in Windows we can't simply do a `cat VERSION` and get that number in somewhere, but boy that wa_version header looks ugly... Just the fact that we somehow have an area to modify and one not, _is_ complicating things around... Secondly, I don't want to have alpha/beta/gamma/whatever compiled in the code: for releasing purpose, a code is x.x.x-dev if it's not associated with a tag, and x.x.x when it actually _IS_ associated with a tag... When we tag a release, we call it 1.2.0, and then depending on how well it goes, we can promote it from beta to gamma to whatever, but we will NOT rebuild the binaries... I'll commit a patch... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Secondly, I don't want to have alpha/beta/gamma/whatever compiled in the code: for releasing purpose, a code is x.x.x-dev if it's not associated with a tag, and x.x.x when it actually _IS_ associated with a tag... ditto, that's why the recent proposal from Remy for TC 4, was to use the Apache HTTPD release scheme x.y.z. You are x.y.z-dev up to the time you make a release where you became x.y.z When we tag a release, we call it 1.2.0, and then depending on how well it goes, we can promote it from beta to gamma to whatever, but we will NOT rebuild the binaries... I'll commit a patch... Simple, before release remove the -dev in wa_version.h ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Punky Tse [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: Punky Tse [EMAIL PROTECTED] wrote: I had been make this patch for a very long time (3/4/5 months). And send to this list several times... If you like, just grap my patch and comit. (wa_version.h must be placed in include/ dir, and change to *whatever* version you like!) Punky, I appreciate your effort, but IMO, wa_version.h is way too utterly complicated. I'd add -DWEBAPP_VERSION=x to CFLAGS from the autoconf magicness, and go from there... Sorry man, when I saw Henri commited my version patch also this morning, and you've commited VERSION file. I had seen some conflicts. Hum what do you think? 1. incorporate VERSION file to (modified and clean) wa_version.h through configure? 2. delete wa_version.h and patch mod_webapp.c in apache-1.3 and apache-2.0 currently in CVS? 3. other ways? Sorry, I had made confusion to you guys. The VERSION file is wrong because there's no chance in hell I'm going to get something out of it under Win32. So wa_version.h is all right (my mistake)... But that version.h takes complication to a next level You need to have a manual just to figure out WHAT you have to change... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Well, it seriously look ugly though... Ok, I admit it might be a PITA cuz in Windows we can't simply do a `cat VERSION` and get that number in somewhere, but boy that wa_version header looks ugly... I admited that it is ugly. See below. Just the fact that we somehow have an area to modify and one not, _is_ complicating things around... Secondly, I don't want to have alpha/beta/gamma/whatever compiled in the code: for releasing purpose, a code is x.x.x-dev if it's not associated with a tag, and x.x.x when it actually _IS_ associated with a tag... When we tag a release, we call it 1.2.0, and then depending on how well it goes, we can promote it from beta to gamma to whatever, but we will NOT rebuild the binaries... I'll commit a patch... See the attached wa_version I originally proposed. I initially copied this from httpd-2.0. See this thread: http://marc.theaimsgroup.com/?l=tomcat-devm=100878406017530w=2 The reason I change to mod_jk way is that JF suggested, and I followed. Hope this help. Pier Punky /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 1999-2001 The Apache Software Foundation. * * All rights reserved.* * * * = * * * * Redistribution and use in source and binary forms, with or without modi- * * fication, are permitted provided that the following conditions are met: * * * * 1. Redistributions of source code must retain the above copyright notice * *notice, this list of conditions and the following disclaimer. * * * * 2. Redistributions in binary form must reproduce the above copyright * *notice, this list of conditions and the following disclaimer in the * *documentation and/or other materials provided with the distribution. * * * * 3. The end-user documentation included with the redistribution, if any, * *must include the following acknowlegement: * * * * This product includes software developed by the Apache Software * *Foundation http://www.apache.org/. * * * *Alternately, this acknowlegement may appear in the software itself, if * *and wherever such third-party acknowlegements normally appear. * * * * 4. The names The Jakarta Project, WebApp, and Apache Software * *Foundation must not be used to endorse or promote products derived * *from this software without prior written permission. For written * *permission, please contact [EMAIL PROTECTED].* * * * 5. Products derived from this software may not be called Apache nor may * *Apache appear in their names without prior written permission of the * *Apache Software Foundation.* * * * THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES * * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY * * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL * * THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY * * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN * * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * * POSSIBILITY OF SUCH DAMAGE. * * * * = * *
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
That still doesn't change the fact that whatever is in JK for versioning is utterly complicated, is completely different from what the Apache folks have done so far (look at both 1.3 and 2.0 trees), and I don't want to look up at a manual on how to interpret the va_version.h header every time I have to roll a release, right? Punky, your ORIGINAL file from December last year looked _MUCH_ better Yes, I know, but it's shame that you were *so* inactive at that time. ;-) I'm still -1 on the version currently in CVS. This is how I would like to see things at the end, exactly like Apache 1.3 and 2.0 are doing... +1 for httpd way. My idea of -DWEBAPP_VERSION=. is wrong because it's impossible to gather that piece of information under Windows when building with Visual Studio (stupid operating system)... You said that you don't support M$ platform, you changed your mind? ;-) Pier Punky -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Pier Fumagalli wrote: Punky Tse [EMAIL PROTECTED] wrote: GOMEZ Henri wrote: Punky, I appreciate your effort, but IMO, wa_version.h is way too utterly complicated. I'd add -DWEBAPP_VERSION=x to CFLAGS from the autoconf magicness, and go from there... Hum, I just commited wa_version.h and it's really similar to what Jean-Frederic proposed and commited to mod_jk. And it's what httpd 2.0 (ap_release.h) use I tell you why: http://marc.theaimsgroup.com/?l=tomcat-devm=100878406017530w=2 That still doesn't change the fact that whatever is in JK for versioning is utterly complicated, is completely different from what the Apache folks have done so far (look at both 1.3 and 2.0 trees), and I don't want to look up at a manual on how to interpret the va_version.h header every time I have to roll a release, right? This version handling is like the Linux Kernel version... (but there it is in the first lines of the main Makefile). The idea behind the complexity is that we could decide version of protocol based on the version containted in version.h file. Punky, your ORIGINAL file from December last year looked _MUCH_ better I'm still -1 on the version currently in CVS. This is how I would like to see things at the end, exactly like Apache 1.3 and 2.0 are doing... In this case we should both mod_webapp and mod_jk/mod_jk2 version. My idea of -DWEBAPP_VERSION=. is wrong because it's impossible to gather that piece of information under Windows when building with Visual Studio (stupid operating system)... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
jean-frederic clere [EMAIL PROTECTED] wrote: That still doesn't change the fact that whatever is in JK for versioning is utterly complicated, is completely different from what the Apache folks have done so far (look at both 1.3 and 2.0 trees), and I don't want to look up at a manual on how to interpret the va_version.h header every time I have to roll a release, right? This version handling is like the Linux Kernel version... (but there it is in the first lines of the main Makefile). That's not the best example of code beauty... The idea behind the complexity is that we could decide version of protocol based on the version containted in version.h file. Get real, we have ONE protocol. Punky, your ORIGINAL file from December last year looked _MUCH_ better I'm still -1 on the version currently in CVS. This is how I would like to see things at the end, exactly like Apache 1.3 and 2.0 are doing... In this case we should both mod_webapp and mod_jk/mod_jk2 version. I'm not -1ing anything on JK... That code might NEED that complicateness, and frankly I could care less.. I'm absolutely -1 on that where it concerns me, namedly, mod_webapp... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Punky Tse [EMAIL PROTECTED] wrote: That still doesn't change the fact that whatever is in JK for versioning is utterly complicated, is completely different from what the Apache folks have done so far (look at both 1.3 and 2.0 trees), and I don't want to look up at a manual on how to interpret the va_version.h header every time I have to roll a release, right? Punky, your ORIGINAL file from December last year looked _MUCH_ better Yes, I know, but it's shame that you were *so* inactive at that time. ;-) My priorities are kinda right... Get laid off by Sun in november, go on a long vacation in December (basically trying to get all my stuff toghether), find a new job in January, and start working on February... Sorry... I'm still -1 on the version currently in CVS. This is how I would like to see things at the end, exactly like Apache 1.3 and 2.0 are doing... +1 for httpd way. Good My idea of -DWEBAPP_VERSION=. is wrong because it's impossible to gather that piece of information under Windows when building with Visual Studio (stupid operating system)... You said that you don't support M$ platform, you changed your mind? ;-) No, I didn't, but I'm sure that my inbox will start to be polluted by questions like how do I do that? WA_VERSION is not defined... Just to keep spam low, and if someone wants to port it, well, I'm not here to prevent them... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Pier Fumagalli wrote: jean-frederic clere [EMAIL PROTECTED] wrote: That still doesn't change the fact that whatever is in JK for versioning is utterly complicated, is completely different from what the Apache folks have done so far (look at both 1.3 and 2.0 trees), and I don't want to look up at a manual on how to interpret the va_version.h header every time I have to roll a release, right? This version handling is like the Linux Kernel version... (but there it is in the first lines of the main Makefile). That's not the best example of code beauty... May be not. But a Kernel needs more complexity than a TC connector. The idea behind the complexity is that we could decide version of protocol based on the version containted in version.h file. Get real, we have ONE protocol. And it is possible to add a #define PROTOCOL_NUMBER n where n increases when we change the protocol. (More easy than testing a version). Punky, your ORIGINAL file from December last year looked _MUCH_ better I'm still -1 on the version currently in CVS. This is how I would like to see things at the end, exactly like Apache 1.3 and 2.0 are doing... In this case we should both mod_webapp and mod_jk/mod_jk2 version. I'm not -1ing anything on JK... That code might NEED that complicateness, and frankly I could care less.. I'm absolutely -1 on that where it concerns me, namedly, mod_webapp... Ok... Please commit your changes. We could add the complexity when needed. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
jean-frederic clere [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: That's not the best example of code beauty... May be not. But a Kernel needs more complexity than a TC connector. Correct... The idea behind the complexity is that we could decide version of protocol based on the version containted in version.h file. Get real, we have ONE protocol. And it is possible to add a #define PROTOCOL_NUMBER n where n increases when we change the protocol. (More easy than testing a version). Take a look at pr_warp_defs.h when that gets generated... Punky, your ORIGINAL file from December last year looked _MUCH_ better I'm still -1 on the version currently in CVS. This is how I would like to see things at the end, exactly like Apache 1.3 and 2.0 are doing... In this case we should both mod_webapp and mod_jk/mod_jk2 version. I'm not -1ing anything on JK... That code might NEED that complicateness, and frankly I could care less.. I'm absolutely -1 on that where it concerns me, namedly, mod_webapp... Ok... Please commit your changes. We could add the complexity when needed. We don't need complexity... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Ok... Please commit your changes. We could add the complexity when needed. We don't need complexity... And users need release. Even if if a release is imperfect. That's why there is release/patch in version ;] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
GOMEZ Henri [EMAIL PROTECTED] wrote: Ok... Please commit your changes. We could add the complexity when needed. We don't need complexity... And users need release. They do... Even if if a release is imperfect. Are you _CRAZY_? I'm going to -1 any release that is not clearly an interim test release (such as Tomcat 4.1.0, which is _supposed_ not to work, although it does) and which doesn't have all the Apache standards to _be_ a release... AKA, at least, it _has_ to build, right? Now webapp doesn't, not how it should anyway, so, -1 on tagging NOW. Plus, given the last changes, the documentation is outdated, that needs to be addressed. If 1.2.0 goes out, I want it to build, run and crash, but at least I don't want to see people writing me because I did what was written there and it doesn't work. Screw that... That's why there is release/patch in version ;] There is -dev and not -dev... And non -dev have to at least compile and come out in a decent state... I'm _not_ going to tag a release... And I'm going to -1 anyone who will propose to do that now, and then we count, ok? Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Are you _CRAZY_? I'm going to -1 any release that is not clearly an interim test release (such as Tomcat 4.1.0, which is _supposed_ not to work, although it does) and which doesn't have all the Apache standards to _be_ a release... Did there is still blocking (showstopper) bug in mod_webapp ? If so, delay the release. AKA, at least, it _has_ to build, right? Now webapp doesn't, not how it should anyway, so, -1 on tagging NOW. It was compiling 2 or 3 hours ago (I've grabbed an autoconf 2.53 in /usr/local ;(. Plus, given the last changes, the documentation is outdated, that needs to be addressed. If 1.2.0 goes out, I want it to build, run and crash, but at least I don't want to see people writing me because I did what was written there and it doesn't work. Screw that... What's that changes ? That's why there is release/patch in version ;] There is -dev and not -dev... And non -dev have to at least compile and come out in a decent state... I'm _not_ going to tag a release... And I'm going to -1 anyone who will propose to do that now, and then we count, ok? mod_webapp is your baby, do what you want with it. I'll delay the official release to generate linux binaries and rpms. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
GOMEZ Henri wrote: Are you _CRAZY_? I'm going to -1 any release that is not clearly an interim test release (such as Tomcat 4.1.0, which is _supposed_ not to work, although it does) and which doesn't have all the Apache standards to _be_ a release... Did there is still blocking (showstopper) bug in mod_webapp ? If so, delay the release. - Multi-thread Apsche are not working and may be even not compiling due to atomic support in APR.(atomic have to be change to mutex). - We have to run a watchdog test. - There are still 6 bugs to check. AKA, at least, it _has_ to build, right? Now webapp doesn't, not how it should anyway, so, -1 on tagging NOW. It was compiling 2 or 3 hours ago (I've grabbed an autoconf 2.53 in /usr/local ;(. Plus, given the last changes, the documentation is outdated, that needs to be addressed. If 1.2.0 goes out, I want it to build, run and crash, but at least I don't want to see people writing me because I did what was written there and it doesn't work. Screw that... What's that changes ? That's why there is release/patch in version ;] There is -dev and not -dev... And non -dev have to at least compile and come out in a decent state... I'm _not_ going to tag a release... And I'm going to -1 anyone who will propose to do that now, and then we count, ok? mod_webapp is your baby, do what you want with it. I'll delay the official release to generate linux binaries and rpms. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
mod_webapp is your baby, do what you want with it. I'll delay the official release to generate linux binaries and rpms. tipo ^ I'll wait the official release to generate linux binaries and rpms -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Pier Fumagalli [EMAIL PROTECTED] wrote: GOMEZ Henri [EMAIL PROTECTED] wrote: It build on my Redhat 6.2 box but failed at http2 start : Invalid virtual host name ?[ Put ServerName befor WebApp... Will have to fix that one BTW, this at least tells me that it works FWIW, the only things I changed were build stuff, and so, once you load the DSO, you're set... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
GOMEZ Henri [EMAIL PROTECTED] wrote: May I suggest you drop the latest tarball, with the configure included :) in jtc/webapp ? Or I could do it for you and prepare the layout but need something like a version number/release : 1.0.3b1, 1.0.2 Version??? Doh... Someone calls it 1.1, someone 0.9, someone 1.0... I'd say we call it 1.2.0 (which I've never seen around) and start back from scratch from there... I'll put up the tarball... Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
GOMEZ Henri [EMAIL PROTECTED] wrote: Ok, so you have to add VirtualHost * around webapp config. No... I remember an old mail where Pier told something about adding support to DefaultHost but it's quite sometimes ago You just have to put ServerName outside of ANY virtual host... Ok, I added : ServerName hgo1.slib.com:8092 and it works fine. BTW, it need to have A FULL HOST:PORT What about reporting webapp version at init time, [Thu May 02 21:44:38 2002] [notice] Apache/2.0.35 (Unix) mod_ssl/2.0.35OpenSSL/0.9.6 DAV/2 mod_jk/1.2.0 configured -- resuming normal operations could be [Thu May 02 21:44:38 2002] [notice] Apache/2.0.35 (Unix) mod_ssl/2.0.35OpenSSL/0.9.6 DAV/2 mod_jk/1.2.0 mod_webapp 1.2.0 configured -- resuming normal operations Nota that mod_jk / mod_webapp coexist very well ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
GOMEZ Henri [EMAIL PROTECTED] wrote: Ok, I added : ServerName hgo1.slib.com:8092 and it works fine. BTW, it need to have A FULL HOST:PORT Correct... On Apache 2.0 yes because there's no Port directive. But since that thing is beating the crap out of me, I'll just change the whole lot... The only thing is that I might have to do some changes on the configuration directives... :( What about reporting webapp version at init time, [Thu May 02 21:44:38 2002] [notice] Apache/2.0.35 (Unix) mod_ssl/2.0.35OpenSSL/0.9.6 DAV/2 mod_jk/1.2.0 configured -- resuming normal operations could be [Thu May 02 21:44:38 2002] [notice] Apache/2.0.35 (Unix) mod_ssl/2.0.35OpenSSL/0.9.6 DAV/2 mod_jk/1.2.0 mod_webapp 1.2.0 configured -- resuming normal operations Hm. Might do that as well... Nota that mod_jk / mod_webapp coexist very well ;) Why shouldn't they? For sure I'm not going to set JK's pointers to NULL just to make it segfault :) Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
[Thu May 02 21:44:38 2002] [notice] Apache/2.0.35 (Unix) mod_ssl/2.0.35OpenSSL/0.9.6 DAV/2 mod_jk/1.2.0 mod_webapp 1.2.0 configured -- resuming normal operations Hm. Might do that as well... I could add that if you want ;) Just to show to Jon that I could also commit in webapp ;) Nota that mod_jk / mod_webapp coexist very well ;) Why shouldn't they? For sure I'm not going to set JK's pointers to NULL just to make it segfault :) Never think about it ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
GOMEZ Henri [EMAIL PROTECTED] wrote: Hm. Might do that as well... I could add that if you want ;) Just to show to Jon that I could also commit in webapp ;) If you want... Nota that mod_jk / mod_webapp coexist very well ;) Why shouldn't they? For sure I'm not going to set JK's pointers to NULL just to make it segfault :) Never think about it ? Yeah, but then I'd have to dig into JK's sources and I wouldn't tell to do that not even to my worst enemy... :) Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvscommit:jakarta-tomcat-connectors/webapp/supportbuildconf.sh
Henri,
What about reporting webapp version at init time,
[Thu May 02 21:44:38 2002] [notice] Apache/2.0.35 (Unix) mod_ssl/2.0.35OpenSSL/0.9.6
DAV/2 mod_jk/1.2.0 configured -- resuming normal operations
could be
[Thu May 02 21:44:38 2002] [notice] Apache/2.0.35 (Unix) mod_ssl/2.0.35OpenSSL/0.9.6
DAV/2 mod_jk/1.2.0 mod_webapp 1.2.0 configured -- resuming normal operations
Nota that mod_jk / mod_webapp coexist very well ;)
try:
=
$ telnet punknix.homeip.net 80
Trying 61.18.154.226...
Connected to punknix.homeip.net.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Fri, 03 May 2002 01:32:34 GMT
Server: Apache/2.0.37-dev (Unix) mod_webapp/1.0.2
Content-Location: index.html.en
Vary: negotiate,accept,accept-language,accept-charset
TCN: choice
Last-Modified: Wed, 01 May 2002 14:43:53 GMT
ETag: 2a78e-5b0-c72f5c40;2a7a7-94f-c73e9e80
Accept-Ranges: bytes
Content-Length: 1456
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Content-Language: en
Expires: Fri, 03 May 2002 01:32:34 GMT
Connection closed by foreign host.
=
I had been make this patch for a very long time (3/4/5 months). And
send to this list several times... If you like, just grap my patch and
comit.
(wa_version.h must be placed in include/ dir, and change to *whatever*
version you like!)
Punky
P.S. May be next time, I send the patch to bugzilla in order to draw
more attention.
Index: mod_webapp.c
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c,v
retrieving revision 1.31
diff -u -r1.31 mod_webapp.c
--- mod_webapp.c17 Jan 2002 17:02:13 - 1.31
+++ mod_webapp.c30 Jan 2002 17:47:45 -
@@ -68,6 +68,7 @@
#include http_protocol.h
#include util_script.h
#include wa.h
+#include wa_version.h
/* * */
/* GENERIC DECLARATIONS */
@@ -523,6 +524,11 @@
return(OK);
}
+static void wam_init_handler(server_rec *s, ap_pool *p)
+{
+ap_add_version_component(WA_EXPOSED_VERSION);
+}
+
/* List of all available Apache handlers */
static const handler_rec wam_handlers[] = {
{webapp-handler, wam_invoke},
@@ -532,7 +538,7 @@
/* Apache module declaration */
module MODULE_VAR_EXPORT webapp_module = {
STANDARD_MODULE_STUFF,
-NULL, /* module initializer */
+wam_init_handler, /* module initializer */
NULL, /* per-directory config creator */
NULL, /* dir config merger */
NULL, /* server config creator */
Index: mod_webapp.c
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c,v
retrieving revision 1.7
diff -u -r1.7 mod_webapp.c
--- mod_webapp.c17 Jan 2002 17:02:13 - 1.7
+++ mod_webapp.c30 Jan 2002 17:47:15 -
@@ -69,6 +69,7 @@
#include http_protocol.h
#include util_script.h
#include wa.h
+#include wa_version.h
#include apr_tables.h
/* * */
@@ -520,12 +521,20 @@
return DECLINED;
}
+static int wam_init_handler(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp,
+ server_rec *s)
+{
+ap_add_version_component(p, WA_EXPOSED_VERSION);
+return OK;
+}
+
static void register_hooks(apr_pool_t *p)
{
ap_hook_handler(wam_invoke, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_translate_name(wam_match, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_child_init(wam_startup, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_map_to_storage(wam_map_to_storage, NULL, NULL, APR_HOOK_MIDDLE);
+ap_hook_post_config(wam_init_handler, NULL, NULL, APR_HOOK_MIDDLE);
}
/* Apache module declaration */
/* = *
* *
* The Apache Software License, Version 1.1 *
* *
* Copyright (c) 1999-2001 The Apache Software Foundation. *
* All rights reserved.*
* *
* = *
* *
* Redistribution and use in source and binary forms, with or without modi- *
* fication, are permitted provided
