PropertyPlaceholderConfigurer does not work with namespace declarations. [SPR-3180]

[spring-projects-issues]

Tim Chen opened SPR-3180 and commented

I have a PropertyPlaceholderConfigurer that is prefixed with #{
I can use it for any spring definition except those that are using namespaces.
For example:
Code:

<tx:advice id="txAdvice" transaction-manager="jtaTxManager">
    <tx:attributes>
        <tx:method name="*" propagation="REQUIRED" timeout="#{operational:jtaTimeout}"/>
    </tx:attributes>
</tx:advice>

It wont process the value and I get exceptions that the value must be an integer.
How can I use PropertyPlaceholderConfigurer with namespaces?

The forum link is http://forum.springframework.org/showthread.php?p=101823#post101823

---

Affects: 2.0.2

Issue Links:

• PropertyPlaceholderConfigurer doesn't work on beans defined in own schema e.g. tx:* [SPR-4847] #9523 PropertyPlaceholderConfigurer doesn't work on beans defined in own schema e.g. tx:* ("is duplicated by")

3 votes, 11 watchers

[spring-projects-issues]

Alef Arendsen commented

Essentially, this is a limitation in the namespaces support and the normal mechanism of installing a PropertyPlaceholderConfigurer will not work here. As Mark correctly points out in the forum thread, the XML will simply not parse because it doesn't adhere to the schema.

Furthermore there's no way I can think of (or that I'm aware of I should say) that allows us to intervene before the namespaces get transformed into actual Spring configuration.

I'm moving this to 2.1 and changing it into an improvement. Maybe we'll be able to come up with an alternative to the PropertyPlaceholderConfigurer for these kinds of scenarios.

[spring-projects-issues]

Juergen Hoeller commented

Actually, PropertyPlaceholderConfigurer does kick in for namespace-generated beans as well, provided that the namespace handler does not build 'hard-configured' instances already - which is exactly what the tx:advice tag does.

The problem here is that the namespace declares strongly typed attributes: 'timeout' needs to be of type int, 'read-only' needs to be of type boolean. This doesn't allow for placeholders simply because those would be Strings, not even accepted by the XML parser!

The tradeoff is that we can only allow for placeholders there by giving up the strong typing of attributes. I'm not sure whether that's worth it... since an important goal of XML schema namespaces is exactly the ability to define strongly typed attributes.

Juergen

[spring-projects-issues]

Tim Chen commented

So this is a bug for the tx:advice namespace handler then?
Is there a work around for now?

[spring-projects-issues]

Juergen Hoeller commented

Well, the problem is in the spring-tx XSD file: It declares those attributes with specified types such as int, hence the XML parser doesn't accept expressions there. If we change those to type String, expressions would work, but we'll lose the type safety in the XML validation process...

So for the time being, the alternative would be to use a plain TransactionInterceptor bean definition instead of tx:advice, passing in the transaction attributes via the "transactionAttributes" bean property there (similar to the traditional TransactionProxyFactoryBean style). Note that aop:config can point to such a TransactionInterceptor bean as well, just like you currently do for tx:advice!

Note that JtaTransactionManager has a "defaultTimeout" property. You might use that one for a custom timeout that is supposed to apply to all your transactions, instead of specifying it for each transaction attribute individually. Since JtaTransactionManager will always be defined as plain bean, placeholders can be used without restrictions there.

Juergen

[spring-projects-issues]

Tim Chen commented

Thank you Juergen. That is what I expected so that is what I did (manually defining the transaction beans). Unfortunately the version of Spring that I am using does not support a setter for the default timeout on the JtaTransactionManager as I was looking into that as well.
You make good points about the benefits of allowing strongly typed attributes but I would think that for flexibility and adaptiveness it would be better to allow this behavior.

[spring-projects-issues]

Juergen Hoeller commented

Actually, "defaultTimeout" was introduced in Spring 2.0.2... which you seem to be using. Note that the actual property is in AbstractPlatformTransactionManager, just inherited by JtaTransactionManager.

Juergen

[spring-projects-issues]

Tim Chen commented

so close ;) 2.0.1

[spring-projects-issues]

Juergen Hoeller commented

Closing groups of outdated issues. Please reopen if still relevant.