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 inside<map: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" value="{request:serverPort}" />
It's possible that whatever<map:call> does isn't a real request and is
always modeled as a GET. Someone much more familiar with Cocoon will
have to comment on this.
Which version of cocoon are you using? Could you test the value of
request:method for a PUT request (in fact for any other request than GET)?
The equipmentHandler() function is basically implemented as (stripped
version)
function equipmentHandler()
{
var request = cocoon.request;
Is cocoon.request how you get information from Cocoon? If you can get
the request from "cocoon.request", then why do you need the "method"
parameter to your function call? Why not just do "cocoon.request.method"
or "request.getMethod()"?
That's right. I actually do not need the map:parameter line of code, as
I can directly access parameters with
cocoon.request.getParameter("..."). Using map:parameter copies the value
of request:method into cocoon.parameters.method, which I subsequently
can access in equipmentHandler(). I just wanted to check the value of
request:method in the sitemap to see if the call to equipmentHandler()
was causing the problem of not having anymore the correct request method
and parameters in that function.
Something doesn't seem right, here, though I'll admit that I know
absolutely nothing about how to use Javascript functions inside Cocoon.
Just make sure you are using the right syntax to get your function
parameter from the Cocoon pipeline, or that you are using the right
syntax to grab the request method from the request. It's also possible
that the implementation of<map:call> does something that makes
everything look like GET, as I theorized above.
I think I can safely say that the request method is already incorrect
before the call is made to equipmentHandler(). Thus, my conclusion is
that there is a some bug or communication problem between cocoon and the
actual request. That is, cocoon is possibly 'changing' the actual
request, or creates a new requests, losing somewhere the actual request
method value. This would very frustrating if this indeed would be the
case, rendering the current version of cocoon virtually useless for use
in RESTful web applications applications. I would not like to switch to
official RESTful tools like RESTlet and so forth. They seem more
complicated from my vantage point.
The code is pretty much standard and as far as I can see is not
interfering at all with the actual request. The only thing that is not
yet clear to me why the request method is always GET. I am wondering now
if Jetty or Tomcat are converting a PUT request simply into a GET request.
Tomcat certainly doesn't do such a thing, and I'd be surprised if Jetty
does it. But, Cocoon might be doing it.
Yeah, it did not seem logical to me either. As indicated above, more
likely cocoon is somehow interfering with the request. I can clearly see
from the log files of Tomcat 6 (7) and Jetty 6 that the servlets receive
the request as a PUT request. Any alteration of the request is committed
by cocoon, before the request reaches the sitemap. I will dig into the
code, if possible, if this is really the case.
I wish that somebody of the cocoon community would comment on this
thread and hopefully correct me in this matter.
Thanks,
André.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyXxk8ACgkQ9CaO5/Lv0PCoYACdFU3QSyAv7DIgru4agBY5kKbP
TD8AnR98/mgxelI3Hzt2Jg4tVMYepebi
=XBsh
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
