Nikolaos,

On Thu, May 27, 2010 at 6:35 PM, Nikolaos Giannopoulos
<nikol...@brightminds.org> wrote:
> Frank Pavageau wrote:
>> On Thu, May 27, 2010 at 5:23 PM, Nikolaos Giannopoulos
>> <nikol...@brightminds.org> wrote:
>>
>>>    public class BaseActionBean implements ActionBean {
>>>       �...@springbean  protected ModalityDao modalityDao;
>>>        ...
>>>
>>>   �...@repository("modalityDao")
>>>    public class ModalityDaoImpl extends BaseDaoImpl<Modality, Integer>
>>> implements ModalityDao {
>>>        public List<Modality> findAll() {
>>>            return (this.load());  // [2]
>>>        }
>>>       �...@postconstruct
>>>        private void init() {
>>>            this.findAll();   // [1]
>>>        }
>>>
> <snip>
>> The problem is that you have objects instanciated by the 2 frameworks
>> with independent lifecycles :
>> - Spring instanciates the DAO at context initialization (triggered by
>> the listener)
>> - Stripes instanciates the Stripersist interceptor at filter
>> initialization, and the Spring context knows nothing about it
>>
> Sure.  I get that.
>
>> You don't really need to use the Stripersist interceptor in your
>> BaseDaoImpl, you just want the EntityManagerFactory injected directly
>> instead. Stripersist also gets it from the Spring context anyway
>> (AFAIR, we use our own TypeConverter with a similar mechanism).
>>
> 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. 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.

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.

Or you can replace the listener used to bootstrap Spring by a custom
filter instanciating the context, also running after Stripes' filter.

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.

Frank

------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Reply via email to