Issue 1:
Mario Alcaraz opened SPR-3272 and commented

JSTL variables named "status" defined before a binding tag can interfere with "status" binding variable. This issue has been reported as http://opensource.atlassian.com/projects/spring/browse/SPR-1140 and fixed on version 1.2.3. Applications developed with 1.2.7 can cope with this but after migrating to 2.0.x setting a variable with named "status" at the page context would throw a ClassCastException inside body tag. It appears this bug has been introduce in http://opensource.atlassian.com/projects/spring/browse/SPR-2166 . A workaround would be to define JSTL variables named "status" in the request context to allow #5843 to take effect, or change their name.

I'm currently working in a patch I'll soon attached to this Issue.

Affects: 1.2.8, 2.0 final, 2.0.1, 2.0.2, 1.2.9, 2.0.3

Attachments:

bindtest.zip (6.45 kB)

patch.txt (2.30 kB)

Issue 2:
Ben Rowlands opened SPR-3311 and commented

To implement a custom local transaction manager we'd like to listen to what Spring is enlisting in the transaction. We don't use a distributed transaction manager or 2PC but instead use a local transaction manager that orders items in 'best-efforts' order and does single-phase commit.

If we could listen to the TransactionSynchronizationManager we could reuse all of Springs current transaction support/integration to handle transaction resource management (using the Spring strategy of binding resources to the thread-local, ie in DataSourceUtils).

In our implementation when the listeners are fired we update our list of transaction items so we can track the order in which items need to be committed (we commit the initiating transaction item last, typically this is the messaging resource so in the event of failure the message is rolled back and replayed - a limitation of this strategy is potential duplicate messages but no lost messages, however it is much simpler than using 2PC and distributed transaction manager and avoids the management overhead).

An additional complexity is the implementation of Savepoints; we take a snapshot of the synchronizations and resources bound to the transaction when the savepoint is created and restore this state when we rollback to a savepoint (we rollback any resources added after the savepoint was created). If we could listen to the TransactionSynchronizationManager we could achieve this by tracking any new synchronizations/resources added after a savepoint was created and then remove them upon rollback of the savepoint.

For example:

public interface TransactionSynchronizationManagerListener

{

public void resourceBound( Object key, Object resource );

public void resourceUnbound( Object key, Object resource );

public void synchronizationRegistered( TransactionSynchronization synchronization );

public void synchronizationUnregistered( TransactionSynchronization synchronization );

}

With API to register a listener for the current thread (and clear).

TransactionSynchronizationManager#setListener( TransactionSynchronizationManagerListener listener )

To handle the savepoint issue (i.e., shrink list of synchronizations to the state they were before the savepoint) an API to selectively remove synchronizations would be ideal:

TransactionSynchronizationManager#unregisterSynchronization( TransactionSynchronization synchronization )

Issue Links:

#9710 Add extension to TransactionSynchronizationManager to allow custom resolution of unbound transaction resources to allow "lazy-enlistment" TransactionManagers

13 votes, 19 watchers