You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Michael Wyraz <mi...@evermind.de> on 2014/06/06 15:20:13 UTC
TAP5-2176,SymbolBeanFactoryPostProcessor breaks property placeholder
in spring when using default values
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.wyraz@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
Re: TAP5-2176,SymbolBeanFactoryPostProcessor breaks property placeholder
in spring when using default values
Posted by Michael Wyraz <mi...@evermind.de>.
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
> <mi...@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.wyraz@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
Re: TAP5-2176,SymbolBeanFactoryPostProcessor breaks property
placeholder in spring when using default values
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
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
<mi...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: TAP5-2176,SymbolBeanFactoryPostProcessor breaks property placeholder
in spring when using default values
Posted by Michael Wyraz <mi...@evermind.de>.
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.wyraz@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org