On Friday, 19. September 2003 16:31, Kip Hampton wrote: > > I can easily back out the change in XPathScript, as it is the only module > > not working. The others work well even on several of my large sites using > > all sorts of file://, sql://, document_root relative and axkit:// URIs > > from within XSLT, XSP and XInclude. Thus I would like to leave the rest > > in place, as it is obviously working and at least one of our long-time > > users asked me when this feature is going in. > > "Works fine here" is nice, but it is not the criteria for checking > significant changes into the main branch. I'm sorry if you've been misled.
It is not a significant change. It doesn't change anything at all, from the application's point of view. Which is a lot less intrusive than many other changes we did. And I have checked that with three rather complex sites I maintain - sites which tend to break (and repeatedly did break) due to many other changes, be they because of libxslt, XML::LibXSLT, libxml, and several changes in AxKit semantics since 1.5.$something. These sites, which use lots of different URL inclusion mechanisms (all of them, except XPathScript based), worked flawlessly with the patched version. I consider this a good and sufficient real-world test. I apologoze for the problems with XPathScript - it would have been better to ask someone actually using that and/or better aquainted with it to do the modifications. > First, make sure that you have the latest Apache::Test from CPAN. Past > that, I'm not exactly sure which docs you're looking at, but the one > here [1] shows that you can pass the -httpd option with an appropriate > path to the t/TEST script to indicate the Apache binary you which to > test against. That is (in the root of the AxKit dist): > > perl t/TEST -httpd /path/to/your/apache These were the docs, my friend, the docs that never end... umm, I mean, that didn't include any help as to why it either picked up the wrong httpd (on a box where it didn't matter anyways, as 'the correct one' would have been apache2), created a broken config file the httpd couldn't grok, or the one most promising case when everything looked fine but the httpd silently didn't start. > A quick look at "perl t/TEST -help" yields many more options that might > help you along. Thanks for the tip, I will give it another try... though I really wonder why it is hidden? Even Apache::Test itself doesn't install, it doesn't ask for any paths at installation time, and the readme file is likewise unhelpful. All this even though all machines now use stock distro httpds (btw, a nice fact... these days this really works). > Assuming that this gives you a working test environment, I'm confident > that you'll not only fix the current XPS bug, but also include a series > of tests that exercise your changes for each module they effect; or, > barring those, that you will back you changes out as requested. The changes don't effect anything as long as you don't use the new API. That's by intention. But I will gladly add some problematic cases from the mentioned past experiences into the test, should I get Apache::Test running this time. I've given up on that several times before. The current XPS bug is already fixed by reverting the untested changes. > > Finally, is this list archived somewhere? I have been thrown off due to > > my mail disaster a few weeks ago and would like to catch up with mails. > > http://nagoya.apache.org/eyebrowse/SummarizeList?listId=50 Thanks. -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
