Re: HTTP POST with XML body
Le 13 nov. 05, à 20:40, Daniel Bößwetter a écrit : Bertrand Delacretaz wrote: ...Would it be possible for you to provide some HtmlUnit test cases along with your patch... Hm, I think I could do this, but I didn't find any htmlunit-test in the 2.1.x distribution nor in the SVN-trunk. The build target htmlunit-tests doesn't exist either. Could you please clarify which source tree I should be using or which patches I need to apply? Patches should always be created against the current SVN codebase. I was talking about the 2.1 branch which can be retrieved from http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/ with a Subversion client. HtmlUnit tests for blocks are found in http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/ blocks/batik/test/htmlunit/org/apache/cocoon/ , for example, and there are more under http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/test/ htmlunit/org/apache/cocoon/ -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: HTTP POST with XML body
Hi Bertrand, Bertrand Delacretaz wrote: I'm always picky about names so I'll make a few suggestions if you don't mind: with the goal of making sitemaps more self-explanatory I'd use the following parameter names: post-body, post-body-encoding, username, password, drop-request-parameters. Ok, good idea. I changed the names accordingly. ...I attached a diff against the 2.1.7 version of WebServiceProxyGenerator. I tested a couple of cases and it seems to solve at least my problems (for now)... Would it be possible for you to provide some HtmlUnit test cases along with your patch, to demonstrate your changes? Having this would help make this generator a "first-class citizen" (and you'd be a bit of a hero as that block doesn't have automated tests currently ;-) You can find example of such tests in Hm, I think I could do this, but I didn't find any htmlunit-test in the 2.1.x distribution nor in the SVN-trunk. The build target htmlunit-tests doesn't exist either. Could you please clarify which source tree I should be using or which patches I need to apply? Best regards, Daniel src/blocks/batik/test/htmlunit src/blocks/webdav/test/htmlunit src/blocks/xsltal/test/htmlunit src/test/htmlunit/ they are quite easy to write, you just need to create classes having names ending in ...TestCase and put their code under src/blocks/proxy/test/htmlunit To execute the tests use "./build.sh htmlunit-tests" and follow the instructions. Note that I just committed a fix as HtmlUnit tests from blocks were not executed, this should be ok now. -Bertrand
Re: HTTP POST with XML body
Daniel Boesswetter daniel-boesswetter.de> writes: > I'm sure this has been discussed before, but since I didn't find a > solution, I've built my own. My problem is, that I need to POST > XML-documents somewhere out of Cocoon and receive the resulting document > (e.g. for takling to an eXist database because there are currently known > bugs with their Cocoon integration and for integrating an XML-RPC based > ERP system on the other hand). Some time ago, I described a solution in http://wiki.apache.org/cocoon/StreamGenerator, which I have in fact used to talk to an eXist server. Unfortunately, a bug was introduced in Cocoon 2.1.6 (http://issues.apache.org/jira/browse/COCOON-1365), for which there is a patch, but this has not been applied to the Cocoon sources. (Actually, the bug was there before, but it showed because of a change in Xalan.) Recently, I added a comment (to Bugzilla, as Jira appeared to be broken from where I was working), asking one of the committers to apply the (very simple) patch. So here is again a request for one of the committers to please apply this patch. I have several Cocoon applications which depend on the correct handling of POST requests with parameters by cinclude, and I would appreciate if my "list of patches to apply to a new version of Cocoon" could become a bit shorter. Best regards, Nico Verwer
Re: HTTP POST with XML body
Hi Daniel, Le 11 nov. 05, à 20:54, Daniel Boesswetter a écrit : None of the Cocoon generators/transformers seemed to do the job (even CInclude has known bugs concerning POST), so I took the WebServiceProxyGenerator (which sounds like a good starting point :) and added the following parameters: Making this generator more powerful is certainly a good idea! Many thanks for sharing this here. - postbody - any valid Cocoon source URI. The resulting document is sent as the body of the POST request. - postbodyenc - the encoding used to serialize the postbody. UTF-8 by default. - username and password - used for basic authentication. - dropparams - if set to "true" the params from the present request are not passed to the target system (my ERP system was confused by params it didn't expect). I'm always picky about names so I'll make a few suggestions if you don't mind: with the goal of making sitemaps more self-explanatory I'd use the following parameter names: post-body, post-body-encoding, username, password, drop-request-parameters. ...I attached a diff against the 2.1.7 version of WebServiceProxyGenerator. I tested a couple of cases and it seems to solve at least my problems (for now)... Would it be possible for you to provide some HtmlUnit test cases along with your patch, to demonstrate your changes? Having this would help make this generator a "first-class citizen" (and you'd be a bit of a hero as that block doesn't have automated tests currently ;-) You can find example of such tests in src/blocks/batik/test/htmlunit src/blocks/webdav/test/htmlunit src/blocks/xsltal/test/htmlunit src/test/htmlunit/ they are quite easy to write, you just need to create classes having names ending in ...TestCase and put their code under src/blocks/proxy/test/htmlunit To execute the tests use "./build.sh htmlunit-tests" and follow the instructions. Note that I just committed a fix as HtmlUnit tests from blocks were not executed, this should be ok now. -Bertrand