On 23/09/11 13:52, Thorsten Scherler wrote:
Ah ok, sorry I have not understood correctly the first time. Ok if so
then I think you found a bug since above would hit:
@Override
public void setConfiguration(Map<String, ? extends Object>
configuration) {
this.setSource((URL) configuration.get("source"));
this.setMimeType((String) configuration.get("mime-type"));
}
in AbstractReader. Since in the first place that that value is null .
Yeah, that would make sense to me.
In the
then we do
public String getContentType() {
if (this.mimeType != null) {
return this.mimeType;
}
URLConnection connection = null;
try {
connection = this.source.openConnection();
return connection.getContentType();
} catch (IOException e) {
throw new ProcessingException(e);
} finally {
URLConnectionUtils.closeQuietly(connection);
}
}
Meaning if this.mimeType == null and the connection fails then and only
then it should return null. Now the question is why
- either fails the connection
- or the connection.getContentType() returns null.
If I have some time over the next week or so, I will debug the
application to see what actually happens.
I'll keep you posted,
André
salu2
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: andre.juf...@oulu.fi
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: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
