<p dir="auto"><strong><a href="https://jira.spring.io/secure/ViewProfile.jspa?name=david_syer" rel="nofollow">Dave Syer</a></strong> opened <strong><a href="https://jira.spring.io/browse/SPR-4855?redirect=false" rel="nofollow">SPR-4855</a></strong> and commented</p>
<p dir="auto">Migrate Repeat and Retry from Spring Batch.  They are almost completely self-contained now (on trunk), so it shouldn't be a tough job - just need to decide where to put them.  Maybe the tests might have some batch dependencies, but they would be easily factored out.  There is also a dependency on some utility stuff in org.springframework.batch.support which would need to be moved over or equivalents provided in core.</p>
<p dir="auto">The only real work will be migrating the StatefulRetryOperationsInterceptor (very useful).  It currently depends on ItemKeyGenerator and NewItemIdentifier, for good reasons, so equivalents will have to be provided.  When this is refactored it might also be a good idea to revisit the whole stateful retry concept - it could be implemented as an extension of the RetryOperations interface instead of through a callback / policy pairing as it is now.</p>
<hr>
<p dir="auto"><strong>Affects:</strong> 2.5.4</p>
<p dir="auto"><strong>Issue Links:</strong></p>
<ul dir="auto">
<li><a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="398117592" data-permission-text="Title is private" data-url="https://github.com/spring-projects/spring-framework/issues/13808" data-hovercard-type="issue" data-hovercard-url="/spring-projects/spring-framework/issues/13808/hovercard" href="https://github.com/spring-projects/spring-framework/issues/13808">#13808</a> Consider moving Spring Batch Retry package into Spring Core (<em><strong>"is duplicated by"</strong></em>)</li>
</ul>
<p dir="auto">1 votes, 3 watchers</p>
<p dir="auto"><strong><a href="https://jira.spring.io/secure/ViewProfile.jspa?name=samokk" rel="nofollow">Sami Dalouche</a></strong> opened <strong><a href="https://jira.spring.io/browse/SPR-2578?redirect=false" rel="nofollow">SPR-2578</a></strong> and commented</p>
<p dir="auto">According to the documentation (<a href="http://static.springframework.org/spring/docs/2.0.x/reference/transaction.html#transaction-declarative-annotations" rel="nofollow">http://static.springframework.org/spring/docs/2.0.x/reference/transaction.html#transaction-declarative-annotations</a>), Annotating interface "IFoo" using <code class="notranslate">@Transactional</code> is supposed to affect the implementations of implementations of "IFoo".</p>
<p dir="auto">This is the case when using Interface-based proxying, but does not work when using CGLIB proxies.</p>
<p dir="auto">This issue is easy to reproduce.. Just take any IFoo, set it <code class="notranslate">@Transactional</code>, create a class that implements IFoo, and use the following in the spring appContext.xml :</p>
<hr>
<p dir="auto"><strong>Affects:</strong> 2.0 RC3</p>
<p dir="auto"><strong>Issue Links:</strong></p>
<ul dir="auto">
<li><a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="398070183" data-permission-text="Title is private" data-url="https://github.com/spring-projects/spring-framework/issues/7211" data-hovercard-type="issue" data-hovercard-url="/spring-projects/spring-framework/issues/7211/hovercard" href="https://github.com/spring-projects/spring-framework/issues/7211">#7211</a> Semantics affected - tx:annotation-driven, proxy-target-class and <code class="notranslate">@Transactional</code> on interface (<em><strong>"duplicates"</strong></em>)</li>
</ul>