How do I combine Path params with Query params?

Splash Forums PrettyFaces Users How do I combine Path params with Query params?

This topic contains 27 replies, has 3 voices, and was last updated by  Lincoln Baxter III 8 years ago.

Viewing 13 posts - 16 through 28 (of 28 total)
  • Author
  • #20503

    Correct, this is Servlet 3.0 only! :-)



    What url-pattern will filters down the chain match against – original request URL, or the re-written “pretty” URL?

    Any recommendations on filter order – run PrettyFilter first, or Hibernate first?



    Looks like the order does not make a difference (?), and that it is the re-written URL that HibernateFilter sees regardless of order, and that I *don’t* want REQUEST dispatcher enabled in the Hibernate filter – only FORWARD (well, unless I have some non-pretty URLs or other resources that need an open Hibernate session).

    I couldn’t figure out why after the first request (which is intercepted by PrettyFaces and results in loadAction) I get a bunch more (seemingly async, bypassing PrettyFilter, but intercepted by HibernateFilter). I’m still not sure what in JSF2/PrimeFaces lifecycle causes it, but without REQUEST dispatcher enabled on HibernateFilter, it is called just once per page load (ignoring AJAX requests, that is), after PrettyFilter forwards the request to the filter chain.



    Never mind, I do need Hibernate session for both cases, and the extra requests came from loading PrimeFaces resources, which is also done via *.jsf, matching url-pattern in web.xml filter-mapping.

    I moved my report-related *.xhtml files to their own subdirectory, so that a single url-pattern in web.xml filter-mapping could detect both “pretty” and regular URLs and then open a Hibernate session for such requests (but would exclude PrimeFaces resources, also loaded via *.jsf requests). So, both /report/reportTag or /report/report-whatever.jsf?reportTag=anything should work.

    However, something major changed between versions 3.1.0 and 3.2.0. With my setup, PrettyFaces could not find the viewIds for mappings like

    <url-mapping id="report">
    <pattern value="report/#{reportBean.reportTag}" />

    With the same configuration using 3.1.0, I see a different issue: for some reason, it sets reportTag to ‘dashboard.jsf’ in the example above, rather than setting it to the matched pattern (e.g. ‘main’ for ‘http://localhost/report/main’). What’s going on? It gets confused by multiple slashes in view-id value?


    Can you explain “cannot find the viewId” ? What is the error message?


    Also, maybe you could debug PrettyFilter and see what is really going on? That would be good to know if it is a PrettyFaces bug or not.




    By not finding viewId, I mean I get HTTP status 404: The requested resource (/crest/report/blah) is not available (no matter what I use for “blah”). As I reported, this happens only with 3.2.0, but not with 3.1.0. Not sure how to debug it further.

    Using 3.1.0 and with no other changes, I get a different error, a NullPointerException in my own code. I debugged it and noticed that it is thrown when I call reportBean.loadReport because reportBean.reportTag is set to an invalid value: to ‘dashboard.jsf’ (not ‘/report/dashboard.jsf’), rather than the path param that my pattern should have matched. The only thing that could cause this, I think, is the fact that my view-id contains a subdirectory. Could you please test this with 3.2.0 and 3.1.0?


    Yes, this behavior has been well tested, which is why I am surprised you are having issues with it. It would help if you could create a small sample application that reproduces your problem – sorry for the inconvenience.

    If you need to get a sample-app created quickly, you might consider using Seam Forge to generate a basic web-application:–rad-java

    In order to debug PrettyFilter, you’d need to make sure you have the PrettyFaces sources available to you in your IDE. Set a breakpoint at the first line of PrettyFilter.doFilter(...), start your server in debug mode, and step through as you try to access the page you are having trouble with. This should cause the breakpoint to activiate, at which point, just take a look at what PrettyFaces is doing in the filter, and go from there.

    I’m sorry I can’t be of much more help here, but I am not working with a lot of information :)

    In order to help you otherwise, please post relevant parts of your web.xml, pretty-config.xml, and also show us where your files are located in the application itself.





    Found my problem: my idea to move report-related *.xhtml files to their own subdirectory with the same name as the pattern that I was matching in pretty-config wasn’t so bright after all.

    As I wrote, I wanted to have a single url-pattern in web.xml filter-mapping that could detect both “pretty” and regular URLs and then open a Hibernate session only for such requests, so that both /report/reportTag or /report/report-whatever.jsf?reportTag=anything would work.

    What I didn’t think of was that requesting /report/report-whatever.jsf also matches my pattern in pretty-config (<pattern value=”report/#{reportBean.reportTag}” />) and sets reportTag to ‘report-whatever.jsf’. And then with an invalid reportTag, page action would result in an NullPointerException, as I already determined.

    However, when I renamed my subdirectory with *.xhtml files from “report” to “reports”, so that “non-Pretty” requests would no longer match that pretty-config pattern, the issue was solved. Of course, I also had to add a second url-pattern to my Hibernate filter. Now it looks like:

    <filter-name>Hibernate Filter</filter-name>
    <filter-name>Hibernate Filter</filter-name>



    Sorry I guess I was unclear on the details – or I would have suggested just this! Every once and a while the Java EE specs get something right ;)



    If you are not too tired of me yet… Using 3.2.0:

    <url-mapping id="report">
    <pattern value="/report/#{/[a-zA-Z]+[\w-]*/ reportBean.reportTag}" />

    <url-mapping id="report-reportDate" parentId="report">
    <pattern value="/#{/\d{8}/ reportDate : reportBean.reportDateString}" />

    This doesn’t work: HTTP Status 404 – /report/main/20101223

    If I do not try to be fancy and just spell out,

    <url-mapping id="report-reportDate">
    <pattern value="/report/#{/[a-zA-Z]+[\w-]*/ reportBean.reportTag}/#{/\d{8}/ reportDate : reportBean.reportDateString}" />

    then it works fine.


    So it looks like the parentId is not working? Interesting…

    Any chance you could debug and see what the compiled URLMapping object has for a pattern? Basically I’m asking if the PrettyConfig has the correct information in it, or if it’s being incorrectly assembled somehow.

    I’ll try to do some testing for this as well.


    PS. Not tired of you :) This shouldn’t break so easily!

Viewing 13 posts - 16 through 28 (of 28 total)

You must be logged in to reply to this topic.

Comments are closed.