Re: RESTful applications
On 09/20/2010 11:38 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andre,
On 9/20/2010 3:06 PM, Andre Juffer wrote:
The source of my problem is therefore clear.
Absolutely.
I've checked Tomcat 7.0.2. Same issue, as expected.
With jetty 7.1.6, I'll get an exception:
2010-09-20 22:32:49.362:WARN::Failed startup of context
webappcont...@55eb1db2@55eb1db2/eap,[file:/tmp/Jetty_0_0_0_0_8080_eap.war__eap__hlptaf/webinf/,
jar:f
ile:/home/juffer/jetty-distribution-7.1.6.v20100715/webapps/eap.war!/],/home/juffer/jetty-distribution-7.1.6.v20100715/webapps/eap.war
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'org.apache.cocoon.Processor': Initialization of bean
failed; nested e
xception is org.springframework.beans.factory.BeanCreationException:
Unable to initialize Avalon component with role
org.apache.cocoon.Processor; nested exce
ption is
org.apache.avalon.framework.configuration.ConfigurationException: Cannot
resolve context://sitemap.xmap
This is probably just a configuration issue as jetty 6 works fine with
my application. So, I cannot confirm that jetty 7 actually parses a PUT
request for making parameters available through getParameter(). Jetty 6
does not seem to do this either as I get exactly the same result as with
Tomcat 6 and 7. But all of this could as well be caused by cocoon internals.
PUT and POST have somewhat different meanings to RESTful applications
and I intend to stick to that. On the tomcat list, it was indeed also
suggested to change a PUT request into a POST request using a Filter. I
prefer to keep things compatible with standards and specifications.
So, does that mean that you'd be more amenable to switching from PUT to
POST, or are you interested in getting PUT to work in one way or another?
Note that adding a Filter to make PUT work for you doesn't violate any
standards at all: it implements behavior your application requires. The
only thing you could say is that is does something /other/ than what the
servlet specification requires. Also note that parsing PUT bodies does
not violate the servlet spec: it's simply not required by it, and
therefore Tomcat doesn't implement it.
Based upon this thread and the others you've probably read, I've filed
an enhancement request against Tomcat:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49964
Feel free to comment on this bug if you'd like.
Great!
I would not like to convert a PUT into a POST request. This would
obscure the meaning of and differences between PUT and POST in context
of RESTful applications. My opinion is that in the case of a PUT
request, the servlet should simply pars the request and make the
parameters available through the getParameters() family. As you said,
this does not violate any specification. Therefore, I am in full support
of this feature request (no sure whether you should call this a bug).
For now, I will assume a POST instead of a PUT request and decide inside
equipmentHandler() what to do. This keeps maintenance of the code
simple. I will make some modifications this evening to see how this is
going. But if the request method is still GET, then this would not solve
anything.
[The DefaultServlet has a] readonly parameter in web.xml to change this
behavior,
but indeed this would not have any impact since the request is handled
by my cocoon2.2-based servlet.
Exactly: DefaultServlet was written to implement PUT as specified in the
HTTP specification, and knows nothing about your REST stuff.
All Tomcat versions should behave this way, as the servlet specification
has been (relatively) consistent across the versions covered by Tomcat
implementations.
Yes, I got to the same conclusion, again from the Tomcat list. That list
was in fact extremely helpful to understand what is going on.
Good. We try to be helpful :)
Thanks!
I use the sitemap that was generated during block creation with Maven,
as documented on the cocoon website.
[snip]
The pipeline that handles the request is really extremely simple:
map:match pattern=*
map:call function=equipmentHandler
map:parameter name=method value={request:method} /
/map:call
/map:match
Hmm... I've never worked with functions as you have above, but I
definitely use the request matcher. Here's what I have in one of my
pipelines, and it definitely works when nested insidemap:transform:
You don't have to. My function is communicating among other with a
database to get things done. But in certain cases, one can also
accomplish this with XSLT stylesheets. Javascript (or actually
Flowscrip) is very convenient to handle client requests and making the
right call to the domain layer.
map:parameter name=requestScheme value={request:scheme} /
map:parameter name=requestServerName value={request:serverName} /
map:parameter name=requestServerPort
Re: RESTful applications
Christopher, On 09/20/2010 11:38 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [The DefaultServlet has a] readonly parameter in web.xml to change this behavior, but indeed this would not have any impact since the request is handled by my cocoon2.2-based servlet. Exactly: DefaultServlet was written to implement PUT as specified in the HTTP specification, and knows nothing about your REST stuff. I found this (for Tomcat 5) http://webcache.googleusercontent.com/search?q=cache:lJ-4J6f0GPQJ:old.nabble.com/How-to-configure-Toncat-to-accept-HTTP-PUT-requests--td18652489.html+%22HTTP+PUT%22+Tomcathl=enstrip=1 Seems to indicate that one can apply this to the individual wepapps as well. I thought that the readOnly configuration parameter could be employed only for the default webapp (DefaultServlet). -- 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
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.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
Re: Cocoon 2.2 PUT HTTP request
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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
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-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
Re: Cocoon 2.2 PUT HTTP request
-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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: RESTful applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, On 9/21/2010 6:22 AM, Andre Juffer wrote: I found this (for Tomcat 5) http://webcache.googleusercontent.com/search?q=cache:lJ-4J6f0GPQJ:old.nabble.com/How-to-configure-Toncat-to-accept-HTTP-PUT-requests--td18652489.html+%22HTTP+PUT%22+Tomcathl=enstrip=1 Seems to indicate that one can apply this to the individual wepapps as well. Correct: you can configure the DefaultServlet specifically for an individual webapp if you choose. Otherwise, you inherit the global configuration that gets applied to all webapps. I thought that the readOnly configuration parameter could be employed only for the default webapp (DefaultServlet). I think you're confusing webapps (represented by a ServletContext object) with servlets, of which the DefaultServlet is one. Each webapp gets a copy of a DefaultServlet deployed into it to handle requests not otherwise mapped. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyY4FAACgkQ9CaO5/Lv0PCv/gCfaO/R2awXV7MXwq7vRkzsrrpU 4FcAniEuYEh92U/XXGFbB7JStJfY++JO =Mori -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
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 usingmap: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-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
Re: RESTful applications
On 09/21/2010 07:41 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, On 9/21/2010 6:22 AM, Andre Juffer wrote: I found this (for Tomcat 5) http://webcache.googleusercontent.com/search?q=cache:lJ-4J6f0GPQJ:old.nabble.com/How-to-configure-Toncat-to-accept-HTTP-PUT-requests--td18652489.html+%22HTTP+PUT%22+Tomcathl=enstrip=1 Seems to indicate that one can apply this to the individual wepapps as well. Correct: you can configure the DefaultServlet specifically for an individual webapp if you choose. Otherwise, you inherit the global configuration that gets applied to all webapps. I thought that the readOnly configuration parameter could be employed only for the default webapp (DefaultServlet). I think you're confusing webapps (represented by a ServletContext object) with servlets, of which the DefaultServlet is one. Each webapp gets a copy of a DefaultServlet deployed into it to handle requests not otherwise mapped. OK, got it. Thanks for pointing this out. I learn these things on the fly and get sometimes the terminology wrong. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyY4FAACgkQ9CaO5/Lv0PCv/gCfaO/R2awXV7MXwq7vRkzsrrpU 4FcAniEuYEh92U/XXGFbB7JStJfY++JO =Mori -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
Re: Cocoon 2.2 PUT HTTP request
-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-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
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 withmap: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-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
Re: Cocoon 2.2 PUT HTTP request
-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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2 PUT HTTP request
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-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
Re: Cocoon 2.2 PUT HTTP request
Chris, I got it working now. It is really in the details. I always relied upon a PUT request like http://localhost:/equipment expecting to see the request method set to PUT. In fact, it was always GET. If, however, one employs http://localhost:/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:/equipment/?para1=val1param2=val2 But a GET without parameters like http://localhost:/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 withmap: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-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
Re: Cocoon 2.2 PUT HTTP request
-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:/equipment expecting to see the request method set to PUT. In fact, it was always GET. If, however, one employs http://localhost:/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-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
