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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juf...@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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
