Freddy D. <[EMAIL PROTECTED]> writes:
>
> 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=/
>
Hi Freddy,
First off, you've done an amazing job on the book. I think it's a perfect
compliment to anyone who is using the framework. The examples you've provided
are very real-world applicable and have saved me a ton of time.
As for the issue at hand, what you wrote makes sense. Thank you for looking
into
it. Unfortunately, there still seems to be an issue. Here is what I am
seeing...
When I navigate to a url that maps to an existing action bean, I get an
exception:
ava.lang.StringIndexOutOfBoundsException: String index out of range: 0 at
java.lang.String.charAt(String.java:558) at
net.sourceforge.stripes.controller.NameBasedActionResolver
.getFindViewAttempts(NameBasedActionResolver.java:368)
at
com.greekd.app.ext.BaseActionResolver
.getFindViewAttempts(BaseActionResolver.java:31)
at
net.sourceforge.stripes.controller
.NameBasedActionResolver.findView(NameBasedActionResolver.java:321)
at
net.sourceforge.stripes.controller.NameBasedActionResolver.
handleActionBeanNotFound(NameBasedActionResolver.java:292)
at
com.greekd.app.ext.BaseActionResolver.
getActionBeanType(BaseActionResolver.java:18)
With that said, I fired up the debugger and started stepping through the two
methods you provided. When the request comes into getActionBeanType, the path
is
correct. As an example, I have an actionbean bound to "/login". When I go to
that page, "/login" is being passed into getActionBeanType and the method
returns null since the actionbean was found. However, instead of ending there,
another request comes into getActionBeanType with a path of "/" and that's
where things go bad. It can't find an actionbean mapped to that binding, so it
calls getFindViewAttempts and bombs on the first line with the aforementioned
exception.
As I mentioned, the above test was for a url that *did* have an actionbean
bound
to it. When I tried a url that was not bound, I got the same error, but I
noticed that when I disabled my interceptor (loginintercptor from the book),
it
worked. After disabling the interceptor, I tried the url to the bound
actionbean, but that still did not work properly.
I am curious to see if you can reproduce any of this.
Again, thank you for your help!
Jim
-------------------------------------------------------------------------
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
