Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4E7C66F5.2050705@oulu.fi>
Date: Fri, 23 Sep 2011 14:01:09 +0300
From: Andre Juffer <andre.juffer@oulu.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.22) Gecko/20110907 Mandriva/3.1.14-0.1mdv2010.2 (2010.2)
 Thunderbird/3.1.14
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: cocoon3 : apache 2 -> jetty-1.6.7
References: <4E7A5E15.5050007@cc.oulu.fi>
 <1316680086.11408.1.camel@mcKenny>	 <4E7B9516.1000504@cc.oulu.fi>
 <1316768369.3440.21.camel@mcKenny>	 <4E7C5FB8.3040503@oulu.fi>
 <1316775141.3440.39.camel@mcKenny>
In-Reply-To: <1316775141.3440.39.camel@mcKenny>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.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