Issue 1:
Stéphane Nicoll opened SPR-7879 and commented

We experienced a threads leak using Spring's DMLC on JBoss 4.2.3. We configured our DMLC as follows:

<jms:listener-container
destination-type="queue"
concurrency="1"
connection-factory="connectionFactory"
destination-resolver="destinationResolver"
transaction-manager="jmsTransactionManager"
task-executor="jmsTaskExecutor">
<jms:listener destination="queue/A" ref="defaultListener"/>
</jms:listener-container>

After some investigations and the help of the support we figured out that the following configuration helped fixing our threads leak issue

<jms:listener-container
destination-type="queue"
concurrency="1"
connection-factory="connectionFactory"
destination-resolver="destinationResolver"
acknowledge="transacted"
task-executor="jmsTaskExecutor">
<jms:listener destination="queue/A" ref="defaultListener"/>
</jms:listener-container>

Our use case is that we have externalized basically the following:

The connection factory and destination resolver (in order to be able to connect to another 3rd party JMS broker)

The JmsTransactionManager, whether we want to enable XA support or not

In the first configuration, it's obvious it is easy to share the configuration of this listener container, just import a strategy that defines the 3 beans above and you're good (we have some kind of "profile" capability using naming conventions). The problem is that the second configuration is the only way to get a proper usage with JBoss (connection/threads leak).

I don't know how easy it would be but the JmsTrasanctionManager that I use is the following

<bean id="jmsTransactionManager" class="org.springframework.jms.connection.JmsTransactionManager">
<property name="connectionFactory" ref="connectionFactory"/>
</bean>

Couldn't we imagine a solution where the DMLC is smart enough to look at the transaction manager type and flip to the "acknowledge=transacted" mode? I understand the JMS API is related to the issue but reading the doc, it's hard to understand what would be the impact of each option.

Affects: 3.0.5

Issue Links:

#13838 Improve Javadocs for DMLC Regarding JmsTransactionManager ("duplicates")

Issue 2:
Daniel Fernández opened SPR-8963 and commented

IMHO, there is a mismatch between the configuration possibilities offered by XML and @Configuration classes in Spring 3.1, which could be fixed by allowing developers to create custom annotations that could be used in @Configuration classes (in the same way as @PropertySource) for performing pre-configured infrastructure tasks.

These annotations could perform these configuration tasks "underneath", hiding their complexities to Spring users, in the same way namespace handlers can in an XML file.

@PropertySource is the clear example to this, as it registers a PropertySource for the specified ".properties" files, but the object registered is of a specific class hard-coded into Spring's code. This avoids the possibility of creating instances of other implementations of the PropertySource interface that perform more complex processing of .properties entries.

Specifically, the jasypt project [ http://www.jasypt.org ] --of which I'm author-- defines an "encryption" XML namespace which allows developers to register an EncryptablePropertySource that performs automatic transparent decryption of properties with "encryption:encryptable-property-placeholder/", which works in a way equivalent to "context:property-placeholder/", but applying transparent decryption.

I would love to be able to offer this same easiness of configuration in @Configuration classes with an @EncryptablePropertySource annotation, but as it happens this is not possible :-(

Please, extend the @Configuration mechanism for allowing custom annotations (with their associated handlers).

Thanks.

Affects: 3.1 GA

Reference URL: http://forum.springsource.org/showthread.php?120147-Can-I-create-my-own-annotations-for-enabling-features-at-Configuration-classes

Issue Links:

#16732 Improve @PropertySource loading support ("is duplicated by")

#14865 Allow @PropertySource to be specified on a test class

#16004 Support declarative PropertySource annotations in the TestContext framework

SEC-3123 Encrypted property value support

#18447 Add support for UTF-8 and other charset/encoding to @PropertySource

#18574 convertPropertyValue (for reading encrypted values) not working

#16428 Custom @Profile annotations not working on @Configuration classes

#13568 PropertySourcesPlaceholderConfigurer never calls "convertProperties" on merged properties

#15294 Add encryption support for PropertyPlaceholderConfigurer

#17236 Backport encrypted property functionality from spring-cloud-config environment work

#18544 Allow a single element to override an array attribute in a meta-annotation

Referenced from: commits a378912

5 votes, 12 watchers