Christian Kaltepoth

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 1,807 total)
  • Author
    Posts
  • in reply to: Integration with Spring Boot not working #27626

    Good question. How do you typically lookup the WebApplicationContext in Spring Boot? Maybe the ContextLoader isn’t registered automatically?

    Could you post the full stack trace please?

    in reply to: Components not rendering when url mapped #27598

    How did you map your FacesServlet? Maybe you have to create the mapping for /user/user-view.jsf or /faces /user/user-view.xhtml instead.

    Also, please update to 3.4.1 which has been released just after 3.4.0 to address a packaging issue with the JARs.

    in reply to: Multiple JSF Applications found on same ClassLoader #27587

    Not sure if this warning is really referring to PrettyFaces. However, if everything is working fine now, this doesn’t matter. 😉

    in reply to: Multiple JSF Applications found on same ClassLoader #27585

    No, this warning isn’t caused by Rewrite and I don’t think that it prevents your rewriting from working correctly.

    in reply to: pretty url broken #27583

    I guess you need something like this:

    String rewritten = externalContext.encodeRedirectURL( path, new HashMap<>() );
    externalContext.redirect(url + rewritten);
    

    Outbound URLs are rewritten using HttpServletResponse.encodeRedirectURL(), so if you are doing redirects manually, you will have to call this method yourself.

    BTW: I think you don’t need url in your code. Just do:

    externalContext.redirect(request.getContextPath() + rewritten);
    
    in reply to: pretty url broken #27581

    Why are you using this weird way of redirecting via ExternalContext? Why not just:

    return "/pages/public/isralib/publication/view.xhtml?publicationId=8123&pubCategoryCode=PBB&faces-redirect=true";
    
    in reply to: pretty url broken #27578

    Please share your configuration, which dependencies your are using and the relevant parts of your code.

    in reply to: hide extra parameter #27575

    As I said earlier: If you remove the parameter from the URL, the client won’t send it, so it won’t be available in your bean.

    Why don’t you just use a SEO URL like this:

    /pages/journal/view/1
    

    From the SEO perspective this is even better, because the term “journal” is part of your path.

    in reply to: hide extra parameter #27573

    You cannot simply hide a query parameter if your application requires it. If it is not present in the URL, the browser won’t include it in the request and therefore your app won’t work.

    If you application does not require it, simply don’t send it.

    in reply to: hide extra parameter #27571

    Could you explain “unfortunately I need to send it” a bit more?

    in reply to: hide extra parameter #27569

    The query string is separated by the path using a ?. So the actual URL you posted is correct. You expected URL is incorrect.

    in reply to: navigate to other page with same pattern #27566

    You could use two different patterns:

    /app/search/P#{code}
    

    and

    /app/search/J#{code}
    
    in reply to: @Join, @RequestAction and dispatch #27561

    Thanks for sharing the code.

    To be honest, I don’t have an idea why the annotation case isn’t working as expected. I don’t see any obvious error here. Perhaps the inheritance is causing problems? I’m not sure if having @Parameter and @RequestAction in an abstract base class will work without problems.

    However, apart from these problems, if I were you, I would prefer using <f:viewParam> and <f:viewAction> over the Rewrite annotations. In my my experience it is preferable to use the features provided by core JSF instead of using too much of the fancy features of 3rd party libraries (including Rewrite). If you use the core JSF features to implement the parameter binding and the action method invocation, you could in theory even simply drop Rewrite from your project and it should still work fine (even if the URLs aren’t pretty any more after that).

    Or is there any specific reason why you would like to use the annotations? You can BTW also use <f:viewParam> and <f:viewAction> and the Rewrite @View annotation. That will work fine.

    However, if you want to find out why the annotations aren’t working in the dispatch case, you will have to dig deeper into the Rewrite code, which can be very difficult. I know this from personal experience 🙂

    in reply to: @Join, @RequestAction and dispatch #27559

    You say that your use case is working fine if you are using Join.path().to() in the central Rewrite configuration but not if you are using annotations? Could you show us example code for both cases?

    IMHO your use case only works if you use .withChaining() on the join, which is currently not supported for annotations.

Viewing 15 posts - 16 through 30 (of 1,807 total)

Next Entries »