Hi Thorsten,
I am not sure whether or not there is a problem with the JsonSerializer.
In the c3-based application I am working on, the first file that is
loaded is a regular HTML file (served by apache->jetty->cocoon). This is
where the problem actually occurs. The JsonSerializer is not being used
at all during this initial phase. Only -after- the dojo-1.6.1 based
application starts up, the application contacts the cocoon3-based server
for additional content. The server always returns this particular
content as JSON and only then the JsonSerializer is relied upon.
Having said this, I am not entirely clear on the internal organization
of cocoon3, so I could easily have overlooked and probably did overlook
something. As said, modifying the site map from
<map:match pattern="">
<map:read src="index.html" />
</map:match>
to
<map:match pattern="">
<map:read src="index.html" mime-type="text/html"/>
</map:match>
resolves the issue completely (that is, the index.html is properly interpreted
as text/html and the application starts and actually works fine (version
0.0.1)). The index.html is returned by an (Encoding)(X)HTMLSerializer and not
by my (Encoding)JsonSerializer. So, this why I concluded that the problem is
actually not related to the JsonSerializer.
But I will go through your remarks in this email and at COCOON3-77. The
content-type and mime-type part was actually not entirely to me where
and how exactly they had to be set. So, you hit the right spot.
Thanks for your reply,
André
On 23/09/11 11:59, Thorsten Scherler wrote:
On Thu, 2011-09-22 at 23:05 +0300, Andre Juffer wrote:
On 09/22/2011 11:28 AM, Thorsten Scherler wrote:
On Thu, 2011-09-22 at 00:58 +0300, Andre Juffer wrote:
Note mimeType=null in the first case. Thus the request reaches
cocoon3, but somewhere the mimeType is set to null, or, when its
value
is requested, the mimeType returns null.
Bug? Or just my fold (I suspect the JsonSerializer [1])
To limit the range
a bit, what happens when you use html or xml
serialization?
The following two requests read a html (index.html) file containing Dojo
javascript. The response should be of type text/html in order to run the
javascript for the application to start. For both requests below, the
index.html -is- in fact returned.
These are the test results:
1)
http://localhost/app/tct
186790 [btpool0-2] INFO org.apache.cocoon.servlet.RequestProcessor -
Performing GET request at /app/tct
186819 [btpool0-2] INFO org.apache.cocoon.servlet.RequestProcessor -
Going to send GET response: mimeType=null, contentLength=1706,
statusCode=200, lastModified=1316719151000
2)
http://localhost/app/tct/index.html
287900 [btpool0-6] INFO org.apache.cocoon.servlet.RequestProcessor -
Performing GET request at /app/tct/index.html
287919 [btpool0-6] INFO org.apache.cocoon.servlet.RequestProcessor -
Going to send NOT MODIFIED response: statusCode=304,
lastModified=1316719151000
Sitemap contains:
For 1):
<map:match pattern="">
<map:read src="index.html" />
</map:match>
For 2)
<map:match equals="index.html">
<map:read src="index.html" />
</map:match>
THUS: The first response has no mime-type set (mimeType=null). The
browser (firefox) interprets the response of type text/plain (thus no
javascript will run, no startup of the application will occur). The
mime-type of the second request is text/html, as it should be.
If I now make the change in the sitemap to handle request 1):
<map:match pattern="">
<map:read src="index.html" mime-type="text/html"/>
</map:match>
and repeat the first request (http://localhost/app/tct), I -do- get the
proper response (that is, text/html):
135151 [btpool0-8] INFO org.apache.cocoon.servlet.RequestProcessor -
Performing GET request at /app/tct
135166 [btpool0-8] INFO org.apache.cocoon.servlet.RequestProcessor -
Going to send NOT MODIFIED response: statusCode=304,
lastModified=1316720003000
135166 [btpool0-8] INFO org.apache.cocoon.servlet.RequestProcessor -
Sitemap execution for /app/tct took 15.131032 ms.
and the application starts normally.
Thus, I would say that the mime-type of the response is not properly set
(probably null by default) or not detected for case 1), when
communicating with a web server that forwarded the original request to
the servlet container (jetty-6.1.7)? This perhaps points to a problem in
ResponseHeaderCollector.java and pipeline.getContentType()?
Actually I think the problems lies in the code you attached to
COCOON3-77 (I just made a comment there). My first try would be to try
to extend from AbstractSAXSerializer and/or implements Finisher.
The important point is
@Override
public void setConfiguration(Map<String, ? extends Object>
configuration) {
if (configuration.containsKey("mime-type")) {
this.contentType = (String) configuration.get("mime-type");
}
}
/**
* @param contentType The type of the content produced by this
serializer.
*/
public void setContentType(String contentType) {
this.contentType = contentType;
}
In other word make sure this.contentType = contentType; is done in some
moment. I saw you do in
@Override
public String getContentType()
{
return this.getMimeType();
}
is this method called from cocoon? Did you set a breakpoint?
salu2
--
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/
StrucBioCat | WWW: www.strucbiocat.oulu.fi
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
