Hi!
Thanks for investigating the issue.
Could you please provide a test case? The simpler, the getter. I haven't
used Spring for ages, so a test case would reduce the time spent fixing
this bug in Tapestry drastically.
On Fri, 06 Jun 2014 11:15:05 -0300, Michael Wyraz
<michael.wy...@evermind.de> wrote:
After looking in the spring code for placeholder resolution I found that
adding
setValueSeparator(null);
to the constructor solves the problem.
Also the method
protected String resolvePlaceholder(String placeholder, Properties
props)
{
try
{
return symbolSource.valueForSymbol(placeholder);
}
catch(RuntimeException e)
{
return super.resolvePlaceholder(placeholder, props);
}
}
Should be changed to
protected String resolvePlaceholder(String placeholder, Properties
props)
{
try
{
return symbolSource.valueForSymbol(placeholder);
}
catch(RuntimeException e)
{
return null;
}
}
This ensures that tapestry only adds it's own placeholders and does not
do some extra stuff (like replacing placeholders by system properties
and such) - if a user would like to do so, he should provide its own
PropertyPlaceholderConfigurer rather than rely on this side effect of
tapestry's SymbolBeanFactoryPostProcessor.
Hi,
I trapped into this issue:
https://issues.apache.org/jira/browse/TAP5-2176
"SymbolBeanFactoryPostProcessor breaks property placeholder in spring
when using default values".
My current workaround is to use a different "valueSeparator" for my own
PropertyConfigurer.
I'd like to provide a fix/patch for this issue but there are several
ways to do it which I'd like to discuss.
1. only resolve properties that begins with "tapestry." as suggested in
the bug
2. disable default-value validation by using a very uncommon
"valueSeparator" instead of the default ":"
3. wait that https://jira.spring.io/browse/SPR-9989 is fixed - probably
never ;-)
IMO 1 has the disadvantage that custom symbols cannot be used anymore
So I'd prefer 2 as a solution. Preventing
SymbolBeanFactoryPostProcessor to resolve ":" separated default values
is not a problem since every other configured
PropertyPlaceholderConfigurer in the context would to the job.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
