cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Juffer <andre.juf...@oulu.fi>
Subject Re: cocoon3 : apache 2 -> jetty-1.6.7
Date Fri, 23 Sep 2011 10:30:16 GMT
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: andre.juffer@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-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message