Make warp-persist more extensible

[GoogleCodeExporter]

This is a patch to make warp-persist a bit more extensible in terms of what
kinds of persistence frameworks it can be used for as described in this
group thread <http://groups.google.com/group/warp-core/t/c74dab2449df234d>.

It maintains backwards compatibility with previous versions of warp-persist
while allowing users to provide their own ways of specifying a persistence
module doing something like the following:

                PersistenceService.using(new HibernatePersistModule())
                    .across(UnitOfWork.REQUEST)
                    .transactedWith(TransactionStrategy.LOCAL)
                    .forAll(Matchers.any())
                    .buildModule();

To do this, the PersistenceModule wraps the passed in PersistModule and
calls the configure(Binder) method to allow the PersistModule to setup its
bindings.  The PersistenceModule then gets the transaction interceptor and
finder interceptor from the PersistModule and binds them accordingly.

This changeset limits the number of changes to adding new
using(PersistModule) method and the PersistModule interface.  Please review
and let me know if you'd like me to make any further modifications.

Rich

Original issue reported on code.google.com by rwallace...@gmail.com on 13 Apr 2008 at 10:03

Attachments:

• warp-persist.patch

[GoogleCodeExporter]

Original comment by dha...@gmail.com on 14 Apr 2008 at 4:26

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Don't forget: we also need to support WorkManager. I am thinking about 
providing a "custom" SPR filter out of 
the box (that way it can maintain its package local static hooks) which simply 
delegates to the work manager that 
a user can provide.

I wish I had thought of this before, then we could have shipped just the one 
SPR filter for all frameworks. =(

Original comment by dha...@gmail.com on 14 Apr 2008 at 4:48

[GoogleCodeExporter]

I'm not sure I'm following you.  Are you suggesting we have a single SPR servlet
filter that gets injected with the appropriate WorkManager and simply uses that
instead of having a separate SPR filter for each type of persistence mechanism? 
 I
think that's a great idea, I'm just wondering how to get the WorkManager into 
the
filter.  Naturally we could just use Guice to inject it and tell people you 
need to
either use guice-servlet or, preferably, warp-servlet to get it properly 
injected.

Along the same line, do you think the session management parts of the 
transaction
interceptors should be pulled out into a single separate session interceptor 
that
uses the WorkManager as well?

Then, if the transaction strategy is REQUEST we don't bind the interceptor but 
it is
on the user to make sure the SPR filter is configured properly?  Otherwise, we 
bind
the session interceptor before the transaction interceptor so sessions get 
opened and
closed properly?

Original comment by rwallace...@gmail.com on 14 Apr 2008 at 6:09

[GoogleCodeExporter]

In that last paragraph of my last comment, it should be "Then, if the unit of 
work is
REQUEST".  Seems I got a bit discombobulated for a second. ;)

Original comment by rwallace...@gmail.com on 14 Apr 2008 at 6:33

[GoogleCodeExporter]

Yes a single filter which we ship (Work managed can be looked up 
thread-locally). But we can't do this right now, 
maybe for the custom extensions.

I don't think there are arbitrary session strategies (we cover most of them) 
and workmanager can be used to 
make more of them (there isn't much to handle in the way of commit/rollback).

Is this the latest patch for this issue?

Original comment by dha...@gmail.com on 17 Apr 2008 at 9:04

[GoogleCodeExporter]

Ok.  I see what you mean now.  Yes, this is the latest patch for the issue.

Original comment by rwallace...@gmail.com on 17 Apr 2008 at 12:39

[GoogleCodeExporter]

project: warp-persisi + struts2.

module:

        binder.bindConstant().annotatedWith(JpaUnit.class).to("restTest");

        binder.install(PersistenceService
                .usingJpa()
                .across(UnitOfWork.REQUEST)
                .transactedWith(TransactionStrategy.LOCAL)
                .buildModule());

        //start persistence service 
        binder.bind(InitializerJpa.class).asEagerSingleton();

database connect is close... why ?

Original comment by xinfeng999@gmail.com on 28 Apr 2008 at 4:15

[GoogleCodeExporter]

Hello,

Are you using the SessionPerRequestFilter? This will cause problems with 
struts2 as there is a bug in the 
struts2-guice plugin. You will need to customize a Struts2 interceptor to run 
properly. Described in this 
book: http://www.apress.com/book/view/9781590599976

Or you can try to use UnitOfWork.TRANSACTION (and remove the SPRfilter).

Dhanji.

PS: please post bug questions on the mailing list rather than the issues 
register--thanks!

Original comment by dha...@gmail.com on 29 Apr 2008 at 1:57

[GoogleCodeExporter]

The single SPR filter is going to happen. The existing ones can subclass that 
one for
backwards compatibility.

The extensibility is also possible in the current trunk, if we add:
using(Class<? extends PersistenceStrategy> ps)
and
using(PersistenceStrategy strategy)

I'm not entirely convinced yet that we should add this, though.

Original comment by robbie.v...@gmail.com on 22 Aug 2008 at 1:27

[GoogleCodeExporter]

We could probably make it a separate method, something like usingCustom(...)

Original comment by dha...@gmail.com on 22 Aug 2008 at 10:45

[GoogleCodeExporter]

Current trunk has a using(PersistenceStrategy ps)

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

• Changed state: Fixed

[GoogleCodeExporter]

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

• Added labels: Milestone-Release2.0