Annotation-bound modules support for @Transactional

[GoogleCodeExporter]

 Much like we have in the trunk for DF now: @UserAnnotation @Transactional.

Original issue reported on code.google.com by robbie.v...@gmail.com on 20 Aug 2008 at 11:52

[GoogleCodeExporter]

@Transactional(unit=UserAnnotation.class) currently in trunk.

Original comment by robbie.v...@gmail.com on 23 Aug 2008 at 12:04

• Changed state: Started

[GoogleCodeExporter]

We should probably make our custom matchers public.

Original comment by robbie.v...@gmail.com on 8 Sep 2008 at 4:52

[GoogleCodeExporter]

Yea good call. Let's put it in c.w.w.p.Matchers

Original comment by dha...@gmail.com on 9 Sep 2008 at 12:03

[GoogleCodeExporter]

Done.

Original comment by robbie.v...@gmail.com on 9 Sep 2008 at 9:47

• Changed state: Fixed

[GoogleCodeExporter]

By the way, this has changed to PersistenceMatchers because of the naming 
conflict
with Guice.

Original comment by robbie.v...@gmail.com on 22 Dec 2008 at 2:28

• Added labels: Milestone-Release2.0

[GoogleCodeExporter]

Hmm, we dont really need unit= for the SPR case. I wonder if it would be easy 
to put that foot forward and fall 
back to the single nameless module for UOW.TRANSACTION?

Original comment by dha...@gmail.com on 23 Dec 2008 at 5:39

[GoogleCodeExporter]

Can you explain? You mean we could do filtering in the transaction interceptor 
based 
on a ThreadLocal or something? In any case, regular modules are still 
supported. The 
downside is that we can't easily check that people aren't screwing up. For 
example if 
they create one annotated module and one regular module the regular module's 
interceptor will also intercept the annotated module's @Transactionals. 
Interesting, 
maybe we can actually detect that in the interceptor.

The default forAll configuration just matches on @Transactional and not on the 
unit; 
this allows for easier migration from annotated to 1.0-style, but we could also 
solve 
the above problem by always checking on the unit (there is a default unit). But 
then 
we should put a huge warning sign on forAll, because the defaults will use 
nonstandard matchers.

Thoughts?

Original comment by robbie.v...@gmail.com on 23 Dec 2008 at 11:38

[GoogleCodeExporter]

I think we should do it, match on DefaultUnit by default. Then the docs must 
state 
that there is an implicit DefaultUnit, which is not visible in the bindings but 
is 
used for interception. So @Transactional will mean 
@Transaction(unit=DefaultUnit.class) (this is currently already true because we 
needed a default).

Original comment by robbie.v...@gmail.com on 23 Dec 2008 at 11:50