Those seem like good modifications to me. Cheers,
Nick -----Original Message----- From: Vincent Massol [mailto:[EMAIL PROTECTED]] Sent: Monday, October 08, 2001 1:09 PM To: [EMAIL PROTECTED] Subject: Re: Sending data to a servlet ----- Original Message ----- From: "Kevin Jones" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 08, 2001 6:41 PM Subject: RE: Sending data to a servlet > Thanks for the reply > > > Question: can we put parameters in the URL when sending data > > using the POST > > method ? In that case, we could maybe use the getQueryString() > > method (if it > > doesn't call getInputStream()) ? > > With Tomcat you can definitely pass a query string when using POST, don't > know about other servers but without checking the HTTP spec I would think > they work also. I also don't see any reason for the server to call > getInputStream in this case as the query string is passed as part of the > URL. > > Reading the HTTP RFC, I can see nowhere in the spec that POST handlers > should ignore the query string. > I checked with the Tomcat guys and it is valid to use HTTP params in the URL when POSTing data. > I think parsing the query string is the only realistic solution (without > looking at the code). If I pass data as a serialized object, the redirector > has to use get[InputStream|Reader] to get the data, this will interfere with > my servlet calling getParameter. If the re-director calls getParameter this > will interfere with my servlet calling get[InputStream|Reader]. > You're right. Let's do it in the URL. I'll modify Cactus to behave this way first ... > If this works then would the idea be to add support for add beginXXX methods > that take a WebRequest object that we could 'write' the input data to? ... then I propose to modify WebRequest : * add a addParameter(String name, String value, String method) method where method = {"POST" | "GET"} * modify the behaviour of the existing addParameter(String name, String value) so that it defaults to addParameter(String name, String value, "GET") * add a setData(InputStream bodyData) method to pass data to write in the HTTP request body. If setData() is used, then all added POST parameters will be ignored * force the method to POST if any POST parameters have been added * add a setContentType(String contentType) method. Content type is "application/x-www-form-urlencoded" by default. Question: is this needed ? I have not looked at multi-part MIME yet. What do you think ? Thanks > > Kevin Jones > Developmentor > www.develop.com > -Vincent > > -----Original Message----- > > From: Vincent Massol [mailto:[EMAIL PROTECTED]] > > Sent: 08 October 2001 17:26 > > To: [EMAIL PROTECTED] > > Subject: Re: Sending data to a servlet > > > > > > Hi Kevin, > > > > ----- Original Message ----- > > From: "Kevin Jones" <[EMAIL PROTECTED]> > > To: "Cactus-User" <[EMAIL PROTECTED]> > > Sent: Monday, October 08, 2001 3:49 PM > > Subject: Sending data to a servlet > > > > > > > I want to send data to a servlet that the servlet retrieves using > > > req.getReader. I know that Cactus doesn't support this directly (and I > > know > > > there's an open todo :-) ), > > > > hehe ... :) > > > > I've tried to write a unit test for Cactus that would use getReader() as I > > didn't see why it would not work ... and it doesn't work ... ! My test is > > very simple: > > > > public void beginGetReader(WebRequest theRequest) > > { > > theRequest.addParameter("test", "some body data"); > > } > > > > public void testGetReader() throws Exception > > { > > String buffer; > > StringBuffer body = new StringBuffer(); > > BufferedReader reader = request.getReader(); > > while ((buffer = reader.readLine()) != null) { > > body.append(buffer); > > } > > assertEquals("test=some body data", body.toString()); > > } > > > > By default, Cactus sends the parameters using the POST method so > > getReader() > > should get the parameter. Ok, I know, if you need to send some raw data > > (without the 'xxx = yyy' format) then it wouldn't work but it > > would be easy > > to add a new method for that. > > > > However, the above test fails and body.toString() is empty. Why ? > > I believe > > it is because, internally, Cactus sends other internal parameters in the > > http request (such as the name of the test class, the method to call, ...) > > and these parameters are extracted by the servlet redirector (using > > request.getParameter()) _before_ the testGetReader() is called ... and > > Servlet API doc says that for a given request, getParameter() > > [which must be > > using getInputStream() internally] or getReader() can be called > > but not both > > ... [for some reason, using Resin, it does not raise an exception, but > > returns ""]. > > > > ..... > > > > This is a major issue as we absolutely need to pass (transparently) some > > context data to the servlet redirector. If we want to be able to support > > getReader() [and we do want that !], we need to find another way > > of passing > > our internal data .... A solution might be to continue to pass them in the > > body and extract them by hand [not using getParameter()] by calling > > getReader() [but we will need to be careful not to read on the > > data for the > > test part - we could also use a serialized java object]. This means there > > will be 2 cases: tests that uses getInputStream() and tests that uses > > getReader() ... > > > > Question: can we put parameters in the URL when sending data > > using the POST > > method ? In that case, we could maybe use the getQueryString() > > method (if it > > doesn't call getInputStream()) ? > > > > To summarize: > > * adding support for sending data to servlets is easy if the code > > under test > > is using getInputStream() to get that data > > * adding support for sending data to servlets is difficult if the > > code under > > test is using getReader() to get that data > > > > > so can I do this 'outside' the scope of Cactus > > > and still have the tests executed. I.e. can I use an > > HttpUrlConnection (or > > > similar) to talk to the re-direction proxy within my testXXX methods? > > > > hum ... > > * the interface between the Cactus client and the Cactus server > > parts is not > > public, meaning it may change in the future (as demonstrated for > > example by > > the above analysis which will probably lead to a change), > > * it would not even work for the reason explained above (getParameter() is > > called before your getReader() code). > > > > The only solution is to help us on Cactus correct this bug/limitation you > > have found ... ! ;-) > > > > Thanks for that ! > > > > > > > > Kevin Jones > > > Developmentor > > > www.develop.com > > > > > > > -Vincent > > > > -- > > Vincent Massol, [EMAIL PROTECTED] > > OCTO Technology, www.octo.com > > Information System Architecture Consulting > > > >
