Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: Release 1.5
-
Fix Version/s: Release 1.5.2, Release 1.6
-
Component/s: None
-
Labels:None
-
Environment:MS Window XP, JDK 1.6, Jboss 5.0.0GA
Description
-Dropping the stripes-example.war (from stripes-1.5.zip) into JBoss 5.0.0GA (EG: jboss-5.0.0.GA\server\default\deploy)
-Start up server and open stripes-examples (http://localhost:8080/stripes-examples)
-Click the quick start link to the simple calculator
-Enter two numbers and press the Add button
Got the following stacktrace:
net.sourceforge.stripes.exception.ActionBeanNotFoundException: Could not locate an ActionBean that is bound to the URL [/examples/quickstart/Calculator.action]. Commons reasons for this include mis-matched URLs and forgetting to implement ActionBean in your class. Registered ActionBeans are: {/controller/DefaultView.action=class net.sourceforge.stripes.controller.DefaultViewActionBean}
net.sourceforge.stripes.controller.AnnotatedClassActionResolver.getActionBean(AnnotatedClassActionResolver.java:325)
net.sourceforge.stripes.controller.NameBasedActionResolver.getActionBean(NameBasedActionResolver.java:264)
net.sourceforge.stripes.controller.AnnotatedClassActionResolver.getActionBean(AnnotatedClassActionResolver.java:279)
net.sourceforge.stripes.controller.DispatcherHelper$1.intercept(DispatcherHelper.java:106)
net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:158)
net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113)
net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155)
net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:74)
net.sourceforge.stripes.controller.DispatcherHelper.resolveActionBean(DispatcherHelper.java:102)
net.sourceforge.stripes.controller.DispatcherServlet.resolveActionBean(DispatcherServlet.java:245)
net.sourceforge.stripes.controller.DispatcherServlet.doPost(DispatcherServlet.java:148)
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:246)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
Attachments
Activity
I've created a patch for this issue as well which is perhaps a bit more acceptable to the project developers. ResolverUtil assumes that the classloader wil give it file: and jar: urls to work with, but does not state this assumption anywhere. Rather than assuming a particular few url schemes and dealing with them in prescribed ways, the patch makes ResolverUtil go through the URL's openStream() method to get access to the jar in all cases except for the specific case of a file: url that points to a directory. This makes it possible for stripes to correctly scan classes that are exposed using unanticipated url schemes by deferring jar streaming logic to whatever protocol handler the container has registered for it.
There are still a couple of special cases to be concerned about. One is the aforementioned file: url pointing to a directory, which is handled the same as before. The other case is handled in loadImplementationsInJar, where parent is stripped from the end of the stringified url under two conditions: 1) parent is the tail of the stringified url, with nothing following it except optionally a slash 
and 2) it is preceeded by ".jar" and an optional delimiting exclamation point 
. This processing used to occur in find, and appears to have been designed to deal specifically with jar: urls, though the original implementation was applied to all urls. The new munging is more precise about what it will strip from the url, so that the jar: case is still correctly handled. The exclamation point is optional in the regex replace because JBoss VFS, in its infinite wisdom, decided to forego delimiting the boundary between jar and jar contents in vfszip: urls.
and 2) it is preceeded by ".jar" and an optional delimiting exclamation point . This processing used to occur in find, and appears to have been designed to deal specifically with jar: urls, though the original implementation was applied to all urls. The new munging is more precise about what it will strip from the url, so that the jar: case is still correctly handled. The exclamation point is optional in the regex replace because JBoss VFS, in its infinite wisdom, decided to forego delimiting the boundary between jar and jar contents in vfszip: urls.
jboss server log