On Tuesday 09 April 2002 10:47, Mark Cance wrote: > Hi, > > I'm developing a Taglib and its becoming a real pain to restart Apache > every time I make a change. > > I've built Apache with the mod_so module and know its possible to achieve > the effect using shared objects. However everything I managed to find so > far relates to building C modules, I'm loathed to make changes to my taglib > that may break everything.
I'm not sure how the way you built apache is relevant to this. While apache with DSO support does allow you to pick and choose what C modules to load at server startup time, it doesn't have anything to do with reloading code in a running server. There isn't any way to reload C code in a running server, if a shared object changes, the server has to be reloaded (and in some OSes you cannot even copy over a .so file if its currently loaded). You CAN try setting up mod_perl so that it will reload modules, but I don't think that really helps you with TagLibs because they get loaded via AxKit directives. I never did find a way to reliably reload them except to restart the server. You will also find that it is a lot easier to debug mod_perl type code if you run a copy of Apache with the -X flag. This creates a single Apache process that never forks, and then you can attach to it with a debugger (there are some excellent articles about using perl debuggers with Apache mod_perl code on the Apache site). I'd particularly recommend the ptkdb debugger which is at CPAN as Devel::ptkdb package. There are instructions on the author's site about using it with mod_perl, and it works pretty darn good! Generally the best strategy though is to build a set of test harnesses for your code. You can load a taglib in a test script without any problem and just call its various functions. That will eliminate 95% of all bugs. I've found over the years that the best way to build good solid commercial grade code is to write all the test cases FIRST, then write the code. The rule in our shop is that all code passes all tests before being commited, and developers commit their code on a daily basis. It helps prevent big problems from showing up. > > Anyone got any ideas? (Sorry if this is slightly OT but I reckoned someone > in this group might be able to help). I can send you (or anyone interested) Apache config files and some scripts that we use here to set up various server environments. Generally we have one dev server but each developer has a seperate mod_perl apache of their own to do debugging on. Then we put a front-end proxy on port 80, so for instance http://tharter.btv.aptusventures.com/login.xsp maps via proxy and a rewrite rule to http://blackbox.btv.aptusventures.com:8201/login.xsp which is my own private server which handles only xsp and xml. Everything else gets handled by a virtual host on port 80 which is a stripped Apache for speed. That also means that my log files don't get filled with garbage related to static content or other people's work, making debugging even easier. > > Cheers, > Mark. > > > --------------------------------------------------------------------- > 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]
