[GUMP@brutus]: cocoon-2.1/cocoon failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 55 projects. Project State : 'Failed', Reason 'Build Failed' The following are affected: - cocoon : Java XML Framework - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-linotype : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-php : Java XML Framework - cocoon-block-poi : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-fw : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slide : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-webdav : Java XML Framework - cocoon-block-woody : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - cocoon-lenya : Content Management System - xml-forrest : Forrest is an XML standards-oriented project documentation f... Full details are available at: http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Jar [cocoon.jar] identifier set to jar basename: [cocoon] -DEBUG- Jar [cocoon-tests.jar] identifier set to jar basename: [cocoon-tests] -DEBUG- Jar [cocoon-deprecated.jar] identifier set to jar basename: [cocoon-deprecated] -DEBUG- Dependency on avalon-framework exists, no need to add for property avalonapi.jar. -INFO- Made directory [/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040726/test] -INFO- Enable verbose output, due to 1 previous error(s). -INFO- Failed with reason build failed -INFO- Enable debug output, due to build failure. -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040726/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040726/test/output] The following work was performed: http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/gump_work/build_cocoon-2.1_cocoon.html Work Name: build_cocoon-2.1_cocoon (Type: Build) State: Failed Elapsed: 12 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Davalonapi.jar=/usr/local/gump/public/workspace/avalon/framework/api/target/avalon-framework-api-20040726.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-logkit/target/avalon-logkit-20040726.jar -Dversion=20040726 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon
Re: Request headers
hi, what about using this kind of snippet? map:select type=header map:parameter name=header-name value=accept/ map:when test=application/xhtml+xml ... /map:when map:otherwise ... /map:otherwise /map:select you may want to read the wiki, too, see http://wiki.apache.org/cocoon/HeaderSelector regards bernhard (switching to the developers list) Ralph == Ralph Goers [EMAIL PROTECTED] writes: Ralph What about the HeaderSelector? Yes. I couldn't find it at first, as it is not listed in the navigation pane of the selectors page of the user manual. But it appears not to be exactly what I want. Looking at the source code, it implements Selector. But I want to be able to select whether or not the Accept header contains the string application/xhtml+xml (so as to be able to do some limited content negotiation). So I think I need a version of header selector that implements NamedPatternsSelector, or AbstractRegexpSelector. I think I could easily implement such a selector. I could call it ContentTypeSelector, specifically matching on the Accept header, but perhaps something more general might be useful. What do people think? -- Colin Paul Adams Preston Lancashire -- 250 MB Mailbox, 100 FreeSMS/Monat, 1000 MB Online-Festplatte Jetzt GMX TopMail kostenlos testen http://www.gmx.net/de/go/topmail
Re: Request headers
Bernhard == bernhard huber [EMAIL PROTECTED] writes: Bernhard hi, what about using this kind of snippet? Bernhard map:select type=header map:parameter Bernhard name=header-name value=accept/ map:when Bernhard test=application/xhtml+xml ... /map:when Bernhard map:otherwise ... /map:otherwise /map:select I don't think so. Bernhard you may want to read the wiki, too, see Bernhard http://wiki.apache.org/cocoon/HeaderSelector I read it. And it says you can only match on the value of the header, whereas I want to check if the header contains the string or not. I think I'll write a RegexpHeaderSelector. -- Colin Paul Adams Preston Lancashire
Re: Request headers
Colin == Colin Paul Adams [EMAIL PROTECTED] writes: Colin I think I'll write a RegexpHeaderSelector. I've done this, and it works to the limit of my testing - namely one example: map:selector name=content-type src=org.apache.cocoon.selection.RegexpHeaderSelector pattern name=xhtml^.*application/xhtml\+xml.*$/pattern header-nameaccept/header-name /map:selector map:match pattern=test map:select type=content-type map:when test=xhtml map:read src=test.xhtml mime-type=application/xhtml+xml/ /map:when map:otherwise map:read src=test.html mime-type=text/html/ /map:otherwise /map:select /map:match Mozilla and Opera display test.xhtml whereas Lynx and Konqueror display test.html. I don't have MSIE, but I've asked a friend to test it, and I have no doubt it will display test.html. This I think is useful. How can I contribute it to Cocoon (I've only written the java class - I don't know where I should add documentation). -- Colin Paul Adams Preston Lancashire
Re: Request headers
Colin Paul Adams wrote: pattern name=xhtml^.*application/xhtml\+xml.*$/pattern Wouldn't pattern name=xhtmlapplication/xhtml\+xml/pattern have the same effect? I think it should. This I think is useful. How can I contribute it to Cocoon (I've only written the java class - I don't know where I should add documentation). Open an issue on Bugzilla and attach the sources. For the docs, provide something similar to the files in src/documentation/xdocs/userdocs/selectors. It would be nice if you could provide unit tests for the selector, too :-). Ugo
Re: Request headers
Ugo == Ugo Cei [EMAIL PROTECTED] writes: Ugo Colin Paul Adams wrote: pattern name=xhtml^.*application/xhtml\+xml.*$/pattern Ugo Wouldn't Ugopattern name=xhtmlapplication/xhtml\+xml/pattern Ugo have the same effect? I think it should. Yes - it does. This I think is useful. How can I contribute it to Cocoon (I've only written the java class - I don't know where I should add documentation). Ugo Open an issue on Bugzilla and attach the sources. For the Ugo docs, provide something similar to the files in Ugo src/documentation/xdocs/userdocs/selectors. OK. Ugo It would be nice if you could provide unit tests for the Ugo selector, too :-). Well, you'll have to tell me what this involves. -- Colin Paul Adams Preston Lancashire
DO NOT REPLY [Bug 24402] - [PATCH] XML posting from SourceWritingTransformer by using an enhanced HTTPClientSource
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24402. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24402 [PATCH] XML posting from SourceWritingTransformer by using an enhanced HTTPClientSource --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 12:41 --- Created an attachment (id=12218) Updated patch for the SourceWritingTransformer
DO NOT REPLY [Bug 24402] - [PATCH] XML posting from SourceWritingTransformer by using an enhanced HTTPClientSource
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24402. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24402 [PATCH] XML posting from SourceWritingTransformer by using an enhanced HTTPClientSource --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 12:42 --- Created an attachment (id=12219) Updated patch for the HttpclientSource
Re: Request headers
Colin Paul Adams wrote: Ugo It would be nice if you could provide unit tests for the Ugo selector, too :-). Well, you'll have to tell me what this involves. Take inspiration from src/test/org/apache/cocoon/selection/HeaderSelectorTestCase.java for instance. Ugo
DO NOT REPLY [Bug 30321] New: - Added RegexpHeaderSelector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30321. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30321 Added RegexpHeaderSelector Summary: Added RegexpHeaderSelector Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have created a selector for matching the request headers using a regular expression. My motivation being to do some simple content negotiation - I wish to serve up XHTML 1.1 pages where the browser indicates it accepts application/xhtml+xml, and HTML pages otherwise. But I think this has many more uses, including automatic i18n, according to the accept-language header. I have written documentation, linked into the user manual (but I note that the selectors book needs updating generally). I have put some question markls on the page concerned, as I am not too sure of a couple of things. Please review it. Unit test to follow later.
DO NOT REPLY [Bug 30321] - Added RegexpHeaderSelector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30321. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30321 Added RegexpHeaderSelector --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 13:54 --- Created an attachment (id=12220) Java source code for RegexpHeaderSelector
Re: Request headers
Ugo Colin Paul Adams wrote: pattern name=xhtml^.*application/xhtml\+xml.*$/pattern Ugo Wouldn't Ugo pattern name=xhtmlapplication/xhtml\+xml/pattern Ugo have the same effect? I think it should. Yes - it does. I was checking the header accept sent by mozilla, it says: accept = text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 thus checking if application/xml is available you need some sort of RE, that's the reason for using plain HeaderSelector is a bit tedious. for the documentation, and testcase templete you will probably need CVS access. documentation template : src/documentation/xdocs/userdocs/selectors/header-selector.xml, or src/documentation/xdocs/userdocs/selectors/selector.template. testcase template : src/test/org/apache/cocoon/selection/HeaderSelectorTestCase.java, src/test/org/apache/cocoon/selection/HeaderSelectorTestCase.xtest, Copy HeaderSelectorTestCase.java to RegexpHeaderSelectorTestCase.java, dito for RegexpHeaderSelectorTestCase.xtest. Adopt RegexpHeaderSelectorTestCase.xtest replacing all HeaderSelector occurences by RegexpHeaderSelector Adopt RegexpHeaderSelectorTestCase.java to your header testings Add both docu + testcase to the bugzilla regards bernhard -- 250 MB Mailbox, 100 FreeSMS/Monat, 1000 MB Online-Festplatte Jetzt GMX TopMail kostenlos testen http://www.gmx.net/de/go/topmail
DO NOT REPLY [Bug 30321] - Added RegexpHeaderSelector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30321. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30321 Added RegexpHeaderSelector --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 13:55 --- Created an attachment (id=12221) Documentation for RegexpHeaderSelector
DO NOT REPLY [Bug 30321] - Added RegexpHeaderSelector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30321. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30321 Added RegexpHeaderSelector --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 13:57 --- Created an attachment (id=1) Patch against selectors.xml to include RegexpHeaderSelector in the list of selectors
DO NOT REPLY [Bug 30321] - Added RegexpHeaderSelector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30321. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30321 Added RegexpHeaderSelector --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 13:58 --- Created an attachment (id=12223) Patch to book.xml to include RegexpHeaderSelector in the ToC
Re: Calling web services from Cocoon
Hi Morley, I answer at Cocoon-dev as others might be interested. AFAIK there are no current prefered method for calling web-services. I and my colleagues, use the extended SourceWritingTransformer (SWT) and org.apache.excalibur.source.impl.HTTPClientSource that you can find in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24402, (I updated it with new patches for the SWT and HTTPClientSource, you still need some stuff from the earlier patch, though). It should be possible to use with HTTPS if you connect https to o.a.e.source.impl.HTTPClientSourceFactory in cocoon.xconf, but I have not tested it. In some applications we have used the HTTPClientSource from flowscript code instead of calling it from the SWT, it requires some more work but gives better control of error handling (and also memory consumption for very large soap requests). My idea with extending the HTTPClientSource with SOAP (post) functionallity was to gather all uses of the o.a.jakarta.commons.HTTPClient in one component. Now similar things are done in various SOAP and Web-proxy components. From a technical POV I still think it is a good idea. There where however a number of other problems that have done that I not have put the code in the Cocoon CVS yet: I never succeeded in updating the avalon CVS, Excalibur have sometimes been quite hard to compile, there where talk about deprecating the Excalibur components, there where severe community problems in Avalon, it have been moved from Ant to Maven and from CVS to Subversion. Now, Excalibur has left Avalon and started a new top level project that seem to be healthy, so I'll try to integrate the extended SWT and HTTPClientSource as soon as I find some time for it ;) I spent some time today trying to test the code with the samples that I submitted in the bugzilla entry, but the web services that I call from xmethods.net seemed to be down or at least very slow, anyone knowing about any other good webservice test sites, preferably with WSDL descriptions? /Daniel Morley Howell wrote: Daniel, I've been struggling for a few days to call a Web service from Cocoon 2.1.5, with little joy. I noticed various discussions on the wiki and the dev list about your source writing idea and some other options from Daniel Fagerstrom and Steve Punte. Do you know what the current preferred method is to call a Web service from Cocoon? Are any of them integrated into 2.1.5? Do any of them work over HTTPS (unlike the SOAP XSP logicsheet). Thanks for any help you can provide. Morley Howell
DO NOT REPLY [Bug 30321] - Added RegexpHeaderSelector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30321. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30321 Added RegexpHeaderSelector --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 16:39 --- Created an attachment (id=12224) Patch to documentation
Bugzilla not available
I can't reach issues.apache.org. -- Colin Paul Adams Preston Lancashire
Re: Request headers
bernhard == bernhard huber [EMAIL PROTECTED] writes: bernhard Copy HeaderSelectorTestCase.java to bernhard RegexpHeaderSelectorTestCase.java, dito for bernhard RegexpHeaderSelectorTestCase.xtest. Adopt bernhard RegexpHeaderSelectorTestCase.xtest replacing all bernhard HeaderSelector occurences by RegexpHeaderSelector Adopt bernhard RegexpHeaderSelectorTestCase.java to your header bernhard testings How do I run the test case? -- Colin Paul Adams Preston Lancashire
Re: Request headers
How do I run the test case? you have to options 1 - run build test runs all testcases, this shall run your test, too. You may want to adopt tools/targets/test-build.xml, target junit-tests decreasing the number of testcases 2 - your IDE allows to run a single the testcase, or single main-class Option 2 works fine using eclipse, or netbeans regards bernhard -- 250 MB Mailbox, 100 FreeSMS/Monat, 1000 MB Online-Festplatte Jetzt GMX TopMail kostenlos testen http://www.gmx.net/de/go/topmail
Re: Request headers
bernhard == bernhard huber [EMAIL PROTECTED] writes: How do I run the test case? bernhard you have to options bernhard 1 - run build test runs all testcases, this shall run bernhard your test, too. I'm getting there. But one thing I can't work - out - and that is where I define the selector for the test. I think it must be in a sitemap.xmap somewhere, but I can't find out where. -- Colin Paul Adams Preston Lancashire
Re: Request headers
How do I run the test case? bernhard you have to options bernhard 1 - run build test runs all testcases, this shall run bernhard your test, too. I'm getting there. But one thing I can't work - out - and that is where I define the selector for the test. I think it must be in a sitemap.xmap somewhere, but I can't find out where. Well, you define the selector for the test in xtest file. Your testcase extends SitemapComponentTestCase, and SitemapCompontentTestCase extends ExcaliburTestCase. ExcaliburTestCase will load the xtest file having the same basename as the testcase class. Thus you need RegexpHeaderSelector.xtest, for your RegexpHeaderSelectorTestCase.java In the xtest file you define: ... selectors logger=test component-instance class=org.apache.cocoon.selection.RegexpHeaderSelector name=regexpheader !-- configuration your selector i assume: define the name of the header attribute name -- header-nameaccept/header-name /component-instance /selectors ... The snippet is taken from HeaderSelectorTestCase.xtest. Now in your test case you can use regexpheader for getting the RegexpHeaderSelector. i hope this short explanation helps you. regards bernhard -- NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler! GMX DSL = supergünstig kabellos http://www.gmx.net/de/go/dsl
DO NOT REPLY [Bug 30326] New: - [Patch] - ScriptableConnection doesn't cleanup SQL Resources
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30326. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30326 [Patch] - ScriptableConnection doesn't cleanup SQL Resources Summary: [Patch] - ScriptableConnection doesn't cleanup SQL Resources Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: blocks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] ScriptableConnection doesn't explicitly close the PreparedStatement. This in turn doesn't free any resultssets from queries. As a result: the JDBC Pool grows with each query !
DO NOT REPLY [Bug 30326] - [Patch] - ScriptableConnection doesn't cleanup SQL Resources
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30326. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30326 [Patch] - ScriptableConnection doesn't cleanup SQL Resources --- Additional Comments From [EMAIL PROTECTED] 2004-07-26 17:20 --- Created an attachment (id=12225) Patch - closing the PreparedStatement
Re: Request headers
Il giorno 26/lug/04, alle 15:53, bernhard huber ha scritto: Ugo Colin Paul Adams wrote: pattern name=xhtml^.*application/xhtml\+xml.*$/pattern Ugo Wouldn't Ugo pattern name=xhtmlapplication/xhtml\+xml/pattern Ugo have the same effect? I think it should. Yes - it does. I was checking the header accept sent by mozilla, it says: accept = text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/ plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 thus checking if application/xml is available you need some sort of RE, that's the reason for using plain HeaderSelector is a bit tedious. Of course. But the regexp application/xhtml\+xml should match everything that ^.*application/xhtml\+xml.*$ matches, unless something is escaping me. The former is simpler and has the same effect. Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Request headers
Ugo == Ugo Cei [EMAIL PROTECTED] writes: Ugo Il giorno 26/lug/04, alle 15:53, bernhard huber ha scritto: Ugo Colin Paul Adams wrote: pattern name=xhtml^.*application/xhtml\+xml.*$/pattern Ugo Wouldn't pattern Ugo name=xhtmlapplication/xhtml\+xml/pattern have the same Ugo effect? I think it should. Yes - it does. I was checking the header accept sent by mozilla, it says: accept = text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/ plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 thus checking if application/xml is available you need some sort of RE, that's the reason for using plain HeaderSelector is a bit tedious. Ugo Of course. But the regexp application/xhtml\+xml should Ugo match everything that ^.*application/xhtml\+xml.*$ matches, Ugo unless something is escaping me. The former is simpler and Ugo has the same effect. The only reason the ^.* and .*$ were there, was I was having problems getting the thing to work, so I was playing around with various REs. Now, I'm just having problems with the test case, but I'll fathom it out sometime tomorrow. -- Colin Paul Adams Preston Lancashire
