Frank Pavageau wrote:
Nikolaos,
On Thu, May 27, 2010 at 6:35 PM, Nikolaos Giannopoulos
<nikol...@brightminds.org> wrote:
Sorry. Now you lost me :-) Sounds great but what "exactly" are you
suggesting?
Actually, I remembered something false: Stripersist does not use
Spring, as Aaron pointed out. If it had, you would have declared an
EntityManagerFactoryBean in your Spring context, and you could have
injected the resulting EntityManagerFactory in the DAO.
Right. My Spring configuration is super minimal and sweet :-)
That is another reason I like Stripersist - it actually works remarkably
well.
However, after
reading on Sourceforge's svn the code in Stripersist, I see that
Stripersist creates its own EntityManagerFactories by parsing
persistence.xml, and it would be a bit of a shame to create another
set of factories with Spring; especially when your domain gets large,
a single factory takes some time to start, so doubling the startup
time wouldn't be ideal.
Precisely. It doesn't make sense. Either you use Stripersist or you
don't... and I choose to... :-)
In light of that, a solution might be to add another filter to your
web.xml, instanciated after Stripes' filter (and thus after
Stripersist's initialization), which would call your service's init()
method. You can even use a DelegatingFilter from Spring, so it has the
service injected. If you have multiple services to initialize, they
can all implement an interface to mark the need for initialization so
you get all the implementing services injected together.
Sounds like an interesting idea. I guess that could work but then the
Filter would do nothing on each request? And I would need to build some
sort of service registration / initialization. It should work but seems
a bit kludgy....
Or you can replace the listener used to bootstrap Spring by a custom
filter instanciating the context, also running after Stripes' filter.
This is the approach I am considering. If I did this then the
@PostConstruct would work fine and the service bean's would be fully
initialized once they become available... just feels more like OO in
that the init is internal and encapsulated...
However, regarding your other mail, I don't see how ordering the
initialization of the interceptors would solve anything, since
SpringInterceptor has nothing to do with Spring's initialization.
You are correct. Ordering the Interceptors would not work as Spring
doesn't initialize itself there anyways.
Thanks for the solution / options / thoughts...
--Nikolaos
------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
