You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Andre Juffer <an...@oulu.fi> on 2010/09/21 15:10:39 UTC
Cocoon 2.2 PUT HTTP request
Dear All,
in a previous thread, I was trying to understand why I could not see the
request parameters of a HTTP PUT request using the
cocoon.request.getParameter("...") family of methods in flowscript.
Conclusion: For a PUT request, according to specification, the servlet
engine is -not- required to parse the request for making the parameters
available through request.getParameter("..") and consequently also
cocoon.request.getParameter("...") will not return a value (just
'null'). [1]
One remedy is assume POST requests (client side) instead for the time
being, despite differences in the meaning of POST and PUT with regard to
RESTful applications.
There is still one other issue to be solved. In the case of a PUT
request (or any other HTTP request for that matter), my understanding is
that I should be able to identify the request HTTP method in flowscript
by cocoon.request.getMethod() or in a pipeline using <map:parameter
name="method" value="{request:method}" />. I find in either case that
this parameter's value is always GET, whatever the original request
method received by the servlet engine was. It seems that the original
request method value is simply lost somewhere, -before- the request is
being handled in the sitemap.
I now seek answers to the following:
1. Can one of you confirm (or not) that this is indeed the case. That
is, cocoon interferes with the original request and makes it a (or
creates a new) GET request. It is certain that the servlet engine
receives the PUT request in good order. It is also certain that the
servlet engine is not changing the original request. It simply passes it
on the cocoon-based webapp.
2. If item 1 above is in fact true (and I really hope this is not the
case), what would be solution to overcome this issue. I could image
making a filter that adds an extra parameter or attribute
'request-method' or something to the request that retains the original
HTTP method and query for its value in the sitemap or in flowscript. I
have to hope that cocoon retains this extra parameter or attribute when
it receives the request.
I would very much appreciate any response in this matter. I could not
find answers on the cocoon email lists or in the documentation,
unfortunately.
[1]
http://mail-archives.apache.org/mod_mbox/cocoon-users/201009.mbox/browser
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
On 09/21/2010 10:52 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andre,
>
> On 9/21/2010 3:15 PM, Andre Juffer wrote:
>> This provides an overview of the cocoon.request methods:
>>
>> http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1383_1_1.html
>
> Okay, this looks like a HttpServletRequest object with a few more
> methods (like get()). It's too bad the methods are poorly documented:
> for instance, get() says that it gets an object from either the
> attributes or parameters, but doesn't tell you what the rules are about
> when it chooses parameter or attribute.
>
> In either case, that parameter would almost certainly be a /request
> parameter/, not a parameter to the function itself.
>
>> However, on the cocoon 2.1 site, there is the following:
>>
>> http://cocoon.apache.org/2.1/userdocs/flow/sitemap.html
>
> That seems to indicate that the proper way to pass parameters from the
> sitemap to the flowscript function is like this:
>
> <map:match pattern="*">
> <map:call function="equipmentHandler">
> <map:parameter name="method" value="{request:method}" />
> </map:call>
> </map:match>
>
> and read them like this:
>
> function equipmentHandler()
> {
> var request = cocoon.request;
> var method = cocoon.parameters.method;
> ...
Actually I already tried this before. Did not work either. But please
read my next email I got it working!
>
>
> See if that works for you.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyZDQcACgkQ9CaO5/Lv0PB50wCggBRhrbi7JSoDEvsTj4YnHRXf
> CggAoJXr6TiRSQBznh131qQeqGJ91m4C
> =svV1
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andre,
On 9/21/2010 3:15 PM, Andre Juffer wrote:
> This provides an overview of the cocoon.request methods:
>
> http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1383_1_1.html
Okay, this looks like a HttpServletRequest object with a few more
methods (like get()). It's too bad the methods are poorly documented:
for instance, get() says that it gets an object from either the
attributes or parameters, but doesn't tell you what the rules are about
when it chooses parameter or attribute.
In either case, that parameter would almost certainly be a /request
parameter/, not a parameter to the function itself.
> However, on the cocoon 2.1 site, there is the following:
>
> http://cocoon.apache.org/2.1/userdocs/flow/sitemap.html
That seems to indicate that the proper way to pass parameters from the
sitemap to the flowscript function is like this:
<map:match pattern="*">
<map:call function="equipmentHandler">
<map:parameter name="method" value="{request:method}" />
</map:call>
</map:match>
and read them like this:
function equipmentHandler()
{
var request = cocoon.request;
var method = cocoon.parameters.method;
...
See if that works for you.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyZDQcACgkQ9CaO5/Lv0PB50wCggBRhrbi7JSoDEvsTj4YnHRXf
CggAoJXr6TiRSQBznh131qQeqGJ91m4C
=svV1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
On 09/21/2010 09:40 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andre,
>
> On 9/21/2010 2:04 PM, Andre Juffer wrote:
>> On 09/21/2010 07:38 PM, Christopher Schultz wrote:
>>> I find the Cocoon documentation very difficult to navigate. Can you
>>> point me to the documentation for calling javascript functions? All I
>>> could find was this:
>>> http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html
>>
>> Yeah, it is not that well organized. Have a look at:
>>
>> http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html
>
> In the examples, I see them use code like this:
>
> cocoon.request.get("foo")
>
> to get a request parameter. get() is not a standard method on
> HttpServletRequest, so this must be some kind of wrapper around
> HttpServletRequest.
This provides an overview of the cocoon.request methods:
http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1383_1_1.html
You will find there both cocoon.request.get(..) and
cocoon.request.getParameter(..). I've used for other applications I've
made in the past always the getParameter("") function. Never worried
about PUT requests.
Check out the links on the left as well.
>
> There seems to be nothing about working with<map:parameter> elements
> from the sitemap in the flowscript. :(
Yeah, you're right. I thought it was explained there. There is indeed
almost no information about <map:parameter> on the cocoon 2.2 site,
except for
http://cocoon.apache.org/2.2/core-modules/core/2.2/852_1_1.html
However, on the cocoon 2.1 site, there is the following:
http://cocoon.apache.org/2.1/userdocs/flow/sitemap.html
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyY/CgACgkQ9CaO5/Lv0PDbZgCfSd98cokDRntfHnLRMkDLduTz
> 0LAAoKlpGlBDntPj09UTTlyVID7OZkS+
> =JCr8
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
On 09/22/2010 06:44 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andre,
>
> On 9/22/2010 3:36 AM, Andre Juffer wrote:
>>> Try confirming (say, with LiveHttpHeaders) that the PUT is being
>>> redirected by the server.
>>
>> This is what I see with LiveHttpHeaders:
>>
>> http://localhost:8888/equipment/
>>
>> POST /equipment/ HTTP/1.1
>
> No, I meant try to PUT to http://localhost:8888/equipment (no trailing
> slash) and see if the server redirects you. Also, it would be nice to to
> know what kind of redirect is being issued. If a 303 response is being
> generated, then the client is supposed to use a GET method for the
> followup request. Other response codes have other meanings.
OK, sorry about that. Here is the output and I think you are right. It
actually generates 302 instead of of a 303 response, but the effect is
probably the same (according to Wikipedia). The second request is not
mine and is actually a GET request. Note that cocoon 2.2 is about two
years old and has not been updated since then. I hope cocoon 3 goes main
stream soon now.
http://localhost:8888/equipment
PUT /equipment HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.10)
Gecko/20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://localhost:8888/ui/start
Content-Length: 94
Cookie: JSESSIONID=hr0mt4clb1k4;
webfx-tree-cookie-persistence=wfxt-4+wfxt-6;
PPA_ID=9qtajhe4ckjkj3mr200ck8jbo3
name=tester&task=tester&category=tester&manufacturer=tester&description=tester&ownerId=3375104
HTTP/1.1 302 Found
X-Cocoon-Version: 2.2.0
Location: http://localhost:8888/equipment/
Content-Length: 0
Server: Jetty(6.1.7)
----------------------------------------------------------
http://localhost:8888/equipment/
GET /equipment/ HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.10)
Gecko/20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost:8888/ui/start
Cookie: JSESSIONID=hr0mt4clb1k4;
webfx-tree-cookie-persistence=wfxt-4+wfxt-6;
PPA_ID=9qtajhe4ckjkj3mr200ck8jbo3
HTTP/1.1 200 OK
X-Cocoon-Version: 2.2.0
Content-Type: application/json; charset=UTF-8
Content-Length: 1838
Server: Jetty(6.1.7)
----------------------------------------------------------
Under 'generator' I find (note the redirect)
#request# PUT http://localhost:8888/equipment
PUT /equipment
name=tester&task=tester&category=tester&manufacturer=tester&description=tester&ownerId=3375104
#request# GET http://localhost:8888/equipment/
#redirect# GET /equipment/
>
>> [W]ith cocoon one can create very easily various
>> resource representation using XSLT, without the need the hardcode this
>> into Java. Cocoon 3 (there is an alpha version) is better prepared for
>> REST.
>
> Excellent. Good luck.
Thanks. And thanks again for your feedback. That was extremely helpful.
I sincerely hope that you are able to get the request for a new feature
related to PUT requests in the next version of Tomcat! Many users will
be very about that (including me).
André
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyaJEAACgkQ9CaO5/Lv0PBapgCeJuwk/PWW1x+mBKa8gA7x8k6J
> paUAnita0RxYiQkAVPogO19b/E+tmCzX
> =TbU7
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andre,
On 9/22/2010 3:36 AM, Andre Juffer wrote:
>> Try confirming (say, with LiveHttpHeaders) that the PUT is being
>> redirected by the server.
>
> This is what I see with LiveHttpHeaders:
>
> http://localhost:8888/equipment/
>
> POST /equipment/ HTTP/1.1
No, I meant try to PUT to http://localhost:8888/equipment (no trailing
slash) and see if the server redirects you. Also, it would be nice to to
know what kind of redirect is being issued. If a 303 response is being
generated, then the client is supposed to use a GET method for the
followup request. Other response codes have other meanings.
> [W]ith cocoon one can create very easily various
> resource representation using XSLT, without the need the hardcode this
> into Java. Cocoon 3 (there is an alpha version) is better prepared for
> REST.
Excellent. Good luck.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyaJEAACgkQ9CaO5/Lv0PBapgCeJuwk/PWW1x+mBKa8gA7x8k6J
paUAnita0RxYiQkAVPogO19b/E+tmCzX
=TbU7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
On 09/22/2010 01:27 AM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andre,
>
> On 9/21/2010 4:26 PM, Andre Juffer wrote:
>> I got it working now. It is really in the details.
>>
>> I always relied upon a PUT request like
>>
>> http://localhost:8888/equipment
>>
>> expecting to see the request method set to PUT. In fact, it was always GET.
>>
>> If, however, one employs
>>
>> http://localhost:8888/equipment/
>> -------------------------------^
>>
>> (Notice the forward slash at the end!)
>
> Wow! So, your server was issuing a redirect to the client?
> That usually
> only happens when you have something else going on.Is /equipment the
> context path of your webapp? If so, I think you have to have /something/
> after the "/equipment", otherwise it's a request for no resource at all.
The 'equipment' is in fact one of the blocks of my cocoon 2.2 based web
application. I have currently three blocks, ui, equipment, and eap, the
latter produces the war file (eap.war) that is to be placed in the
webapps directory of some servlet engine.
With cocoon, one can also immediately test your application by going
into one of the blocks (usually the eap) block and enter
mvn jetty:run
instead of copying the eap.war to the webapps directory of the servlet
engine. One needs to point your browser to
http://localhost:8888/ui/start
(so without the 'eap' in the path)
and posting equipment would require a POST request using
http://localhost:8888/equipment/
while updating with PUT would require
http://localhost:8888/equipment/12345
Note that the latter can also be used in a GET request. In addition, a
GET request like
http://localhost:8888/equipment/
results in a list of equipment (with or without the forward slash).
For the equipment block, equipment is than the context path. The
equipment block's sitemap contains
<map:match pattern="*">
<map:call function="equipmentHandler" />
</map:match>
meaning that -all- requests results in a call to equipmentHandler.
The path within the equipment block does not contain anymore
'equipment'. The issue with the extra forward slash at the end is
probably a cocoon thing, and because I have <map:match pattern="*"> in
the sitemap, I guess. Previous applications I have made with cocoon did
not use the <map:match pattern="*"> so this never occurred. I had things
like
<map:match pattern="manage/*">
and I was checking for a 'task' request parameter like in
http://localhost:8888/equipment/manage?task=update?id=12345
to decide what to do. I never was thinking in terms of REST. The whole
problem of not having the request parameters never occurred, simply
because the request parameters where always included in the path as above.
Now, using dojo.xhrPost() or dojo.xhrPut() on the client (Dojo Toolkit)
, the actual request send to the server is assembled differently, and in
the case of a POST or PUT request, the request parameters are not
anymore encoded into the path. Therefore I ran into problems with PUT
and POST. In all my previous emails, I used the PUT request as an
example, but I could have used POST as well.
I should note however, in context of REST, a PUT request for creating
(so not updating) a resource like
http://localhost:8888/equipment/
does indeed not make sense, as no identification of the resource is
provided. Creating resources is done with POST if the server can decide
on the path to (or ID of) the resource. If the client can decide on the
resource path (or ID), a PUT is appropriate.
>
> Try confirming (say, with LiveHttpHeaders) that the PUT is being
> redirected by the server.
This is what I see with LiveHttpHeaders:
http://localhost:8888/equipment/
POST /equipment/ HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.10)
Gecko/20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://localhost:8888/ui/start
Content-Length: 94
Cookie: JSESSIONID=hr0mt4clb1k4;
webfx-tree-cookie-persistence=wfxt-4+wfxt-6;
PPA_ID=9qtajhe4ckjkj3mr200ck8jbo3
Pragma: no-cache
Cache-Control: no-cache
name=hallo&task=thallo&category=testing&manufacturer=testing&description=hallo&ownerId=3375104
HTTP/1.1 200 OK
X-Cocoon-Version: 2.2.0
Content-Type: application/json; charset=UTF-8
Content-Length: 320
Server: Jetty(6.1.7)
So, no redirect, as far as I can see. I did not think that was happening.
>
>> Requests parameters are not
>> available, at least not with Jetty 1.6.7 (and I would assume the same is
>> true for tomcat 6 and 7, did not check).
>
> I've got an enhancement request in for TC 7, and I'm working on a patch.
> I have it working -- I'm just working on the unit tests and
> documentation, now.
>
>> So, this leaves us with the issue with PUT not having the parameters
>> available, but at least the request method is now properly set.
>>
>> I was almost ready to switch to a different framework like
>> https://jersey.dev.java.net/. Almost ....
>
> Well, building a REST service on top of Cocoon seems like a mismatch:
> Jersey was created explicitly for REST services.
That's right. But with cocoon one can create very easily various
resource representation using XSLT, withouy the need the hardcode this
into Java. Cocoon 3 (there is an alpha version) is better prepared for REST.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyZMVwACgkQ9CaO5/Lv0PCyiACgmprQv72BM35MiK5G7dN2t/lk
> GTkAn2O0wSCSvmaVH/R3EUlGUDrZN3Op
> =heIE
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andre,
On 9/21/2010 4:26 PM, Andre Juffer wrote:
> I got it working now. It is really in the details.
>
> I always relied upon a PUT request like
>
> http://localhost:8888/equipment
>
> expecting to see the request method set to PUT. In fact, it was always GET.
>
> If, however, one employs
>
> http://localhost:8888/equipment/
> -------------------------------^
>
> (Notice the forward slash at the end!)
Wow! So, your server was issuing a redirect to the client? That usually
only happens when you have something else going on. Is /equipment the
context path of your webapp? If so, I think you have to have /something/
after the "/equipment", otherwise it's a request for no resource at all.
Try confirming (say, with LiveHttpHeaders) that the PUT is being
redirected by the server.
> Requests parameters are not
> available, at least not with Jetty 1.6.7 (and I would assume the same is
> true for tomcat 6 and 7, did not check).
I've got an enhancement request in for TC 7, and I'm working on a patch.
I have it working -- I'm just working on the unit tests and
documentation, now.
> So, this leaves us with the issue with PUT not having the parameters
> available, but at least the request method is now properly set.
>
> I was almost ready to switch to a different framework like
> https://jersey.dev.java.net/. Almost ....
Well, building a REST service on top of Cocoon seems like a mismatch:
Jersey was created explicitly for REST services.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyZMVwACgkQ9CaO5/Lv0PCyiACgmprQv72BM35MiK5G7dN2t/lk
GTkAn2O0wSCSvmaVH/R3EUlGUDrZN3Op
=heIE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
Chris,
I got it working now. It is really in the details.
I always relied upon a PUT request like
http://localhost:8888/equipment
expecting to see the request method set to PUT. In fact, it was always GET.
If, however, one employs
http://localhost:8888/equipment/
-------------------------------^
(Notice the forward slash at the end!)
then the request method is set to PUT. Requests parameters are not
available, at least not with Jetty 1.6.7 (and I would assume the same is
true for tomcat 6 and 7, did not check). This is what one could expect,
as the specification does not require the availability of the request
parameters. A GET request with request parameters should also use the
forward slash at the end like
http://localhost:8888/equipment/?para1=val1¶m2=val2
But a GET without parameters like
http://localhost:8888/equipment/123456
is OK (is always interpreted as a GET).
Using a POST request instead (and with the forward slash), the request
method is POST and all parameters are now available through the
getParameter() family of methods ion flowscript. I've not tried any of
the other request methods like DELETE.
So, this leaves us with the issue with PUT not having the parameters
available, but at least the request method is now properly set.
I was almost ready to switch to a different framework like
https://jersey.dev.java.net/. Almost ....
Thanks,
André
On 09/21/2010 09:40 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andre,
>
> On 9/21/2010 2:04 PM, Andre Juffer wrote:
>> On 09/21/2010 07:38 PM, Christopher Schultz wrote:
>>> I find the Cocoon documentation very difficult to navigate. Can you
>>> point me to the documentation for calling javascript functions? All I
>>> could find was this:
>>> http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html
>>
>> Yeah, it is not that well organized. Have a look at:
>>
>> http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html
>
> In the examples, I see them use code like this:
>
> cocoon.request.get("foo")
>
> to get a request parameter. get() is not a standard method on
> HttpServletRequest, so this must be some kind of wrapper around
> HttpServletRequest.
>
> There seems to be nothing about working with<map:parameter> elements
> from the sitemap in the flowscript. :(
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyY/CgACgkQ9CaO5/Lv0PDbZgCfSd98cokDRntfHnLRMkDLduTz
> 0LAAoKlpGlBDntPj09UTTlyVID7OZkS+
> =JCr8
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andre,
On 9/21/2010 2:04 PM, Andre Juffer wrote:
> On 09/21/2010 07:38 PM, Christopher Schultz wrote:
>> I find the Cocoon documentation very difficult to navigate. Can you
>> point me to the documentation for calling javascript functions? All I
>> could find was this:
>> http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html
>
> Yeah, it is not that well organized. Have a look at:
>
> http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html
In the examples, I see them use code like this:
cocoon.request.get("foo")
to get a request parameter. get() is not a standard method on
HttpServletRequest, so this must be some kind of wrapper around
HttpServletRequest.
There seems to be nothing about working with <map:parameter> elements
from the sitemap in the flowscript. :(
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyY/CgACgkQ9CaO5/Lv0PDbZgCfSd98cokDRntfHnLRMkDLduTz
0LAAoKlpGlBDntPj09UTTlyVID7OZkS+
=JCr8
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
On 09/21/2010 07:38 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andre,
>
> (Is everyone on the list named Andre? :)
No, there is Robbie as well!
>
> On 9/21/2010 9:10 AM, Andre Juffer wrote:
>> There is still one other issue to be solved. In the case of a PUT
>> request (or any other HTTP request for that matter), my understanding is
>> that I should be able to identify the request HTTP method in flowscript
>> by cocoon.request.getMethod() or in a pipeline using<map:parameter
>> name="method" value="{request:method}" />. I find in either case that
>> this parameter's value is always GET, whatever the original request
>> method received by the servlet engine was. It seems that the original
>> request method value is simply lost somewhere, -before- the request is
>> being handled in the sitemap.
>
> I'll check to see what I can get from {request:method} in my sitemap.
> Other {request:*} methods seem to be working okay, though. I am also
> using Cocoon 2.1, but at (the other) Andre points out, the differences
> shouldn't be great in these areas.
>
> I'm still interested in how Cocoon passes parameters to functions. In
> the code you posted before, it didn't seem like you were actually trying
> to access that parameter. If you use {request:method} in your pipeline,
> I suspect it will give you the right method as long as you read the
> /parameter/ instead of trying to use cocoon.request.getMethod() as it
> appeared you were doing.
That's right. Both approaches are fine. I tend to use the
cocoon.request.get* because it is available anyways within flowscript
functions.
>
> I find the Cocoon documentation very difficult to navigate. Can you
> point me to the documentation for calling javascript functions? All I
> could find was this:
> http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html
Yeah, it is not that well organized. Have a look at:
http://cocoon.apache.org/2.2/blocks/flowscript/1.0/1241_1_1.html
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyY36MACgkQ9CaO5/Lv0PALAgCgtih3jh2Z4nqm+RuRafLbGOEe
> qCAAoLofwTo+Tah8/kyZlF2sA2B504Wh
> =B+Zg
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andre,
(Is everyone on the list named Andre? :)
On 9/21/2010 9:10 AM, Andre Juffer wrote:
> There is still one other issue to be solved. In the case of a PUT
> request (or any other HTTP request for that matter), my understanding is
> that I should be able to identify the request HTTP method in flowscript
> by cocoon.request.getMethod() or in a pipeline using <map:parameter
> name="method" value="{request:method}" />. I find in either case that
> this parameter's value is always GET, whatever the original request
> method received by the servlet engine was. It seems that the original
> request method value is simply lost somewhere, -before- the request is
> being handled in the sitemap.
I'll check to see what I can get from {request:method} in my sitemap.
Other {request:*} methods seem to be working okay, though. I am also
using Cocoon 2.1, but at (the other) Andre points out, the differences
shouldn't be great in these areas.
I'm still interested in how Cocoon passes parameters to functions. In
the code you posted before, it didn't seem like you were actually trying
to access that parameter. If you use {request:method} in your pipeline,
I suspect it will give you the right method as long as you read the
/parameter/ instead of trying to use cocoon.request.getMethod() as it
appeared you were doing.
I find the Cocoon documentation very difficult to navigate. Can you
point me to the documentation for calling javascript functions? All I
could find was this:
http://cocoon.apache.org/2.2/core-modules/core/2.2/844_1_1.html
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyY36MACgkQ9CaO5/Lv0PALAgCgtih3jh2Z4nqm+RuRafLbGOEe
qCAAoLofwTo+Tah8/kyZlF2sA2B504Wh
=B+Zg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by Andre Juffer <an...@oulu.fi>.
Thanks for your response.
I am going to try this and see if this works. The RequestMethodSelector
is also available in Cocoon 2.2. I just did not expect that one must use
it to identify the request method in the sitemap, given that the request
object is available as cocoon.request in flow as well.
On 09/21/2010 04:40 PM, florent andré wrote:
> Hi Andre,
>
> Thanks for your day to day research feedback.
>
> In Lenya (widely use of cocoon), we have this :
> <map:select type="request-method">
> <!-- many client editors like to PUT changes -->
> <map:when test="PUT">
> <map:mount uri-prefix=""
> src="{fallback:lenya/modules/webdav/sitemap.xmap}" check-reload="true"
> reload-method="synchron"/>
> </map:when>
> </map:select>
>
> So the request-method selector seems to detect PUT.
>
> The selector is implemented here :
> cocoon_2_1_x/src/java/org/apache/cocoon/selection/RequestMethodSelector.java
>
>
> With this code :
> String method = ObjectModelHelper.getRequest(objectModel).getMethod();
>
> Note that is cocoon 2.1, but normaly no big changes with 2.2.
>
> Maybe selector and input don't have the same implementation ?
>
> Just some piece of informations I have. I'm not enough inform about
> how cocoon deal with request for helping more.
> HTH
>
> ++
>
>
> On 09/21/2010 03:10 PM, Andre Juffer wrote:
>> Dear All,
>>
>> in a previous thread, I was trying to understand why I could not see the
>> request parameters of a HTTP PUT request using the
>> cocoon.request.getParameter("...") family of methods in flowscript.
>> Conclusion: For a PUT request, according to specification, the servlet
>> engine is -not- required to parse the request for making the parameters
>> available through request.getParameter("..") and consequently also
>> cocoon.request.getParameter("...") will not return a value (just
>> 'null'). [1]
>>
>> One remedy is assume POST requests (client side) instead for the time
>> being, despite differences in the meaning of POST and PUT with regard to
>> RESTful applications.
>>
>> There is still one other issue to be solved. In the case of a PUT
>> request (or any other HTTP request for that matter), my understanding is
>> that I should be able to identify the request HTTP method in flowscript
>> by cocoon.request.getMethod() or in a pipeline using <map:parameter
>> name="method" value="{request:method}" />. I find in either case that
>> this parameter's value is always GET, whatever the original request
>> method received by the servlet engine was. It seems that the original
>> request method value is simply lost somewhere, -before- the request is
>> being handled in the sitemap.
>>
>> I now seek answers to the following:
>>
>> 1. Can one of you confirm (or not) that this is indeed the case. That
>> is, cocoon interferes with the original request and makes it a (or
>> creates a new) GET request. It is certain that the servlet engine
>> receives the PUT request in good order. It is also certain that the
>> servlet engine is not changing the original request. It simply passes it
>> on the cocoon-based webapp.
>>
>> 2. If item 1 above is in fact true (and I really hope this is not the
>> case), what would be solution to overcome this issue. I could image
>> making a filter that adds an extra parameter or attribute
>> 'request-method' or something to the request that retains the original
>> HTTP method and query for its value in the sitemap or in flowscript. I
>> have to hope that cocoon retains this extra parameter or attribute when
>> it receives the request.
>>
>> I would very much appreciate any response in this matter. I could not
>> find answers on the cocoon email lists or in the documentation,
>> unfortunately.
>>
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/cocoon-users/201009.mbox/browser
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
Posted by florent andré <fl...@4sengines.com>.
Hi Andre,
Thanks for your day to day research feedback.
In Lenya (widely use of cocoon), we have this :
<map:select type="request-method">
<!-- many client editors like to PUT changes -->
<map:when test="PUT">
<map:mount uri-prefix=""
src="{fallback:lenya/modules/webdav/sitemap.xmap}" check-reload="true"
reload-method="synchron"/>
</map:when>
</map:select>
So the request-method selector seems to detect PUT.
The selector is implemented here :
cocoon_2_1_x/src/java/org/apache/cocoon/selection/RequestMethodSelector.java
With this code :
String method = ObjectModelHelper.getRequest(objectModel).getMethod();
Note that is cocoon 2.1, but normaly no big changes with 2.2.
Maybe selector and input don't have the same implementation ?
Just some piece of informations I have. I'm not enough inform about how
cocoon deal with request for helping more.
HTH
++
On 09/21/2010 03:10 PM, Andre Juffer wrote:
> Dear All,
>
> in a previous thread, I was trying to understand why I could not see the
> request parameters of a HTTP PUT request using the
> cocoon.request.getParameter("...") family of methods in flowscript.
> Conclusion: For a PUT request, according to specification, the servlet
> engine is -not- required to parse the request for making the parameters
> available through request.getParameter("..") and consequently also
> cocoon.request.getParameter("...") will not return a value (just
> 'null'). [1]
>
> One remedy is assume POST requests (client side) instead for the time
> being, despite differences in the meaning of POST and PUT with regard to
> RESTful applications.
>
> There is still one other issue to be solved. In the case of a PUT
> request (or any other HTTP request for that matter), my understanding is
> that I should be able to identify the request HTTP method in flowscript
> by cocoon.request.getMethod() or in a pipeline using <map:parameter
> name="method" value="{request:method}" />. I find in either case that
> this parameter's value is always GET, whatever the original request
> method received by the servlet engine was. It seems that the original
> request method value is simply lost somewhere, -before- the request is
> being handled in the sitemap.
>
> I now seek answers to the following:
>
> 1. Can one of you confirm (or not) that this is indeed the case. That
> is, cocoon interferes with the original request and makes it a (or
> creates a new) GET request. It is certain that the servlet engine
> receives the PUT request in good order. It is also certain that the
> servlet engine is not changing the original request. It simply passes it
> on the cocoon-based webapp.
>
> 2. If item 1 above is in fact true (and I really hope this is not the
> case), what would be solution to overcome this issue. I could image
> making a filter that adds an extra parameter or attribute
> 'request-method' or something to the request that retains the original
> HTTP method and query for its value in the sitemap or in flowscript. I
> have to hope that cocoon retains this extra parameter or attribute when
> it receives the request.
>
> I would very much appreciate any response in this matter. I could not
> find answers on the cocoon email lists or in the documentation,
> unfortunately.
>
>
> [1]
> http://mail-archives.apache.org/mod_mbox/cocoon-users/201009.mbox/browser
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org