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
ServletCont
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
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;
>>>
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 fi
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 ag
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 explicit
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")
>>
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 Mo
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
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.getEntityMan
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 t
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 e
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
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 tha
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.ActionBeanResolut
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 Striper
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.initServi
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("
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 ModalityServi
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 i
20 matches
Mail list logo
