Hi Thiago,
I have attached a testcase to the bug with 3 tests.
testSpringOnly creates a spring application context using only spring's
PropertyPlaceholderConfigurer
testSpringWithTapestry creates the same as above plus an instance of
SymbolBeanFactoryPostProcessor. This test fails because of TAP5-2176
testSpringWithTapestry_bugfix uses my fixed version of
SymbolBeanFactoryPostProcessor and succeeds.
I don't know how to integrate this testcases in tapestry-spring's tests.
You only need the first two tests.
I found out that simply setting valueSeparator to NULL is not sufficient
to solve the issue. If a symbol contains a default value (e.g.
${mysymbol:defaultvalue}) teh whole string "mysymbol:defaultvalue" is
resolved against SymbolSource which fails. So I put some more code into
"resolvePlaceholder()".
So what actually happens is (please add this to the javadoc of
SymbolBeanFactoryPostProcessor):
All placeholders are resolved against tapestry's SymbolSource. If a
placeholder contains a default value (e.g.
${mysymbol:mydefaultvalue}) the default value is removed from the
placeholder. If the placeholder cannot be resolved against
SymbolSource, it remains completely unchanged. So
${mysymbol:mydefaultvalue}) will be untouched if "mysymbol" is not
known by the symbol source. It will not be resolved to
"mydefaultvalue" (this behaviour changed with TAP5-2176 since
tapestry-5.4-beta-???).
If another PropertyPlaceholderConfigurer is configured in spring,
this one will resolve all remaining values including all default values.
Kind regards,
Michael.
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.
--
Mit freundlichen Grüßen / Kind regards
Michael Wyraz
evermind GmbH
Schorlemmerstraße 1
04155 Leipzig
Tel.: +49 (0)341-25 39 66 - 0
Fax: +49 (0)341-25 39 66 - 1
Funk: +49 (0)177-73 00 00 3
E-Mail: michael.wy...@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
