Startup failure in version 1.6

[srbala]

Mybatis has a demo application https://github.com/mybatis/jpetstore-6

I have tried update the stripes dependencey (pom.xml) to 1.6, demo stops working with following error.

1168 [localhost-startStop-1] FATAL net.sourceforge.stripes.controller.StripesFi
ter  - Could not instantiate specified Configuration. Class name specified was
net.sourceforge.stripes.config.RuntimeConfiguration].
net.sourceforge.stripes.exception.StripesRuntimeException: Problem instantiatin
 default configuration objects.
        at net.sourceforge.stripes.config.DefaultConfiguration.init(DefaultConfguration.java:245)
        at net.sourceforge.stripes.config.RuntimeConfiguration.init(RuntimeConfguration.java:291)
        at net.sourceforge.stripes.controller.StripesFilter.createConfiguration StripesFilter.java:137)
        at net.sourceforge.stripes.controller.StripesFilter.init(StripesFilter.java:103)

Steps to recreate:

1. clone above repository.
2. update update stripes version to 1.6.0 in pom.xml
3. run the application mvn clean tomcat7:run, application should be available at http://localhost:8080/jpetstore

[rgrashel]

I haven't actually used this target, but I'll take a look at it.

[harawata]

Stripes 1.6 has some backward incompatible changes since 1.5.x. SpringInterceptor which is used in the jpetstore application was removed in favor of the new ObjectPostProcessor mechanism.

There might be other issues, but the following change to web.xml should be enough to startup the application.

diff --git a/src/main/webapp/WEB-INF/web.xml b/src/main/webapp/WEB-INF/web.xml
index d9b5d81..7c1c2c9 100644
--- a/src/main/webapp/WEB-INF/web.xml
+++ b/src/main/webapp/WEB-INF/web.xml
@@ -25,10 +25,10 @@
                        <param-value>org.mybatis.jpetstore.web</param-value>
                </init-param>
                <init-param>
-                       <param-name>Interceptor.Classes</param-name>
+                       <param-name>Extension.Packages</param-name>
                        <param-value>
-                       net.sourceforge.stripes.integration.spring.SpringInterceptor
-                   </param-value>
+                               net.sourceforge.stripes.integration.spring
+                       </param-value>
                </init-param>
        </filter>
        <filter-mapping>

With this change, Stripes will pick up the new SpringInjectionPostProcessor that handles the @SpringBean injection.

Hope this helps, Iwao

[rgrashel]

Iwao,

@harawata, did you test this with the maven target called out by @srbala?

[harawata]

Hi Rick,

Yes, I tested with mvn clean tomcat7:run.

And for future reference, here is the full stack trace that the OP should have seen.

net.sourceforge.stripes.exception.StripesServletException: Could not instantiate specified Configuration. Class name specified was [net.sourceforge.stripes.config.RuntimeConfiguration].
        at net.sourceforge.stripes.controller.StripesFilter.createConfiguration(StripesFilter.java:145)
        at net.sourceforge.stripes.controller.StripesFilter.init(StripesFilter.java:103)
        at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:281)
        at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:262)
        at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:107)
        at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4775)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5452)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
Caused by: net.sourceforge.stripes.exception.StripesRuntimeException: Problem instantiating default configuration objects.
        at net.sourceforge.stripes.config.DefaultConfiguration.init(DefaultConfiguration.java:245)
        at net.sourceforge.stripes.config.RuntimeConfiguration.init(RuntimeConfiguration.java:291)
        at net.sourceforge.stripes.controller.StripesFilter.createConfiguration(StripesFilter.java:137)
        ... 13 more
Caused by: net.sourceforge.stripes.exception.StripesRuntimeException: Could not find class [net.sourceforge.stripes.integration.spring.SpringInterceptor] specified by the configuration parameter [Interceptor.Classes]. This value must contain fully qualified class names separated  by commas.
        at net.sourceforge.stripes.config.BootstrapPropertyResolver.getClassPropertyList(BootstrapPropertyResolver.java:200)
        at net.sourceforge.stripes.config.BootstrapPropertyResolver.getClassPropertyList(BootstrapPropertyResolver.java:242)
        at net.sourceforge.stripes.config.RuntimeConfiguration.initInterceptors(RuntimeConfiguration.java:214)
        at net.sourceforge.stripes.config.DefaultConfiguration.init(DefaultConfiguration.java:220)
        ... 15 more

[juanpablo-santos]

Just a couple of quick notes,

1) SpringInjectionPostProcessor isn't (always) a one-change solution: SpringInterceptor allowed to not have an applicationContext (the interceptor did nothing and the application init carried on), wereas the SpringObjectPostProcessor fails the application at startup if an Spring application context isn't found.

We found this while migrating to 1.6 on quite a lot of unit tests without spring context which were sharing the same configuration as other tests declaring an spring context.

2) Wasn't SpringInterceptor meant to be kept on 1.6? (cfr. with https://stripesframework.atlassian.net/browse/STS-633 and its comments)

[vankeisb]

Hi,

1) From what you say, it's a regression. I propose to revert to the previous behaviour. 2) It's apparently been wiped out. Do we really need it ?

[juanpablo-santos]

Hi @vankeisb,

1) +1 on that; could send a PR if needed;

2) (imho) with the previous behaviour in place, most probably not.. Right now, we defined a custom Spring PostProcessor which mimics the old behaviour and carried on, was easier than going from test to test.

As an aside, it would be nice to have some packages automagically loaded, as it is done with the core interceptors. The SpringObjectPostProcessor would be a good fit for that, as it has basically no overhead if there isn't an Spring's application context (with the previous behaviour, that is).

Finally, one other potentially breaking change we found when migrating from 1.5.8 to 1.6: given an ActionBean with a method annotated with @HandlesEvent but without any @DefaultHandler, Stripes 1.5.8 raised a warning on the logs, whereas 1.6 raises an exception and prevents the application from starting. The only "special" thing with all of our actionbeans is that they all use @UrlBinding, so I'm not very sure if that has something to do with the exception.

br, juan pablo

[vankeisb]

Hi Juan Pablo,

Feel free to send a PR for 1/.

For 2/ I think I'd have used the same workaround, makes sense. But in case 1/ is fixed, you agree that we don't need the old class ? It wasn't meant to be used directly, other than by the fwk itself, so it's no problem if we don't keep it I guess ?

Now for the last issue (no @DefaultHandler on the action), I'm not sure.

On one hand, it seems natural that an action should have a default handler. On the other hand, if you specify the event name in all of your requests, then you don't need a default handler...

I think the warning (1.5.8 behavior) is better.

@rgrashel @foxdonut @bengunter what do you think ?

[juanpablo-santos]

Hi @vankeisb,

just attached the PR.

Re. 2/, I don't it's necessary now, as it's been already taken out, and the spring objectfactory supersedes it, so need for it

br, juan pablo

[vankeisb]

Hi Juan Pablo, thanks for the PR, I'll have a look. I just ran into the last issue mentioned in this thread (no default handler), and I think it deserves another ticket.