[jira] [Commented] (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

2017-07-14 Thread Woonsan Ko (JIRA)

[ 
https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087480#comment-16087480
 ] 

Woonsan Ko commented on FREEMARKER-55:
--

{{AbstractTemplateView}} has an option to put every attribute to model, but the 
option is turned off by default.
And, 
{{org.springframework.web.servlet.view.freemarker.FreeMarkerView#buildTemplateModel(Map, HttpServletRequest, HttpServletResponse)}} does put the 
{{FreemarkerServlet}} variables again *for some reason*.
My guess is probably {{FreemarkerServlet}} variables are more efficient than 
iterating and copying the attributes in {{AbstractTemplateView}}. Anyway, 
that's my guess. So did I.
I'll create a new pull request with renaming *Freemarker* to *FreeMarker*.

> FM3 freemarker-spring module, Web MVC support
> -
>
> Key: FREEMARKER-55
> URL: https://issues.apache.org/jira/browse/FREEMARKER-55
> Project: Apache Freemarker
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Daniel Dekany
>
> Add Spring "Web MVC framework" functionality to freemarker-spring.
> This can be complex task (and the issue possibly has to be subdivided), as it 
> involves things like:
> * Some aspects of the FreeMarker 2 integration (developed by the Spring 
> developers) are quite confusing ({{FreemarerConfigurer}}, etc.), and we are 
> looking into if it needs to be like that.
> * See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
> hard coded into {{ViewResolverRegistry}}, which we can't modify)
> * Creating custom directives/methods to expose Spring features like the 
> Spring JSP Tag Library does (but in a way that firs FreeMarker better)
> * Expose JSP custom tag support from the {{freemarker-servlet}} module.
> Depends on: FREEMARKER-54



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

2017-07-13 Thread Woonsan Ko (JIRA)

[ 
https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16086481#comment-16086481
 ] 

Woonsan Ko commented on FREEMARKER-55:
--

Yeah, {{org.springframework.web.servlet.view.AbstractTemplateView}} puts the 
{{RequestContext}} object (by name of {{springMacroRequestContext}}) into 
{{model}}.
As our {{FreemarkerView}} extends it, the attribute should still exist as well 
in the model.

> FM3 freemarker-spring module, Web MVC support
> -
>
> Key: FREEMARKER-55
> URL: https://issues.apache.org/jira/browse/FREEMARKER-55
> Project: Apache Freemarker
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Daniel Dekany
>
> Add Spring "Web MVC framework" functionality to freemarker-spring.
> This can be complex task (and the issue possibly has to be subdivided), as it 
> involves things like:
> * Some aspects of the FreeMarker 2 integration (developed by the Spring 
> developers) are quite confusing ({{FreemarerConfigurer}}, etc.), and we are 
> looking into if it needs to be like that.
> * See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
> hard coded into {{ViewResolverRegistry}}, which we can't modify)
> * Creating custom directives/methods to expose Spring features like the 
> Spring JSP Tag Library does (but in a way that firs FreeMarker better)
> * Expose JSP custom tag support from the {{freemarker-servlet}} module.
> Depends on: FREEMARKER-54



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

2017-07-05 Thread Woonsan Ko (JIRA)

[ 
https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16075734#comment-16075734
 ] 

Woonsan Ko commented on FREEMARKER-55:
--

Hi [~ddekany],

I've created a new PR based on your reviews like the following:
- Switched Servlet spec dependency to 3.0 and jsp-api/EL dependencies to 2.2.
- I've set the spring dependency version to 4.0.x (4.0.9.RELEASE) as a minimal 
servlet-spec 3.0 based framework.
- Made {{TaglibFactory}} immutable and add {{Builder}} extending 
{{CommonBuilder}} inside the {{TaglibFactory}}.
- Moved {{SpringResourceTemplateLoader}} to {{org.apache.freemarker.spring}} 
package.

Regarding "the existing Spring macros/functions", yes, I agree. We'll need to 
add new macros/functions.

Regarding "FreemarkerViewResolver exposing things like FreemarkerServlet: ...", 
{{FreemarkerViewResolver}} doesn't expose {{FreemarkerServlet}}, but it uses 
only constants defined in the {{FreemarkerServlet}} to use the same attribute 
names, for instance. It used to expose some 'protected' getters/setters for the 
internal {{GenericServlet}} (for page object in JSP taglibs), {{ObjectWrapper}} 
and {{ServletContextModel}}, but those were removed now. Used only internally 
now.
BTW, {{View}} of Spring Framework is dependent on {{HttpServletRequest}} and 
{{HttpServletResponse}}. So, {{pageContextServlet}}, {{servletContextModel}} 
and {{taglibFactory}} in {{FreemarkerView}} (passed by 
{{FreemarkerViewResolver}}) should be okay.

Regards,

Woonsan

> FM3 freemarker-spring module, Web MVC support
> -
>
> Key: FREEMARKER-55
> URL: https://issues.apache.org/jira/browse/FREEMARKER-55
> Project: Apache Freemarker
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Daniel Dekany
>
> Add Spring "Web MVC framework" functionality to freemarker-spring.
> This can be complex task (and the issue possibly has to be subdivided), as it 
> involves things like:
> * Some aspects of the FreeMarker 2 integration (developed by the Spring 
> developers) are quite confusing ({{FreemarerConfigurer}}, etc.), and we are 
> looking into if it needs to be like that.
> * See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
> hard coded into {{ViewResolverRegistry}}, which we can't modify)
> * Creating custom directives/methods to expose Spring features like the 
> Spring JSP Tag Library does (but in a way that firs FreeMarker better)
> * Expose JSP custom tag support from the {{freemarker-servlet}} module.
> Depends on: FREEMARKER-54



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

2017-07-03 Thread Woonsan Ko (JIRA)

[ 
https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073099#comment-16073099
 ] 

Woonsan Ko edited comment on FREEMARKER-55 at 7/4/17 5:34 AM:
--

Initial pull request submitted:
- https://github.com/apache/incubator-freemarker/pull/25

This initial pull request contains the following:
- FreemarkerView and FreemarkerViewResolver. So, it is now possible to use this 
new view and resolver with the ConfigurationFactoryBean, I think, with a 
configuration like the following:
{code}
  

  

  

  
UTF-8
true
strong:20, soft:250
 
   
   
  


  


  

  

  
{code}
- So, we don't need something like {{FreeMarkerConfigurer}} which is referred 
to implicitly by type in spring lib, but the view resolver should be configured 
with a {{Configuration}} explicitly.
- As {{FreeMarkerViewResolver}} extends {{AbstractTemplateViewResolver}} of 
spring, I believe the existing macros of spring should be supported as-is. I 
didn't verify this though.
- Still we will probably need to consider how we can provide better "custom 
directives/methods" for templating in spring env than the existing ones in 
spring lib.
- FreemarkerViewResolver exposes servlet context model, request 
attribute/parameter models, session model and JSP TaglibFactory,  by default, 
like FreemarkerServlet does.
  (I just thought it wouldn't do any harm by providing those by default. Not 
sure yet if we should make them optional.)
  To achieve this, I have slightly refactored FreemarkerServlet in the areas of 
TaglibFactory building and too tight dependency on FreemarkerServlet in session 
model (by changing it to GenericServlet, so that can be used in the spring 
module as well).
- Added {{org.apache.geronimo.specs:geronimo-servlet_3.0_spec}} dependency as 
spring framework 4 requires servlet-spec 3 API (which is different from 
freemarker-servlet's; should we update freemarker-servlet's too?).

TODOs:
- See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
hard coded into ViewResolverRegistry, which we can't modify)
- Consider better "custom directives/methods" for templating in spring env.
- Integration testing in a simple web application module?


was (Author: woon_san):
Initial pull request submitted:
- https://github.com/apache/incubator-freemarker/pull/25

This initial pull request contains the following:
- FreemarkerView and FreemarkerViewResolver. So, it is now possible to use this 
new view and resolver with the ConfigurationFactoryBean, I think, with a 
configuration like the following:
{code}
  

  

  

  
UTF-8
true
strong:20, soft:250
 
   
   
  


  


  

  

  
{code}
- So, we don't need something like {{FreeMarkerConfigurer}} which is referred 
to implicitly by type in spring lib, but the view resolver should be configured 
with a {{Configuration}} explicitly.
- As {{FreeMarkerViewResolver}} extends {{AbstractTemplateViewResolver}} of 
spring, I believe the existing macros of spring should be supported as-is. I 
didn't verify this though.
- Still we will probably need to consider how we can provide better "custom 
directives/methods" for templating in spring env than the existing ones in 
spring lib.
- FreemarkerViewResolver exposes servlet context model, request 
attribute/parameter models, session model and JSP TaglibFactory,  by default, 
like FreemarkerServlet does.
  (I just thought it wouldn't do any harm by providing those by default. Not 
sure yet if we should make them optional.)
  To achieve this, I have slightly refactored FreemarkerServlet in the areas of 
TaglibFactory building and too tight dependency on FreemarkerServlet in session 
model (by changing it to GenericServlet, so that can be used in the spring 
module as well).

TODOs:
- See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
hard coded into ViewResolverRegistry, which we can't modify)
- Consider better "custom directives/methods" for templating in spring env.
- Integration testing in a simple web application module?

> FM3 freemarker-spring module, Web MVC support
> -
>
> Key: FREEMARKER-55
> URL: https://issues.apache.org/jira/browse/FREEMARKER-55
> Project: Apache Freemarker
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Daniel Dekany
>
> Add Spring "Web MVC framework" functionality to freemarker-spring.
> This can be complex task (and the issue possibly has to be subdivided), as it 
> involves things like:
> * Some aspects of the FreeMarker 2 integration (developed by the Spring 
> developers) are quite confusing ({{FreemarerConfigurer}}, etc.), and we are 
> looking into if it needs to be like that.
> * 

[jira] [Comment Edited] (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

2017-07-03 Thread Woonsan Ko (JIRA)

[ 
https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073099#comment-16073099
 ] 

Woonsan Ko edited comment on FREEMARKER-55 at 7/4/17 4:41 AM:
--

Initial pull request submitted:
- https://github.com/apache/incubator-freemarker/pull/25

This initial pull request contains the following:
- FreemarkerView and FreemarkerViewResolver. So, it is now possible to use this 
new view and resolver with the ConfigurationFactoryBean, I think, with a 
configuration like the following:
{code}
  

  

  

  
UTF-8
true
strong:20, soft:250
 
   
   
  


  


  

  

  
{code}
- So, we don't need something like {{FreeMarkerConfigurer}} which is referred 
to implicitly by type in spring lib, but the view resolver should be configured 
with a {{Configuration}} explicitly.
- As {{FreeMarkerViewResolver}} extends {{AbstractTemplateViewResolver}} of 
spring, I believe the existing macros of spring should be supported as-is. I 
didn't verify this though.
- Still we will probably need to consider how we can provide better "custom 
directives/methods" for templating in spring env than the existing ones in 
spring lib.
- FreemarkerViewResolver exposes servlet context model, request 
attribute/parameter models, session model and JSP TaglibFactory,  by default, 
like FreemarkerServlet does.
  (I just thought it wouldn't do any harm by providing those by default. Not 
sure yet if we should make them optional.)
  To achieve this, I have slightly refactored FreemarkerServlet in the areas of 
TaglibFactory building and too tight dependency on FreemarkerServlet in session 
model (by changing it to GenericServlet, so that can be used in the spring 
module as well).

TODOs:
- See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
hard coded into ViewResolverRegistry, which we can't modify)
- Consider better "custom directives/methods" for templating in spring env.
- Integration testing in a simple web application module?


was (Author: woon_san):
Initial pull request submitted:
- https://github.com/apache/incubator-freemarker/pull/25

This initial pull request contains the following:
- FreemarkerView and FreemarkerViewResolver. So, it is now possible to use this 
new view and resolver with the ConfigurationFactoryBean, I think, with a 
configuration like the following:
{code}
  

  

  

  
UTF-8
true
strong:20, soft:250
 
   
   
  


  


  

  

  
{code}
- So, we don't need something like {{FreeMarkerConfigurer}} which is referred 
to implicitly by type in spring lib, but the view resolver should be configured 
with a {{Configuration}} explicitly.
- As {{FreeMarkerViewResolver}} extends {{AbstractTemplateViewResolver}} of 
spring, I believe the existing macros of spring should be supported as-is. I 
didn't verify this though.
- Still we will probably need to consider how we can provide better "custom 
directives/methods" for templating in spring env than the existing ones in 
spring lib.
- FreemarkerViewResolver exposes servlet context model, request 
attribute/parameter models, session model and JSP TaglibFactory,  by default, 
like FreemarkerServlet does.
  (I just thought it wouldn't do any harm by providing those by default. Not 
sure yet if we should make them optional.)

TODOs:
- See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
hard coded into ViewResolverRegistry, which we can't modify)
- Consider better "custom directives/methods" for templating in spring env.
- Integration testing in a simple web application module?

> FM3 freemarker-spring module, Web MVC support
> -
>
> Key: FREEMARKER-55
> URL: https://issues.apache.org/jira/browse/FREEMARKER-55
> Project: Apache Freemarker
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Daniel Dekany
>
> Add Spring "Web MVC framework" functionality to freemarker-spring.
> This can be complex task (and the issue possibly has to be subdivided), as it 
> involves things like:
> * Some aspects of the FreeMarker 2 integration (developed by the Spring 
> developers) are quite confusing ({{FreemarerConfigurer}}, etc.), and we are 
> looking into if it needs to be like that.
> * See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
> hard coded into {{ViewResolverRegistry}}, which we can't modify)
> * Creating custom directives/methods to expose Spring features like the 
> Spring JSP Tag Library does (but in a way that firs FreeMarker better)
> * Expose JSP custom tag support from the {{freemarker-servlet}} module.
> Depends on: FREEMARKER-54



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (FREEMARKER-55) FM3 freemarker-spring module, Web MVC support

2017-07-03 Thread Woonsan Ko (JIRA)

[ 
https://issues.apache.org/jira/browse/FREEMARKER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073099#comment-16073099
 ] 

Woonsan Ko commented on FREEMARKER-55:
--

Initial pull request submitted:
- https://github.com/apache/incubator-freemarker/pull/25

This initial pull request contains the following:
- FreemarkerView and FreemarkerViewResolver. So, it is now possible to use this 
new view and resolver with the ConfigurationFactoryBean, I think, with a 
configuration like the following:
{code}
  

  

  

  
UTF-8
true
strong:20, soft:250
 
   
   
  


  


  

  

  
{code}
- So, we don't need something like {{FreeMarkerConfigurer}} which is referred 
to implicitly by type in spring lib, but the view resolver should be configured 
with a {{Configuration}} explicitly.
- As {{FreeMarkerViewResolver}} extends {{AbstractTemplateViewResolver}} of 
spring, I believe the existing macros of spring should be supported as-is. I 
didn't verify this though.
- Still we will probably need to consider how we can provide better "custom 
directives/methods" for templating in spring env than the existing ones in 
spring lib.
- FreemarkerViewResolver exposes servlet context model, request 
attribute/parameter models, session model and JSP TaglibFactory,  by default, 
like FreemarkerServlet does.
  (I just thought it wouldn't do any harm by providing those by default. Not 
sure yet if we should make them optional.)

TODOs:
- See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
hard coded into ViewResolverRegistry, which we can't modify)
- Consider better "custom directives/methods" for templating in spring env.
- Integration testing in a simple web application module?

> FM3 freemarker-spring module, Web MVC support
> -
>
> Key: FREEMARKER-55
> URL: https://issues.apache.org/jira/browse/FREEMARKER-55
> Project: Apache Freemarker
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Daniel Dekany
>
> Add Spring "Web MVC framework" functionality to freemarker-spring.
> This can be complex task (and the issue possibly has to be subdivided), as it 
> involves things like:
> * Some aspects of the FreeMarker 2 integration (developed by the Spring 
> developers) are quite confusing ({{FreemarerConfigurer}}, etc.), and we are 
> looking into if it needs to be like that.
> * See if we can support {{@EnableWebMvc}} (note that FreeMarker 2 support is 
> hard coded into {{ViewResolverRegistry}}, which we can't modify)
> * Creating custom directives/methods to expose Spring features like the 
> Spring JSP Tag Library does (but in a way that firs FreeMarker better)
> * Expose JSP custom tag support from the {{freemarker-servlet}} module.
> Depends on: FREEMARKER-54



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (FREEMARKER-54) FM3 freemareker-spring module, basic functionality

2017-06-18 Thread Woonsan Ko (JIRA)

[ 
https://issues.apache.org/jira/browse/FREEMARKER-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053439#comment-16053439
 ] 

Woonsan Ko edited comment on FREEMARKER-54 at 6/19/17 4:54 AM:
---

Thanks for the pointer! I've corrected the following:
- {{#setSettings(Map)}} was removed as {{#setSetting(Properties)}} is totally 
fine in spring (ref: bean definition example in commented block in unit test).
- Corrected logging in {{SpringResourceTemplateLoader}}.
- Added {{VersionEditor}} for Spring because it's more convenient to set by 
string in XML bean definitions. (See "FooEditor" example in \[1\] for 
reference.)
- Added {{baseLocation}} property in {{SpringResourceTemplateLoader}} for 
convenience.

Since this PR includes {{VersionEditor}} in core, please take a review.

Regards,

Woonsan

\[1\] 
https://docs.spring.io/spring/docs/current/spring-framework-reference/html/validation.html#beans-beans-conversion


was (Author: woon_san):
Thanks for the pointer! I've corrected the following:
- {{#setSettings(Map)}} was removed as {{#setSetting(Properties)}} is totally 
fine in spring (ref: bean definition example in commented block in unit test).
- Corrected logging in {{SpringResourceTemplateLoader}}.
- Added {{VersionEditor}} for Spring because it's more convenient to set by 
string in XML bean definitions. (See "FooEditor" example in \[1\] for 
reference.)

Since this PR includes {{VersionEditor}} in core, please take a review.

Regards,

Woonsan

\[1\] 
https://docs.spring.io/spring/docs/current/spring-framework-reference/html/validation.html#beans-beans-conversion

> FM3 freemareker-spring module, basic functionality
> --
>
> Key: FREEMARKER-54
> URL: https://issues.apache.org/jira/browse/FREEMARKER-54
> Project: Apache Freemarker
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Daniel Dekany
>
> Create the Gradle module. Basic non-Web functionality. This certainly means:
> * Creating a FactoryBean by extending {{Configuration.ExtendableBuilder}} 
> which has defaults that are practical for Spring.
> * Creating a {{SpringResourceTemplateLoader}} which relies on Spring's 
> {{Resource}} abstraction
> It's also an important goal to polish the {{freemarker-core}} configuration 
> and template loader API-s, and change them if that's needed for smoother 
> Spring integration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (FREEMARKER-54) FM3 freemareker-spring module, basic functionality

2017-06-17 Thread Woonsan Ko (JIRA)

[ 
https://issues.apache.org/jira/browse/FREEMARKER-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053066#comment-16053066
 ] 

Woonsan Ko commented on FREEMARKER-54:
--

I've just opened a pull request for initial reviews. It contains (a) 
FactoryBean by extending Configuration.ExtendableBuilder and (b) 
SpringResourceTemplateLoader at the moment.
However, I didn't give enough consideration on the following yet:
- "defaults that are practical for Spring"
- "polish the freemarker-core configuration and template loader API-s"
I'd like to polish more about those two points with this PR.

> FM3 freemareker-spring module, basic functionality
> --
>
> Key: FREEMARKER-54
> URL: https://issues.apache.org/jira/browse/FREEMARKER-54
> Project: Apache Freemarker
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Daniel Dekany
>
> Create the Gradle module. Basic non-Web functionality. This certainly means:
> * Creating a FactoryBean by extending {{Configuration.ExtendableBuilder}} 
> which has defaults that are practical for Spring.
> * Creating a {{SpringResourceTemplateLoader}} which relies on Spring's 
> {{Resource}} abstraction
> It's also an important goal to polish the {{freemarker-core}} configuration 
> and template loader API-s, and change them if that's needed for smoother 
> Spring integration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (FREEMARKER-1) Option to not to overwrite response ContentType in FreemarkerServlet

2015-10-17 Thread Woonsan Ko (JIRA)

[ 
https://issues.apache.org/jira/browse/FREEMARKER-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14962138#comment-14962138
 ] 

Woonsan Ko commented on FREEMARKER-1:
-

Both totally make sense to me! Thanks a lot for caring about the cases I didn't 
think about!

Cheers,

Woonsan

> Option to not to overwrite response ContentType in FreemarkerServlet
> 
>
> Key: FREEMARKER-1
> URL: https://issues.apache.org/jira/browse/FREEMARKER-1
> Project: Apache Freemarker
>  Issue Type: Improvement
>Reporter: Woonsan Ko
>Assignee: Daniel Dekany
>Priority: Minor
>
> FreemarkerServlet doesn't have to set response ContentType by default. 
> Especially when a controller in an MVC framework sets the response 
> ContentType, it's better to not set the response ContentType again by the 
> default ContentType setting in FreemarkerServlet according to servlet 
> specification (SRV.5.2 and SRV.14.2.22.1):
> {quote}
> Servlet programmers are responsible for ensuring that the Content-Type header 
> is appropriately set in the response object for the content the servlet is 
> generating. The HTTP 1.1 specification does not require that this header be 
> set in an HTTP response. Servlet containers must not set a default content 
> type when the servlet programmer does not set the type.
> {quote}
> {quote}
> ServletResponse#getContentType() should "Returns the content type used for 
> the MIME body sent in this response. The content type proper must have been 
> specified using setContentType(String) before the response is committed. If 
> no content type has been specified, this method returns null. If a content 
> type has been specified and a character encoding has been explicitly or 
> implicitly specified as described in getCharacterEncoding() , the charset 
> parameter is included in the string returned. If no character encoding has 
> been specified, the charset parameter is omitted.
> Returns: a String specifying the content type, for example, text/html; 
> charset=UTF-8, or null
> Since: 2.4
> {quote}
> So, optionally, if #getContentType() returns null, then FreemarkerServlet can 
> detect that the Content-Type was never set before.
> Actually, frameworks or containers don't have to set Content-Type if 
> programmers don't. However, I think setting Content-Type header in the 
> framework level (freemarker servlet in this case) to a reasonable default 
> value seems fine.
> Daniels's remarks/suggestions on this in the old ML:
> {quote}
> The contentType matter... thanks for looking after these! So then, 
> FreemarkerServlet surely should set the HttpServletResponse contentType when 
> it's still null. OTOH there should be an option to only set it then (if it's 
> not null), not always as it happens now. So then the "ContetType" init-param 
> remains as is, and we add a new init-param, "OverrideResponseContentType" 
> (better name?), whose default is true for backward compatibility, but this 
> default can be changed to false by extending FreemarkerServlet. WDYT?
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)