Hi Jim,
That's an interesting problem. I've investigated this and I'll do my
best to explain what I've found. Ben, please correct me if I'm wrong
(I mention Ben because he is the creator of the DynamicMappingFilter,
but others who find inaccuracies below are of course also welcome to
point them out).
First, like you said, when using the standard Stripes configuration,
everything works as expected. It's important to understand that in
this case, you have *something* in web.xml that differentiates
requests that go through Stripes from all the other requests, be
it *.action, /action/*, and so on. The default is *.action, in which
case, index.jsp forwarding to /Index.action will put the request
through Stripes, which eventually calls
NameBasedActionResolver, which in turn has the mechanism for handling
an Action Bean not found, that is, to look for a JSP as a final
attempt. This is where you have inserted your code to prepend
"/WEB-INF/jsp" to the paths, and it will find /WEB-INF/jsp/index.jsp.
So far, so good.
Now, with DMF, things are different. *Every* request goes through DMF,
and DMF has to determine whether to pass the request on to Stripes. To
decide that, DMF has to look ahead and ask the ActionResolver for a
"sneak preview", asking, "will this path map to an Action Bean"? More
specifically, DMF asks the ActionResolver for the Class of the Action
Bean that *would* handle the request, using a call to
getActionBeanType(String path). Only if that returns a non-null value
does the DMF actually put the request through.
The difference is that in the first scenario, the request is already
in Stripes because it matches the .action pattern (or whatever you've
mapped in web.xml). So it is assumed that an Action
Bean will match, and if it doesn't, NameBasedActionResolver says "wait
a minute, let me see if I can find a matching JSP." Your code gets
called to look in /WEB-INF/jsp.
In the second scenario, the request is not necessarily a Stripes
request. When the DMF sees that getActionBeanType() returns null, it
does not pass the request on to Stripes, and your code never gets
called.
I hope that wasn't too confusing. The good news is that you can get
around this by overriding getActionBeanType() and calling
handleActionBeanType() to see if there's a matching JSP. If there is,
you pat DMF on the shoulder reassuringly and say, "it's OK, I'm confident
the request will work, go ahead and put it through Stripes" by returning
a non-null value from getActionBeanType(). The custom ActionResolver
becomes:
public class MyActionResolver extends NameBasedActionResolver {
@Override
public Class<? extends ActionBean> getActionBeanType(String path) {
Class<? extends ActionBean> cls = super.getActionBeanType(path);
if (cls == null) {
ActionBean bean = handleActionBeanNotFound(null, path);
if (bean != null) {
return bean.getClass();
}
}
return null;
}
@Override
protected List<String> getFindViewAttempts(String url) {
List<String> defaultViews = super.getFindViewAttempts(url);
List<String> customViews =
new ArrayList<String>(defaultViews.size());
for (String view : defaultViews) {
customViews.add("/WEB-INF/jsp" + view);
}
return customViews;
}
}
I tried this out and it works with DMF and your /WEB-INF/jsp/index.jsp
example. Note that you'll see an error logged by
AnnotatedClassActionResolver - this is normal, because the error is
logged before the exception is thrown. But the exception is then
caught by NameBasedActionResolver which does its
handleActionBeanNotFound() method, so all ends well.
Hope that helps. Let me know if that made any sense!
PS I hope you are enjoying the book.
Cheers,
Freddy
-
- Hi All,
-
- Here is what I am trying to accomplish:
-
- 1) Use DynamicMappingFilter
- 2) Keep all JSP's under WEB-INF
- 3) Take advantage of the DefaultViewActionBean so that I can stay
- true to the pre-action pattern and avoid directly accessing JSPs
- while not having to create an action bean just to forward to the JSP
- 4) Allow my default document (ex: index.jsp) to use the
- DefaultViewActionBean
- and resolve to index.jsp under WEB-INF
-
- I am using a couple of concepts from the Stripes book. The first, on
- page 288...overriding a method in NameBasedActionResolver to make it
- check the WEB-INF directory for a jsp matching the request. Here is
- the code:
-
- public class MyActionResolver extends NameBasedActionResolver {
- @Override
- protected List<String> getFindViewAttempts(String url) {
- List<String> defaultViews =
- super.getFindViewAttempts(url);
- List<String> customViews =
- new ArrayList<String>(defaultViews.size());
- for (String view : defaultViews) {
- customViews.add("/WEB-INF/jsp" + view);
- }
- return customViews;
- }
- }
-
- I put this in my extensions directory and when the server starts up,
- it is being loaded. I tried this with the typical stripes config (no
- dynamicmappingfilter) and this works as advertised. However, when I
- replace the standard config and use DynamicMappingFilter, it seems
- that the actionresolver is no longer being
- called. From the documentation on DMF, it seems that it should be.
- It says the DMF follows this process:
-
- " This filter takes the following approach to determining when to
- dispatch an ActionBean:
-
- 1. Allow the request to process normally, trapping any HTTP
- errors that are returned.
- 2. If no error was returned then do nothing, allowing the request
- to complete successfully. If any error other than 404 was returned
- then send the error through. Otherwise ...
- 3. Check the ActionResolver to see if an ActionBean is mapped to
- the URL. If not, then send the 404 error through. Otherwise...
- 4. Invoke StripesFilter and DispatcherServlet
- "
-
- At step 3, it should use my actionresolver to check to see if it can
- find an actionbean (in this case, the DefaultViewActionBean).
- However, when debugging, it never seems to be accessed.
-
- If anyone can provide some insight on this, I'd be grateful.
-
- Thanks in advance!
-
- J
-
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
