Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Feb 16, 2007 · 8 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Feb 16, 2007

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:

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

3 votes, 11 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 20, 2007

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 29, 2007

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 6, 2007

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 12, 2007

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 13, 2007

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 13, 2007

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 13, 2007

Tim Chen commented

so close ;) 2.0.1

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 22, 2015

Juergen Hoeller commented

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants