[
https://issues.apache.org/jira/browse/FREEMARKER-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290009#comment-17290009
]
Gray edited comment on FREEMARKER-177 at 2/24/21, 3:19 PM:
-----------------------------------------------------------
I changed the return type to Properties in
[https://github.com/apache/freemarker/pull/74]
I extended Configuration and just changed getProperties() to return Properties
and this resolved the problem. setProperties(InputStream) wasn't a problem I
guess. That method should have been loadProperties(InputStream). I tend to
make sure that get and set methods are only getting/setting fields and not
doing processing as a rule.
Spring (really java.beans.PropertyDescriptor) wants there to be symmetry. Even
though you are returning Map and properties is a Map get-type.class !=
set-type.class.
> It's also surprising that after 10+ years this suddenly comes up.
No I've been putting up with this for a while now. I suspect others are as
well.
> it doesn't matter much if for how long something is deprecated. Removing it
>is still not backward compatible
Then why mark anything deprecated? The whole point of deprecated is indicate
that in a future release it will go away. If we never change any API then we
will always have to put up with bad decisions made in the past. See:
[https://www.iitk.ac.in/esc101/05Aug/tutorial/post1.0/converting/deprecation.html]
If you changed the return type then it would take someone like 3 minutes to fix
the compilation error in their code and it would allow Configuration to be used
with Spring.
was (Author: dig090):
I changed the return type to Properties in
[https://github.com/apache/freemarker/pull/74]
I extended Configuration and just changed getProperties() to return Properties
and this resolved the problem. setProperties(InputStream) wasn't a problem I
guess. That method should have been loadProperties(InputStream). I tend to
make sure that get and set are only setting fields.
Spring (really java.beans.PropertyDescriptor) wants there to be symmetry. Even
though you are returning Map and properties is a Map get-type.class !=
set-type.class.
> It's also surprising that after 10+ years this suddenly comes up.
No I've been putting up with this for a while now. I suspect others are as
well.
> it doesn't matter much if for how long something is deprecated. Removing it
>is still not backward compatible
Then why mark anything deprecated? The whole point of deprecated is indicate
that in a future release it will go away. If we never change any API then we
will always have to put up with bad decisions made in the past. See:
[https://www.iitk.ac.in/esc101/05Aug/tutorial/post1.0/converting/deprecation.html]
If you changed the return type then it would take someone like 3 minutes to fix
the compilation error in their code and it would allow Configuration to be used
with Spring.
> freemarker Configurable has a asymmetric settings get/set which causes spring
> failure
> -------------------------------------------------------------------------------------
>
> Key: FREEMARKER-177
> URL: https://issues.apache.org/jira/browse/FREEMARKER-177
> Project: Apache Freemarker
> Issue Type: Bug
> Affects Versions: 2.3.29
> Reporter: Gray
> Priority: Major
> Attachments: trace.txt
>
>
> When I try to configure freemarker.template.Configuration in spring, it
> throws the exception:
> {{Caused by: org.springframework.beans.FatalBeanException: Failed to obtain
> BeanInfo for class [freemarker.template.Configuration]; nested exception is
> java.beans.IntrospectionException: type mismatch between read and write
> methods}}
> The problem is that setSettings(...) takes a Properties and getSettings()
> returns a Map. The get has been deprecated forever. Can it please be
> fixed? The alternative is having to do some spring hackery.
> See: [https://github.com/apache/freemarker/pull/74]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
