File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSF and the fly likes h:commandlink request uri does not change Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "h:commandlink request uri does not change" Watch "h:commandlink request uri does not change" New topic
Author

h:commandlink request uri does not change

Gina vernon
Ranch Hand

Joined: Jan 16, 2009
Posts: 108
I have the following issue with h:commandlink tag:

My dir structure is as follows
_App Contx
|
|_ _css
|
|_ _protected pages
|
|
Welcome.page

I have page (pg1) in the protected folder that uses an h:commandlink. The link uses an action method and jsf navigation rules to navigate to another page(pg2) in the protected folder.
A custom filter filters all protected requests. When I click the link in pg1, the rquest uri that is sent to the filter is ../protected/pg1 instead of ../protected/pg2. So, the user stays in pg1.
I tried various usecases- I moved pg1 out of the protected folder and the link works.I used and it works. Only when both pages are in the same folder the URI does not change.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

If what you're talking about is the URL displayed in the browser navigation bar, that's NOT a pointer to a specific View, it's a handle on the JSF context.

To get the URL to update, add the "redirect" element to the navigation action. it's extra overhead, but it does change the displayed URL, as well as establishing the absolute View context, which is important for bookmarking and for container-managed security.


Customer surveys are for companies who didn't pay proper attention to begin with.
Gina vernon
Ranch Hand

Joined: Jan 16, 2009
Posts: 108
Tim, I do have the redirect tag in the navigation rule. This happens inspite of it. When the filter intercepts the request generated by clicking the link, the URI of the request is pg1 not pg2. Again I do have the redirect in the navigation rule.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

If I read that properly, that's because you're applying the filter on the direct return from the form, and the redirect hasn't been applied yet. If you look closer, I think you may see 2 passes through the filter, and the second pass will be the redirected one.
Gina vernon
Ranch Hand

Joined: Jan 16, 2009
Posts: 108

Tim, negative on that. There is only one pass through the filter. I debugged it very closely several times. And even if it somehow did go through twice, the request should go to the second page, it doesn't. It goes into an unending loop in the filter. Here is the filter code

Gina vernon
Ranch Hand

Joined: Jan 16, 2009
Posts: 108
Nevermind. It works now.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

You know, I think it must have been 3 whole days since I've make a comment on why Do-It-Yourself security systems are not only an oxymoron, but expensive to boot.

OK. got that out of my system.

There are limits to what I can deduce here without having actual hands on the code and running app, but there are a couple of observations I can make.

One of which is that you're testing for ".xhtml" strings. Normally, the URL doesn't have an "xhtml" in it, since that's a war resource file extension, not a URL component. My webapps normally end their JSF URLs with ".jsf", which web.xml has been instructed to resolve by locating and processing the corresponding ".xhtml" file. A lot of people confuse resource component names with URL component names, since syntactically, they're pretty much the same. However, functionally, they're as different as apples and tomatoes.

Which means, in short, that I'm not sure whether you're examining each and every URL that comes through the filter in your debugger. I think there should be some other indications than what you're reporting and I don't know if they're not there or if you simple don't see what you're not looking for. You might want to write all the URIs out to the log for debugging purposes.

Couple of basic programming hints, though. Doesn't affect behaviour but it makes code simpler.

1. If you say if( "yes".equals(authenticated) ), you'll save a few keysrtokes and a test, since "yes".equals(null) returns false. No need for a separate null test.

2. You should be able to replace requestedPage.indexOf("pg2.xhtml")>-1 with requestedPage.endsWith("pg2.xhtml"). Again, a little tidier and perhaps a tad more efficient. However, as I said above, "xhtml" is normally a resource file suffix, not a URL component, so I'd expect this clause to always return false.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: h:commandlink request uri does not change