Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Based on what you've written in the meantime, this may not matter anymore,
but looking at the source code it looks to me like the interceptors do get
initialized in the order they're specified in web.xml. I haven't done much
with Spring, but when I have used it it was initialized with a
ServletContextListener, which executes before any filters or servlets are
initialized, according to the spec. So I think having Spring initialize
before filters are initialized, yet dependent on an interceptor that is
initialized in a filter, is the source of your problem. (Unless you're
initializing Spring some other way.)
You might try a Stripes Interceptor that doesn't actually intercept anything
(lacks @Intercepts) but initializes Spring in its init() method. Then the
order of the interceptor classes definitely would matter, but like I said
above, they'll initialize and execute in the specified order.
-Ben
On Thu, May 27, 2010 at 5:17 PM, Nikolaos Giannopoulos <
nikol...@brightminds.org> wrote:
> Ben,
>
> Actually I was thinking about what I wrote below and think maybe the PROPER
> solution is to have Stripes FIXED to enforce the ordering of classes in
> "Interceptor.Classes" w.r.t. "initialization" (in addition to the ordering
> already enforced for "execution").
>
> Would this be difficult to fix considering the ordering is already handled
> for execution
>
> I have a test bed ready to go :-) AND clearly this would be the "right"
> solution and I think an important more general fix for Stripes for other
> future scenarios as Developers leverage interceptors more and more this will
> become a necessity vs. a nice to have I suspect.
>
> Thanks,
>
> --Nikolaos
>
> P.S. If you can point me to the code that does the initialization I can
> take a look to see what I can provide
>
>
>
>
> Nikolaos Giannopoulos wrote:
>
> Aaron / Frank,
>
> While I realize I don't have to use Stripersist... I am quite happy with
> it... and instead of chucking it and doing some things by hand I am trying
> to figure out how I can make things work. I mean it is providing some
> benefit (we have MANY Entities and MANY DAOs) and while I agree that the
> EntityManagerFactory is something it indirectly leverages I would hope to
> find a way to make Stripersist work in this case... which I think is
> important.
>
> With that said I have clearly identified the problem by running all sorts
> of tests and debugging things.
>
> The Stripersist interceptor never gets a chance to initialize itself prior
> to the Spring interceptor no matter how I configure the web.xml and the
> ordering of Interceptor.classes appears to only apply to "execution"
> strictly - not in addition "initialization" - as some have suggested.
>
> Why is this a problem... because of the way Stripersist is coded... Spring
> ends up calling my @PostConstruct which in turn calls:
>
> protected List load(String persistenceUnitName) {
> return
> Stripersist.getEntityManager(persistenceUnitName).createQuery("from " +
> this.entityClass.getName()).getResultList();
>
> Which in turn calls:
>
> public static EntityManager getEntityManager(String persistenceUnit) {
> EntityManagerFactory factory =
> getEntityManagerFactory(persistenceUnit);
>
> Which in turn calls:
>
> public static EntityManagerFactory getEntityManagerFactory(String
> persistenceUnit) {
> return entityManagerFactories.get(persistenceUnit); // [1]
>
> and herein lies the problem... if Stripersist init() has not been called
> then the following static attribute is NULL
>
> static private Map
> entityManagerFactories;
>
> It is the lack of initialization of this attribute using information
> obtained by reading the persistence.xml, calling the Persistence class,
> etc... that is the problem.
>
> And to prove that... if we do the following in our @PostConstruct:
> Stripersist s = new Stripersist();
> s.init(StripesFilter.getConfiguration());
>
> List modalityList = this.modalityDao.findAll();
> this.modalityCache = new ModalityCache();
> this.modalityCache.init(modalityList);
>
> Stripersist spits up 2 exceptions about being accessed outside any request
> but now that the static attributes are initialized things work from here.
> Of course defensively placing this code that spews 2 exceptions in each
> service bean is not acceptable but it proves the point.
>
> Stripersist interceptor needs to be initialized BEFORE Spring interceptor
> and Stripes does NOT seem to offer a configurable way to force this.
>
> Does anyone know how I can create a wrapper to dynamically:
>
> --> Init and wire up Stripersist interceptor...
> followed by
> --> Init and wire up Spring interceptor
>
> I figure if I create a simple wrapper to force the ordering we should be in
> business.
>
> --Nikolaos
>
>
>
>
> Aaron Porter wrote:
>
> Hi Nikolaos,
> What Frank is saying is you don't have to go through Stripersist to get
> an EntityManager. The main purpos
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Frank Pavageau wrote: Nikolaos, On Thu, May 27, 2010 at 6:35 PM, Nikolaos Giannopoulos 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
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Nikolaos,
On Thu, May 27, 2010 at 6:35 PM, Nikolaos Giannopoulos
wrote:
> Frank Pavageau wrote:
>> On Thu, May 27, 2010 at 5:23 PM, Nikolaos Giannopoulos
>> wrote:
>>
>>> public class BaseActionBean implements ActionBean {
>>> �...@springbean protected ModalityDao modalityDao;
>>> ...
>>>
>>> �...@repository("modalityDao")
>>> public class ModalityDaoImpl extends BaseDaoImpl
>>> implements ModalityDao {
>>> public List findAll() {
>>> return (this.load()); // [2]
>>> }
>>> �...@postconstruct
>>> private void init() {
>>> this.findAll(); // [1]
>>> }
>>>
>
>> 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
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Ben,
Actually I was thinking about what I wrote below and think maybe the
PROPER solution is to have Stripes FIXED to enforce the ordering of
classes in "Interceptor.Classes" w.r.t. "initialization" (in addition to
the ordering already enforced for "execution").
Would this be difficult to fix considering the ordering is already
handled for execution
I have a test bed ready to go :-) AND clearly this would be the "right"
solution and I think an important more general fix for Stripes for other
future scenarios as Developers leverage interceptors more and more this
will become a necessity vs. a nice to have I suspect.
Thanks,
--Nikolaos
P.S. If you can point me to the code that does the initialization I can
take a look to see what I can provide
Nikolaos Giannopoulos wrote:
Aaron / Frank,
While I realize I don't have to use Stripersist... I am quite happy
with it... and instead of chucking it and doing some things by hand I
am trying to figure out how I can make things work. I mean it is
providing some benefit (we have MANY Entities and MANY DAOs) and while
I agree that the EntityManagerFactory is something it indirectly
leverages I would hope to find a way to make Stripersist work in this
case... which I think is important.
With that said I have clearly identified the problem by running all
sorts of tests and debugging things.
The Stripersist interceptor never gets a chance to initialize itself
prior to the Spring interceptor no matter how I configure the web.xml
and the ordering of Interceptor.classes appears to only apply to
"execution" strictly - not in addition "initialization" - as some have
suggested.
Why is this a problem... because of the way Stripersist is coded...
Spring ends up calling my @PostConstruct which in turn calls:
protected List load(String persistenceUnitName) {
return
Stripersist.getEntityManager(persistenceUnitName).createQuery("from "
+ this.entityClass.getName()).getResultList();
Which in turn calls:
public static EntityManager getEntityManager(String persistenceUnit) {
EntityManagerFactory factory =
getEntityManagerFactory(persistenceUnit);
Which in turn calls:
public static EntityManagerFactory getEntityManagerFactory(String
persistenceUnit) {
return entityManagerFactories.get(persistenceUnit); // [1]
and herein lies the problem... if Stripersist init() has not been
called then the following static attribute is NULL
static private Map
entityManagerFactories;
It is the lack of initialization of this attribute using information
obtained by reading the persistence.xml, calling the Persistence
class, etc... that is the problem.
And to prove that... if we do the following in our @PostConstruct:
Stripersist s = new Stripersist();
s.init(StripesFilter.getConfiguration());
List modalityList = this.modalityDao.findAll();
this.modalityCache = new ModalityCache();
this.modalityCache.init(modalityList);
Stripersist spits up 2 exceptions about being accessed outside any
request but now that the static attributes are initialized things work
from here. Of course defensively placing this code that spews 2
exceptions in each service bean is not acceptable but it proves the point.
Stripersist interceptor needs to be initialized BEFORE Spring
interceptor and Stripes does NOT seem to offer a configurable way to
force this.
Does anyone know how I can create a wrapper to dynamically:
--> Init and wire up Stripersist interceptor...
followed by
--> Init and wire up Spring interceptor
I figure if I create a simple wrapper to force the ordering we should
be in business.
--Nikolaos
Aaron Porter wrote:
Hi Nikolaos,
What Frank is saying is you don't have to go through Stripersist to get
an EntityManager. The main purpose of Stripersist is to provide the
Formatter/TypeConverter for Stripes to handle entities. It also provides
a little security by beginning a transaction so that you must explicity
commit for changes to occur.
I don't use Spring but I'm sure there is some way to get an
EntityManager from Spring without going through Stripersist.
Aaron
On 05/27/2010 09:35 AM, Nikolaos Giannopoulos wrote:
Frank,
Comments in-line below...
Frank Pavageau wrote:
On Thu, May 27, 2010 at 5:23 PM, Nikolaos Giannopoulos
wrote:
public class BaseActionBean implements ActionBean {
@SpringBean protected ModalityDao modalityDao;
...
@Repository("modalityDao")
public class ModalityDaoImpl extends BaseDaoImpl
implements ModalityDao {
public List findAll() {
return (this.load()); // [2]
}
@PostConstruct
private void init() {
this.findAll(); // [1]
}
The problem is that you have objects instanciated by the 2 frameworks
with independent lifecycles :
- Spring instanciates the DAO at c
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Aaron / Frank,
While I realize I don't have to use Stripersist... I am quite happy with
it... and instead of chucking it and doing some things by hand I am
trying to figure out how I can make things work. I mean it is providing
some benefit (we have MANY Entities and MANY DAOs) and while I agree
that the EntityManagerFactory is something it indirectly leverages I
would hope to find a way to make Stripersist work in this case... which
I think is important.
With that said I have clearly identified the problem by running all
sorts of tests and debugging things.
The Stripersist interceptor never gets a chance to initialize itself
prior to the Spring interceptor no matter how I configure the web.xml
and the ordering of Interceptor.classes appears to only apply to
"execution" strictly - not in addition "initialization" - as some have
suggested.
Why is this a problem... because of the way Stripersist is coded...
Spring ends up calling my @PostConstruct which in turn calls:
protected List load(String persistenceUnitName) {
return
Stripersist.getEntityManager(persistenceUnitName).createQuery("from " +
this.entityClass.getName()).getResultList();
Which in turn calls:
public static EntityManager getEntityManager(String persistenceUnit) {
EntityManagerFactory factory =
getEntityManagerFactory(persistenceUnit);
Which in turn calls:
public static EntityManagerFactory getEntityManagerFactory(String
persistenceUnit) {
return entityManagerFactories.get(persistenceUnit); // [1]
and herein lies the problem... if Stripersist init() has not been called
then the following static attribute is NULL
static private Map entityManagerFactories;
It is the lack of initialization of this attribute using information
obtained by reading the persistence.xml, calling the Persistence class,
etc... that is the problem.
And to prove that... if we do the following in our @PostConstruct:
Stripersist s = new Stripersist();
s.init(StripesFilter.getConfiguration());
List modalityList = this.modalityDao.findAll();
this.modalityCache = new ModalityCache();
this.modalityCache.init(modalityList);
Stripersist spits up 2 exceptions about being accessed outside any
request but now that the static attributes are initialized things work
from here. Of course defensively placing this code that spews 2
exceptions in each service bean is not acceptable but it proves the point.
Stripersist interceptor needs to be initialized BEFORE Spring
interceptor and Stripes does NOT seem to offer a configurable way to
force this.
Does anyone know how I can create a wrapper to dynamically:
--> Init and wire up Stripersist interceptor...
followed by
--> Init and wire up Spring interceptor
I figure if I create a simple wrapper to force the ordering we should be
in business.
--Nikolaos
Aaron Porter wrote:
Hi Nikolaos,
What Frank is saying is you don't have to go through Stripersist to get
an EntityManager. The main purpose of Stripersist is to provide the
Formatter/TypeConverter for Stripes to handle entities. It also provides
a little security by beginning a transaction so that you must explicity
commit for changes to occur.
I don't use Spring but I'm sure there is some way to get an
EntityManager from Spring without going through Stripersist.
Aaron
On 05/27/2010 09:35 AM, Nikolaos Giannopoulos wrote:
Frank,
Comments in-line below...
Frank Pavageau wrote:
On Thu, May 27, 2010 at 5:23 PM, Nikolaos Giannopoulos
wrote:
public class BaseActionBean implements ActionBean {
@SpringBean protected ModalityDao modalityDao;
...
@Repository("modalityDao")
public class ModalityDaoImpl extends BaseDaoImpl
implements ModalityDao {
public List findAll() {
return (this.load()); // [2]
}
@PostConstruct
private void init() {
this.findAll(); // [1]
}
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?
Much appreciated!
--Nikolaos
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforg
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Hi Nikolaos,
What Frank is saying is you don't have to go through Stripersist to get
an EntityManager. The main purpose of Stripersist is to provide the
Formatter/TypeConverter for Stripes to handle entities. It also provides
a little security by beginning a transaction so that you must explicity
commit for changes to occur.
I don't use Spring but I'm sure there is some way to get an
EntityManager from Spring without going through Stripersist.
Aaron
On 05/27/2010 09:35 AM, Nikolaos Giannopoulos wrote:
> Frank,
>
> Comments in-line below...
>
>
> Frank Pavageau wrote:
>
>> On Thu, May 27, 2010 at 5:23 PM, Nikolaos Giannopoulos
>> wrote:
>>
>>
>>> public class BaseActionBean implements ActionBean {
>>> @SpringBean protected ModalityDao modalityDao;
>>> ...
>>>
>>> @Repository("modalityDao")
>>> public class ModalityDaoImpl extends BaseDaoImpl
>>> implements ModalityDao {
>>> public List findAll() {
>>> return (this.load()); // [2]
>>> }
>>> @PostConstruct
>>> private void init() {
>>> this.findAll(); // [1]
>>> }
>>>
>>>
>
>
>> 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?
>
> Much appreciated!
>
> --Nikolaos
>
>
> --
>
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Frank,
Comments in-line below...
Frank Pavageau wrote:
> On Thu, May 27, 2010 at 5:23 PM, Nikolaos Giannopoulos
> wrote:
>
>>public class BaseActionBean implements ActionBean {
>>@SpringBean protected ModalityDao modalityDao;
>>...
>>
>>@Repository("modalityDao")
>>public class ModalityDaoImpl extends BaseDaoImpl
>> implements ModalityDao {
>>public List findAll() {
>>return (this.load()); // [2]
>>}
>>@PostConstruct
>>private void init() {
>>this.findAll(); // [1]
>>}
>>
> 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?
Much appreciated!
--Nikolaos
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
On Thu, May 27, 2010 at 5:23 PM, Nikolaos Giannopoulos
wrote:
> public class BaseActionBean implements ActionBean {
> �...@springbean protected ModalityDao modalityDao;
> ...
>
> �...@repository("modalityDao")
> public class ModalityDaoImpl extends BaseDaoImpl
> implements ModalityDao {
> public List findAll() {
> return (this.load()); // [2]
> }
> �...@postconstruct
> private void init() {
> this.findAll(); // [1]
> }
>
> And let's show the ApplicationContext.xml relevant snippet:
>
>
> base-package="org.lightagents.ws.dao.impl.stripersist" />
>
> The modalityDao bean is indeed constructed and all is well except that
> the init() post construct at [1] results in the call at [2] which
> results in calls to the underlying Stripersist Interceptor were in IT is
> not initialized.
>
> Clearly Stripersist plumbing is in an invalid state but how to get this
> to work is the question!
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
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).
Frank
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Oscar,
Comments in-line...
Oscar Westra van Holthe - Kind wrote:
> I may have missed the point too, given your description. The NPE tells me
> that the class is in an invalid state.
Let's go back to the more simplified example in this thread:
public class BaseActionBean implements ActionBean {
@SpringBean protected ModalityDao modalityDao;
...
@Repository("modalityDao")
public class ModalityDaoImpl extends BaseDaoImpl
implements ModalityDao {
public List findAll() {
return (this.load()); // [2]
}
@PostConstruct
private void init() {
this.findAll(); // [1]
}
And let's show the ApplicationContext.xml relevant snippet:
The modalityDao bean is indeed constructed and all is well except that
the init() post construct at [1] results in the call at [2] which
results in calls to the underlying Stripersist Interceptor were in IT is
not initialized.
Clearly Stripersist plumbing is in an invalid state but how to get this
to work is the question!
> Some of the reasons may be that Spring
> isn't injecting that state (at all or yet),
Not sure what you mean by this... .
> another that the interceptors are
> called in the wrong order. Due to the annotations,
> I do not believe the latter.
>
Right. The Stripersist interceptor intercepts at RequestInit which is
"before" the Spring intereceptor which intercepts at ActionBeanResolution.
> As a result, I try to structure the code to force it to initialize the
> autowired dependencies first. Constructor injection does that, though I do
> not know if there is another way. Failing that, I'd hazard a guess that
> Spring isn't managing the instance that throws a NPE.
>
I hear you however I'm still not sure how this would help as even with
Constructor injection you still need to have a way for the bean itself
to fully initialize itself. In fact, the reduced case re-presented
above doesn't even have any additional @Autowire dependency so it is
just this bean that needs to be created and initialized.
I am really open to what you are saying I just don't see how Constructor
injection will solve this.
Can you please outline your solution using the snippet of code above?
Thank You
--Nikolaos
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Ben, Oooops! Corrected - however the updated web.xml still results in the same exception at: ... Caused by: java.lang.NullPointerException at org.stripesstuff.stripersist.Stripersist.getEntityManagerFactory(Stripersist.java:401) at org.stripesstuff.stripersist.Stripersist.getEntityManager(Stripersist.java:495) ... with web.xml as follows: org.springframework.web.context.ContextLoaderListener StripesFilter net.sourceforge.stripes.controller.StripesFilter ... Interceptor.Classes org.stripesstuff.stripersist.Stripersist, net.sourceforge.stripes.integration.spring.SpringInterceptor Extension.Packages org.lightagents.ui.stripes.extensions, org.lightagents.ui.stripes.reload.extensions, --Nikolaos Ben Gunter wrote: You've specified a package name (org.stripesstuff.stripersist) in Interceptor.Classes where it requires a class name (org.stripesstuff.stripersist.Stripersist). On Wed, May 26, 2010 at 11:21 PM, Nikolaos Giannopoulos mailto:nikol...@brightminds.org>> wrote: Ben, Thanks for the reply. I tweaked the web.xml as you suggested as follows: org.springframework.web.context.ContextLoaderListener StripesFilter net.sourceforge.stripes.controller.StripesFilter ... Interceptor.Classes org.stripesstuff.stripersist, net.sourceforge.stripes.integration.spring.SpringInterceptor Extension.Packages org.lightagents.ui.stripes.extensions, org.lightagents.ui.stripes.reload.extensions However I am still getting the same exception (see below this time though with debug logging enabled and more than just the exception). Could it be that the Interceptor.Classes list only guarantees the order of "execution" but not "initialization". Any other ideas --Nikolaos -- ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
You've specified a package name (org.stripesstuff.stripersist) in Interceptor.Classes where it requires a class name (org.stripesstuff.stripersist.Stripersist). On Wed, May 26, 2010 at 11:21 PM, Nikolaos Giannopoulos < nikol...@brightminds.org> wrote: > Ben, > > Thanks for the reply. I tweaked the web.xml as you suggested as follows: > > > > > org.springframework.web.context.ContextLoaderListener > > > >StripesFilter > > > net.sourceforge.stripes.controller.StripesFilter >... > >Interceptor.Classes > >org.stripesstuff.stripersist, >net.sourceforge.stripes.integration.spring.SpringInterceptor > > > >Extension.Packages > >org.lightagents.ui.stripes.extensions, >org.lightagents.ui.stripes.reload.extensions > > > > However I am still getting the same exception (see below this time > though with debug logging enabled and more than just the exception). > > Could it be that the Interceptor.Classes list only guarantees the order > of "execution" but not "initialization". > > Any other ideas > > --Nikolaos > > -- ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
On 26-05-2010 at 19:53, Nikolaos Giannopoulos wrote: > Oscar, > [...] > The problem here appears to be that Spring beans get initialized > BEFORE Stripersist initializes itself... or at least that is how it > appears... and as such invocations to Stripersist after bean > creation / DI will throw errors regardless of whether I am doing > Constructor vs. Setter based injection... unless I am missing > something? > > If I did miss your point what do you propose as a solution? I may have missed the point too, given your description. The NPE tells me that the class is in an invalid state. Some of the reasons may be that Spring isn't injecting that state (at all or yet), another that the interceptors are called in the wrong order. Due to the annotations, I do not believe the latter. As a result, I try to structure the code to force it to initialize the autowired dependencies first. Constructor injection does that, though I do not know if there is another way. Failing that, I'd hazard a guess that Spring isn't managing the instance that throws a NPE. Oscar -- ,-_ /() ) Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/ (__ ( =/ () Even if you win the rat race, you are still a rat... signature.asc Description: Digital signature -- ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Ben,
Thanks for the reply. I tweaked the web.xml as you suggested as follows:
org.springframework.web.context.ContextLoaderListener
StripesFilter
net.sourceforge.stripes.controller.StripesFilter
...
Interceptor.Classes
org.stripesstuff.stripersist,
net.sourceforge.stripes.integration.spring.SpringInterceptor
Extension.Packages
org.lightagents.ui.stripes.extensions,
org.lightagents.ui.stripes.reload.extensions
However I am still getting the same exception (see below this time
though with debug logging enabled and more than just the exception).
Could it be that the Interceptor.Classes list only guarantees the order
of "execution" but not "initialization".
Any other ideas
--Nikolaos
[#|2010-05-26T23:01:13.755-0400|INFO|glassfishv3.0|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=23;_ThreadName=AutoDeployer;|Security
startup service called|#]
[#|2010-05-26T23:01:13.760-0400|INFO|glassfishv3.0|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=23;_ThreadName=AutoDeployer;|SEC1143:
Loading policy provider
com.sun.enterprise.security.provider.PolicyWrapper.|#]
[#|2010-05-26T23:01:13.804-0400|INFO|glassfishv3.0|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=23;_ThreadName=AutoDeployer;|Realm
admin-realm of classtype
com.sun.enterprise.security.auth.realm.file.FileRealm successfully
created.|#]
[#|2010-05-26T23:01:13.805-0400|INFO|glassfishv3.0|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=23;_ThreadName=AutoDeployer;|Realm
file of classtype com.sun.enterprise.security.auth.realm.file.FileRealm
successfully created.|#]
[#|2010-05-26T23:01:13.807-0400|INFO|glassfishv3.0|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=23;_ThreadName=AutoDeployer;|Realm
certificate of classtype
com.sun.enterprise.security.auth.realm.certificate.CertificateRealm
successfully created.|#]
[#|2010-05-26T23:01:13.813-0400|INFO|glassfishv3.0|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=23;_ThreadName=AutoDeployer;|Security
service(s) started successfully|#]
[#|2010-05-26T23:01:14.046-0400|INFO|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=23;_ThreadName=AutoDeployer;|Created
HTTP listener http-listener-1 on port 8080|#]
[#|2010-05-26T23:01:14.053-0400|INFO|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=23;_ThreadName=AutoDeployer;|Created
HTTP listener http-listener-2 on port 8181|#]
[#|2010-05-26T23:01:14.061-0400|INFO|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=23;_ThreadName=AutoDeployer;|Created
HTTP listener admin-listener on port 4848|#]
[#|2010-05-26T23:01:14.063-0400|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=22;_ThreadName={felix.fileinstall.poll=5000,
felix.fileinstall.bundles.new.start=true,
felix.fileinstall.dir=/Users/nikolaos2/home/dv/oracle-glassfish-3.0/glassfish/modules/autostart/,
felix.fileinstall.debug=1};|Updating configuration from
org.apache.felix.fileinstall-autodeploy-bundles.cfg|#]
[#|2010-05-26T23:01:14.067-0400|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=22;_ThreadName={felix.fileinstall.poll=5000,
felix.fileinstall.bundles.new.start=true,
felix.fileinstall.dir=/Users/nikolaos2/home/dv/oracle-glassfish-3.0/glassfish/modules/autostart/,
felix.fileinstall.debug=1};|Installed
/Users/nikolaos2/home/dv/oracle-glassfish-3.0/glassfish/modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg|#]
[#|2010-05-26T23:01:14.071-0400|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=24;_ThreadName={felix.fileinstall.poll=5000,
felix.fileinstall.bundles.new.start=true,
service.pid=org.apache.felix.fileinstall.42b62929-8446-4358-9e67-0a53b6423f82,
felix.fileinstall.dir=/Users/nikolaos2/home/dv/oracle-glassfish-3.0/glassfish/domains/domain1/autodeploy/bundles/,
felix.fileinstall.filename=org.apache.felix.fileinstall-autodeploy-bundles.cfg,
service.factorypid=org.apache.felix.fileinstall,
felix.fileinstall.debug=1};|{felix.fileinstall.poll (ms) = 5000,
felix.fileinstall.dir =
/Users/nikolaos2/home/dv/oracle-glassfish-3.0/glassfish/domains/domain1/autodeploy/bundles,
felix.fileinstall.debug = 1, felix.fileinstall.bundles.new.start = true,
felix.fileinstall.tmpdir =
/var/folders/DA/DA91I53NH+io5VDIetEmiE+++TQ/-Tmp-/fileinstall-735697260072014,
felix.fileinstall.filter = null}|#]
[#|2010-05-26T23:01:14.120-0400|INFO|glassfishv3.0|javax.enterprise.system.con
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
If you list both of these interceptors in your Interceptor.Classes
init-param in the order you want them to initialize they will initialize in
the specified order. You already list SpringInterceptor there. I think if
you just insert Stripersist before it then you'll be in business. (Once you
do that then you should remove their packages from Extension.Packages to
improve startup speed.)
-Ben
On Wed, May 26, 2010 at 10:25 PM, Nikolaos Giannopoulos <
nikol...@brightminds.org> wrote:
> All,
>
> After a lot of digging I have unfortunately gotten nowhere.
>
> I have found that the lifecycles that Stripersist intercepts are:
> @Intercepts({LifecycleStage.RequestInit, LifecycleStage.RequestComplete})
>
> Whereas the Spring Interceptor intercepts at:
> @Intercepts(LifecycleStage.ActionBeanResolution)
>
> SO if both were initialized at "execution" intercept time then I suspect we
> would not have any issues.
>
> However the NPE tells me that this issue appears due to order of
> "initialization" of Interceptors.
> I have found how to order the "execution" of Interceptors BUT not the
> "initialization" of Interceptors.
>
> Does anyone know how I can get Stripersist to initialize BEFORE Spring
> Interceptor?
> I have the following web.xml snippet and could really use a lot of help...
> PLEASE...
>
>
>
> org.springframework.web.context.ContextLoaderListener
>
>
>
> StripesFilter
>
> net.sourceforge.stripes.controller.StripesFilter
> ...
>
> Interceptor.Classes
>
> net.sourceforge.stripes.integration.spring.SpringInterceptor
>
>
> Extension.Packages
>
> org.lightagents.ui.stripes.extensions,
> org.lightagents.ui.stripes.reload.extensions,
> org.stripesstuff.stripersist,
> net.sourceforge.stripes.integration.spring
>
>
> ...
>
> Stripersist is an awesome package and we have even built a shard layer on
> top of it... I surely hope there is a solution for it to play nice with
> Spring in this case.
>
> Thanks in Advance!
>
> --Nikolaos
>
>
>
> Nikolaos Giannopoulos wrote:
>
> Still trying to resolve this issue... and I think I have made some progress
> in ZERO'ing in on a reduced version of the issue.
>
> The following code works fine:
>
> public class BaseActionBean implements ActionBean {
> @SpringBean protected ModalityDao modalityDao;
> ...
>
> @Repository("modalityDao")
> public class ModalityDaoImpl extends BaseDaoImpl
> implements ModalityDao {
> public List findAll() {
> return (this.load());
> }
>
> However if I add a @PostConstruct on the above DAO as follows I get the
> exception reported previously (see below again):
>
> public class BaseActionBean implements ActionBean {
> @SpringBean protected ModalityDao modalityDao;
> ...
>
> @Repository("modalityDao")
> public class ModalityDaoImpl extends BaseDaoImpl
> implements ModalityDao {
> public List findAll() {
> return (this.load());
> }
> @PostConstruct
> private void init() {
> this.findAll();
> }
>
> It would appear that Spring's interceptor is doing its work BEFORE
> Stripersist's interceptor gets its chance to initialize.
>
> Because in digging through the Stripersist code we have:
>
> /**
> * Called by Stripes during initialization.
> */
> public void init(Configuration configuration)
> ...
> URL url =
> Thread.currentThread().getContextClassLoader().getResource("/META-INF/persistence.xml");
> ...
> init(url);
>
> ... and in turn init(url) calls ...
>
> public void init(URL xml)
> ...
> entityManagerFactories = new ConcurrentHashMap EntityManagerFactory>();
>
> and that would clearly appear that entityManagerFactories is initialized
> however it is NULL when we run the 2nd code above.
>
> It would APPEAR we want the Stripersist interceptor to initialize BEFORE
> the Spring interceptor.
>
> Anyone know how we can accomplish this besides creating a Spring-Stripes
> extension class that simply calls them in the desired order???
>
> --Nikolaos
>
>
>
>
> Nikolaos Giannopoulos wrote:
>
> Freddy (and Aaron),
>
> Offhand THANK YOU for the help! While it DID help I'm afraid I'm not
> there yet... .
>
> So I added the @PostConstruct annotation (and/> in the applicationContext.xml to register things) and have the
> following code:
>
> @Service("modalityService")
> public class ModalityServiceImpl implements ModalityService {
>
> @Autowired
> private ModalityDao modalityDao;
>
> private ModalityCache modalityCache;
>
> public ModalityServiceImpl() {
> }
>
> @PostConstruct
> public void initService() {
> List modalityList = this.modalityDao.findAll();
> this.modalityCache = new ModalityCache();
> this.mod
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
All,
After a lot of digging I have unfortunately gotten nowhere.
I have found that the lifecycles that Stripersist intercepts are:
@Intercepts({LifecycleStage.RequestInit, LifecycleStage.RequestComplete})
Whereas the Spring Interceptor intercepts at:
@Intercepts(LifecycleStage.ActionBeanResolution)
SO if both were initialized at "execution" intercept time then I suspect
we would not have any issues.
However the NPE tells me that this issue appears due to order of
"initialization" of Interceptors.
I have found how to order the "execution" of Interceptors BUT not the
"initialization" of Interceptors.
Does anyone know how I can get Stripersist to initialize BEFORE Spring
Interceptor?
I have the following web.xml snippet and could really use a lot of
help... PLEASE...
org.springframework.web.context.ContextLoaderListener
StripesFilter
net.sourceforge.stripes.controller.StripesFilter
...
Interceptor.Classes
net.sourceforge.stripes.integration.spring.SpringInterceptor
Extension.Packages
org.lightagents.ui.stripes.extensions,
org.lightagents.ui.stripes.reload.extensions,
org.stripesstuff.stripersist,
net.sourceforge.stripes.integration.spring
...
Stripersist is an awesome package and we have even built a shard layer
on top of it... I surely hope there is a solution for it to play nice
with Spring in this case.
Thanks in Advance!
--Nikolaos
Nikolaos Giannopoulos wrote:
Still trying to resolve this issue... and I think I have made some
progress in ZERO'ing in on a reduced version of the issue.
The following code works fine:
public class BaseActionBean implements ActionBean {
@SpringBean protected ModalityDao modalityDao;
...
@Repository("modalityDao")
public class ModalityDaoImpl extends BaseDaoImplInteger> implements ModalityDao {
public List findAll() {
return (this.load());
}
However if I add a @PostConstruct on the above DAO as follows I get
the exception reported previously (see below again):
public class BaseActionBean implements ActionBean {
@SpringBean protected ModalityDao modalityDao;
...
@Repository("modalityDao")
public class ModalityDaoImpl extends BaseDaoImplInteger> implements ModalityDao {
public List findAll() {
return (this.load());
}
@PostConstruct
private void init() {
this.findAll();
}
It would appear that Spring's interceptor is doing its work BEFORE
Stripersist's interceptor gets its chance to initialize.
Because in digging through the Stripersist code we have:
/**
* Called by Stripes during initialization.
*/
public void init(Configuration configuration)
...
URL url =
Thread.currentThread().getContextClassLoader().getResource("/META-INF/persistence.xml");
...
init(url);
... and in turn init(url) calls ...
public void init(URL xml)
...
entityManagerFactories = new ConcurrentHashMapEntityManagerFactory>();
and that would clearly appear that entityManagerFactories is
initialized however it is NULL when we run the 2nd code above.
It would APPEAR we want the Stripersist interceptor to initialize
BEFORE the Spring interceptor.
Anyone know how we can accomplish this besides creating a
Spring-Stripes extension class that simply calls them in the desired
order???
--Nikolaos
Nikolaos Giannopoulos wrote:
Freddy (and Aaron),
Offhand THANK YOU for the help! While it DID help I'm afraid I'm
not there yet... .
So I added the @PostConstruct annotation (and
in the applicationContext.xml to
register things) and have the following code:
@Service("modalityService")
public class ModalityServiceImpl implements ModalityService {
@Autowired
private ModalityDao modalityDao;
private ModalityCache modalityCache;
public ModalityServiceImpl() {
}
@PostConstruct
public void initService() {
List modalityList = this.modalityDao.findAll();
this.modalityCache = new ModalityCache();
this.modalityCache.init(modalityList);
}
And the @PostConstruct indeed helped as the initService method is
getting executed however now I am back to the issue with Stripersist
generating a NPE in the following method call:
/**
* Finds the EntityManagerFactory which is associated with the
specified
* persistence unit. Normally you shouldn't use this class because
* Stripersist won't clean up any EntityManagers that you create.
*
* @param persistenceUnit the name of the persistence unit
* @return an EntityManagerFactory or null
*/
public static EntityManagerFactory getEntityManagerFactory(String
persistenceUnit)
{
return entityMa
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Oscar,
Thanks for the input however I am not weighing the merits of Constructor
based VS. Setter based Spring DI.
The problem here appears to be that Spring beans get initialized BEFORE
Stripersist initializes itself... or at least that is how it appears...
and as such invocations to Stripersist after bean creation / DI will
throw errors regardless of whether I am doing Constructor vs. Setter
based injection... unless I am missing something?
If I did miss your point what do you propose as a solution?
--Nikolaos
Oscar Westra van Holthe - Kind wrote:
On 26-05-2010 at 03:16, Nikolaos Giannopoulos wrote:
So we have the following code excerpt:
@Service
public class ModalityServiceImpl implements ModalityService {
@Autowired
private ModalityDao modalityDaoImpl;
public ModalityServiceImpl() {
this.initService();
}
private void initAfter() {
List modalityList = this.modalityDaoImpl.findAll();
// ** NPE ** - this.modalityDaoImpl ** IS NULL **
this.modalityCache = new ModalityCache();
this.modalityCache.init(modalityList);
}
However, the above results in a NullPointerException at the line marked
with ** NPE ** because this.modalityDaoImpl is NULL which clearly
indicates that Spring has not completed the Autowiring and we are trying
to invoke a method on.
I may be going against dogma here, but I prefer all classes to be in a valid
state all the time. So no Spring injection into fields: after construction
the object is in an invalid state until Spring completes the injection.
Instead, I let Spring do Constructor injection.
CON: I need to set the field myself (but I can make it final)
PRO: The constructor can do the initialization
Oscar
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
On 26-05-2010 at 03:16, Nikolaos Giannopoulos wrote:
> So we have the following code excerpt:
>
> @Service
> public class ModalityServiceImpl implements ModalityService {
>
> @Autowired
> private ModalityDao modalityDaoImpl;
>
> public ModalityServiceImpl() {
> this.initService();
> }
>
> private void initAfter() {
> List modalityList = this.modalityDaoImpl.findAll();
> // ** NPE ** - this.modalityDaoImpl ** IS NULL **
> this.modalityCache = new ModalityCache();
> this.modalityCache.init(modalityList);
> }
>
> However, the above results in a NullPointerException at the line marked
> with ** NPE ** because this.modalityDaoImpl is NULL which clearly
> indicates that Spring has not completed the Autowiring and we are trying
> to invoke a method on.
I may be going against dogma here, but I prefer all classes to be in a valid
state all the time. So no Spring injection into fields: after construction
the object is in an invalid state until Spring completes the injection.
Instead, I let Spring do Constructor injection.
CON: I need to set the field myself (but I can make it final)
PRO: The constructor can do the initialization
Oscar
--
,-_
/() ) Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/
(__ (
=/ () QED - Quite Easily Done
signature.asc
Description: Digital signature
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Still trying to resolve this issue... and I think I have made some
progress in ZERO'ing in on a reduced version of the issue.
The following code works fine:
public class BaseActionBean implements ActionBean {
@SpringBean protected ModalityDao modalityDao;
...
@Repository("modalityDao")
public class ModalityDaoImpl extends BaseDaoImpl
implements ModalityDao {
public List findAll() {
return (this.load());
}
However if I add a @PostConstruct on the above DAO as follows I get the
exception reported previously (see below again):
public class BaseActionBean implements ActionBean {
@SpringBean protected ModalityDao modalityDao;
...
@Repository("modalityDao")
public class ModalityDaoImpl extends BaseDaoImpl
implements ModalityDao {
public List findAll() {
return (this.load());
}
@PostConstruct
private void init() {
this.findAll();
}
It would appear that Spring's interceptor is doing its work BEFORE
Stripersist's interceptor gets its chance to initialize.
Because in digging through the Stripersist code we have:
/**
* Called by Stripes during initialization.
*/
public void init(Configuration configuration)
...
URL url =
Thread.currentThread().getContextClassLoader().getResource("/META-INF/persistence.xml");
...
init(url);
... and in turn init(url) calls ...
public void init(URL xml)
...
entityManagerFactories = new ConcurrentHashMapEntityManagerFactory>();
and that would clearly appear that entityManagerFactories is initialized
however it is NULL when we run the 2nd code above.
It would APPEAR we want the Stripersist interceptor to initialize BEFORE
the Spring interceptor.
Anyone know how we can accomplish this besides creating a Spring-Stripes
extension class that simply calls them in the desired order???
--Nikolaos
Nikolaos Giannopoulos wrote:
Freddy (and Aaron),
Offhand THANK YOU for the help! While it DID help I'm afraid I'm not
there yet... .
So I added the @PostConstruct annotation (and
in the applicationContext.xml to
register things) and have the following code:
@Service("modalityService")
public class ModalityServiceImpl implements ModalityService {
@Autowired
private ModalityDao modalityDao;
private ModalityCache modalityCache;
public ModalityServiceImpl() {
}
@PostConstruct
public void initService() {
List modalityList = this.modalityDao.findAll();
this.modalityCache = new ModalityCache();
this.modalityCache.init(modalityList);
}
And the @PostConstruct indeed helped as the initService method is
getting executed however now I am back to the issue with Stripersist
generating a NPE in the following method call:
/**
* Finds the EntityManagerFactory which is associated with the
specified
* persistence unit. Normally you shouldn't use this class because
* Stripersist won't clean up any EntityManagers that you create.
*
* @param persistenceUnit the name of the persistence unit
* @return an EntityManagerFactory or null
*/
public static EntityManagerFactory getEntityManagerFactory(String
persistenceUnit)
{
return entityManagerFactories.get(persistenceUnit);
}
Where: entityManagerFactories is NULL! So it is almost like even
though the @PostConstruct annotated method gets invoked on bean post
creation a layer of the onion has been lifted and now the problem
appears that Stripersist hasn't completed its initialization. I have
to think there MUST be a way to solve this!!! AHh???
Full stack trace below
Many Thanks,
--Nikolaos
[#|2010-05-26T14:07:50.795-0400|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=11;_ThreadName=FelixStartLevel;|[14:07:50,774]
ERROR
org.springframework.web.context.ContextLoader.initWebApplicationContext
- Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'modalityService': Invocation of init method
failed; nested exception is java.lang.NullPointerException
at
org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:147)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:350)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1331)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowir
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Freddy (and Aaron),
Offhand THANK YOU for the help! While it DID help I'm afraid I'm not
there yet... .
So I added the @PostConstruct annotation (and
in the applicationContext.xml to
register things) and have the following code:
@Service("modalityService")
public class ModalityServiceImpl implements ModalityService {
@Autowired
private ModalityDao modalityDao;
private ModalityCache modalityCache;
public ModalityServiceImpl() {
}
@PostConstruct
public void initService() {
List modalityList = this.modalityDao.findAll();
this.modalityCache = new ModalityCache();
this.modalityCache.init(modalityList);
}
And the @PostConstruct indeed helped as the initService method is
getting executed however now I am back to the issue with Stripersist
generating a NPE in the following method call:
/**
* Finds the EntityManagerFactory which is associated with the specified
* persistence unit. Normally you shouldn't use this class because
* Stripersist won't clean up any EntityManagers that you create.
*
* @param persistenceUnit the name of the persistence unit
* @return an EntityManagerFactory or null
*/
public static EntityManagerFactory getEntityManagerFactory(String
persistenceUnit)
{
return entityManagerFactories.get(persistenceUnit);
}
Where: entityManagerFactories is NULL! So it is almost like even
though the @PostConstruct annotated method gets invoked on bean post
creation a layer of the onion has been lifted and now the problem
appears that Stripersist hasn't completed its initialization. I have to
think there MUST be a way to solve this!!! AHh???
Full stack trace below
Many Thanks,
--Nikolaos
[#|2010-05-26T14:07:50.795-0400|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=11;_ThreadName=FelixStartLevel;|[14:07:50,774]
ERROR
org.springframework.web.context.ContextLoader.initWebApplicationContext
- Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'modalityService': Invocation of init method failed;
nested exception is java.lang.NullPointerException
at
org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:147)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:350)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1331)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
at java.security.AccessController.doPrivileged(Native Method)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:380)
at
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
at
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
at
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4591)
at
com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:535)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:5193)
at com.sun.enterprise.web.WebModule.start(WebModule.java:499)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:928)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:912)
at org.apache.catalina
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Hi Nikolaos,
> I guess what I need is a WAY to perform POST initialization on this
> Spring managed Service object. If I was dealing with an ActionBean then
> an @AFTER on a particular life cycle event I imagine would do the trick
> but this is not an Action Bean.
You are right, it is a bad idea to do any work in the constructor in
this case; you need to let Spring finish its wiring.
Indeed there is a standard annotation for doing post-initialization
work:
javax.annotation.PostConstruct. Spring recognizes this annotation when
its
annotation post processor is registered.[1]
So all you need is something like:
@PostConstruct
public void init() {
// do initialization work
// the name of the method can be something else than 'init'
}
I use this mechanism a lot and it works well.
Hope that helps.
Cheers,
Freddy
[1]:
http://static.springsource.org/spring/docs/2.5.x/reference/beans.html#beans-postconstruct-and-predestroy-annotations
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
Hi,
I finally tracked down an issue that I was having in a Stripes 1.5.4
BETA, Stripersist, Spring, JPA, Hibernate, etc... application:
We essentially have a Services layer that sits in front of the Dao layer
and as such are following the following example:
http://www.stripesframework.org/display/stripes/Stripes+Spring+JPA
Furthermore, as ALL beans in Spring default to being Singletons it is
important that the Service initialize itself when it (the Singleton)
gets created otherwise we end up with multiple users of the Singleton
trying to initialize it / adding synchronized blocks et al... which is
UGLY to say the least
So we have the following code excerpt:
@Service
public class ModalityServiceImpl implements ModalityService {
@Autowired
private ModalityDao modalityDaoImpl;
public ModalityServiceImpl() {
this.initService();
}
private void initAfter() {
List modalityList = this.modalityDaoImpl.findAll();
// ** NPE ** - this.modalityDaoImpl ** IS NULL **
this.modalityCache = new ModalityCache();
this.modalityCache.init(modalityList);
}
However, the above results in a NullPointerException at the line marked
with ** NPE ** because this.modalityDaoImpl is NULL which clearly
indicates that Spring has not completed the Autowiring and we are trying
to invoke a method on. A similar scenario occurs even if we didn't
Autowire the DAO and simply had the following for the attribute:
private ModalityDao modalityDaoImpl = new ModalityDaoImpl();
In this latter case there is Stripersist except when trying to lookup
the persistence unit with a NULL entityFactories hashtable.
I guess what I need is a WAY to perform POST initialization on this
Spring managed Service object. If I was dealing with an ActionBean then
an @AFTER on a particular life cycle event I imagine would do the trick
but this is not an Action Bean.
Any ideas anyone??? Perhaps using the SpringIntereceptorSupport class
Thanks,
--Nikolaos
--
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
