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: listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class!-- Automatically loads: /WEB-INF/applicationContext.xml -- /listener filter filter-nameStripesFilter/filter-name filter-classnet.sourceforge.stripes.controller.StripesFilter/filter-class ... init-param param-nameInterceptor.Classes/param-name param-value org.stripesstuff.stripersist, net.sourceforge.stripes.integration.spring.SpringInterceptor /param-value /init-param init-param param-nameExtension.Packages/param-name param-value org.lightagents.ui.stripes.extensions, org.lightagents.ui.stripes.reload.extensions /param-value /init-param 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
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: listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class!-- Automatically loads: /WEB-INF/applicationContext.xml -- /listener filter filter-nameStripesFilter/filter-name filter-classnet.sourceforge.stripes.controller.StripesFilter/filter-class ... init-param param-nameInterceptor.Classes/param-name param-value org.stripesstuff.stripersist.Stripersist, net.sourceforge.stripes.integration.spring.SpringInterceptor /param-value /init-param init-param param-nameExtension.Packages/param-name param-value org.lightagents.ui.stripes.extensions, org.lightagents.ui.stripes.reload.extensions, /param-value /init-param --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 nikol...@brightminds.org mailto:nikol...@brightminds.org wrote: Ben, Thanks for the reply. I tweaked the web.xml as you suggested as follows: listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class!-- Automatically loads: /WEB-INF/applicationContext.xml -- /listener filter filter-nameStripesFilter/filter-name filter-classnet.sourceforge.stripes.controller.StripesFilter/filter-class ... init-param param-nameInterceptor.Classes/param-name param-value org.stripesstuff.stripersist, net.sourceforge.stripes.integration.spring.SpringInterceptor /param-value /init-param init-param param-nameExtension.Packages/param-name param-value org.lightagents.ui.stripes.extensions, org.lightagents.ui.stripes.reload.extensions /param-value /init-param 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
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 BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality findAll() {
return (this.load()); // [2]
}
@PostConstruct
private void init() {
this.findAll(); // [1]
}
And let's show the ApplicationContext.xml relevant snippet:
context:annotation-config /
context:component-scan
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!
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
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 BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality findAll() {
return (this.load()); // [2]
}
�...@postconstruct
private void init() {
this.findAll(); // [1]
}
And let's show the ApplicationContext.xml relevant snippet:
context:annotation-config /
context:component-scan
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
Frank,
Comments in-line below...
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 BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality 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?
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
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
nikol...@brightminds.org wrote:
public class BaseActionBean implements ActionBean {
@SpringBean protected ModalityDao modalityDao;
...
@Repository(modalityDao)
public class ModalityDaoImpl extends BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality 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?
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
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 ListT 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 MapString, EntityManagerFactory 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());
ListModality 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
nikol...@brightminds.org wrote:
public class BaseActionBean implements ActionBean {
@SpringBean protected ModalityDao modalityDao;
...
@Repository(modalityDao)
public class ModalityDaoImpl extends BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality 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?
Much appreciated!
--Nikolaos
--
___
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 ListT 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 MapString, EntityManagerFactory
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());
ListModality 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
nikol...@brightminds.org wrote:
public class BaseActionBean implements ActionBean {
@SpringBean protected ModalityDao modalityDao;
...
@Repository(modalityDao)
public class ModalityDaoImpl extends BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality findAll() {
return (this.load()); // [2]
}
@PostConstruct
private void init() {
this.findAll(); // [1]
}
snip
The problem is that you have objects instanciated by the 2
Re: [Stripes-users] Stripes and Spring - Exception if doing INIT in Constructor
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 BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality 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
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 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
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
context:annotation-config / 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() {
ListModality 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
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 BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality 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 BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality 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 ConcurrentHashMapString,
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
context:annotation-config / 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() {
ListModality 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
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() {
ListModality 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
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...
listener
listener-classorg.springframework.web.context.ContextLoaderListener/listener-class!--
Automatically loads: /WEB-INF/applicationContext.xml --
/listener
filter
filter-nameStripesFilter/filter-name
filter-classnet.sourceforge.stripes.controller.StripesFilter/filter-class
...
init-param
param-nameInterceptor.Classes/param-name
param-valuenet.sourceforge.stripes.integration.spring.SpringInterceptor/param-value
/init-param
init-param
param-nameExtension.Packages/param-name
param-value
org.lightagents.ui.stripes.extensions,
org.lightagents.ui.stripes.reload.extensions,
org.stripesstuff.stripersist,
net.sourceforge.stripes.integration.spring
/param-value
/init-param
...
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 BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality 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 BaseDaoImplModality, Integer
implements ModalityDao {
public ListModality 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 ConcurrentHashMapString,
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 context:annotation-config
/ 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
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:
listener
listener-classorg.springframework.web.context.ContextLoaderListener/listener-class!--
Automatically loads: /WEB-INF/applicationContext.xml --
/listener
filter
filter-nameStripesFilter/filter-name
filter-classnet.sourceforge.stripes.controller.StripesFilter/filter-class
...
init-param
param-nameInterceptor.Classes/param-name
param-value
org.stripesstuff.stripersist,
net.sourceforge.stripes.integration.spring.SpringInterceptor
/param-value
/init-param
init-param
param-nameExtension.Packages/param-name
param-value
org.lightagents.ui.stripes.extensions,
org.lightagents.ui.stripes.reload.extensions
/param-value
/init-param
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,
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
