java.lang.IllegalStateException: PhaseBinding does not support retrieval

Splash Forums Rewrite Users java.lang.IllegalStateException: PhaseBinding does not support retrieval

This topic contains 18 replies, has 3 voices, and was last updated by  Christian Kaltepoth 8 years, 5 months ago.

Viewing 15 posts - 1 through 15 (of 19 total)
  • Author
  • #24435


    Hi there1
    Anyone please help, simple faces bean and page:

    @Join(path = "/test/{bookId}/", to = "/faces/pages/pub/test.xhtml")
    public class BookBean {
      private String bookId;

    and a page:

    <html xmlns=""
          <h:outputText value="ID: #{bookBean.bookId}"/>
          <h:link outcome="/pages/pub/test.xhtml">
            <f:param name="bookId" value="#{bookBean.bookId}"/>

    which doesn’t get rendered because of the h:link causing the subj.
    Besides, I do not understand what is meant by before or after phase parameter in @Deferred annotation, how the phase is determined exactly? In the sources I cant even find where @org.ocpsoft.rewrite.faces.annotation.Phase.getPhaseId() is somehow compared to the current phase of the FacesContext.

    UPD: rewrite-servlet-2.0.4, rewrite-integration-faces-2.0.4

    • This topic was modified 8 years, 5 months ago by  0swald.


    Looks like I’ve fixed the bug. Class org.ocpsoft.rewrite.util.ParameterUtils, method performRetrieval(final Rewrite event, final EvaluationContext context, final Parameter<?> parameter) has been marked as FIXME by Linkcoln, so I’ve added an obvious fix regarding supportsRetrieval() :

          // FIXME Should not have to worry about order here.
          for (Binding binding : bindings)
             if (result == null && !(binding instanceof Evaluation) && binding.supportsRetrieval())
                result = binding.retrieve(event, context);

    Lincoln, Christian, please let me know if I’m right here, I’ll submit a patch.

    • This reply was modified 8 years, 5 months ago by  0swald.
    • This reply was modified 8 years, 5 months ago by  0swald.

    Hey Oswald!

    Thanks so much for digging down to the root of this problem! I’m not actually sure if this is correct or not, but please do go ahead and submit the patch! I’ll play around with it. (I’m on vacation for a while longer, but I should be able to find the time.) Just send us your pull request and I’ll check it out!

    Thank you (yet again!)


    PS. The stuff you are looking for is in RewritePhaseListener 🙂 The before and after phases map to each JSF lifecycle phase for which the deferred action or binding should be executed.



    Hi Lincoln,

    yes, I’ve already found RewritePhaseListener )) Guided by Christian’s idea of creating own annotations, I’ve spent almost a week examining the code and finally managed to create my own set of annotations intended purely for JSF – my @Parameters support class inheritance, are deferred by default (as well as URL actions), they have optional postback flags (not standalone annotations), and, finally, in my case several @Joins are going to be allowed per class, testing it right now. So now my JSF integration lib requires rewrite-servlet only, though it uses a substantial set of classes from rewrite-intergration-faces, and, I must say, I’m pretty happy with new Rewrite)))


    Awesome! I’m glad to hear that you are liking things! We really need to work on more documentation – it’s in the works, but lots to do. Do you think your changes are worth putting into the rewrite libraries themselves, or are they more for your specific case? Christian? What are your thoughts here?



    Lincoln, these aren’t actually ‘changes’, this is a library built on top of rewrite and rewrite-integration-faces – actually a more JSF-friendly substitution for the latter, a dozen of classes (annotations, handlers and utility ones) making the Rewrite more convenient for JSF projects, that’s all, very much like the old prettyfaces 3.x. I did it because I totally disagree with the design, core functionality, tools and means provided by rewrite-integration-faces, no offense))

    And yes, sure, I will publish my sources so you could have a look at them, probably in a day or two.
    PS: what about my pull requests? I’m new to github and could miss something out when submitting patches.



    Lincoln, finally I’ve published my library, here it is: , feel free to reuse the code if you and your team find it interesting. I did my best commenting the sources and learning git))


    Thanks Oswald!

    Really nice work! How did you find the Annotation APIs?

    I’m interested in why you disagree with our design, and also what you found unappealing about the rewrite-config-prettyfaces module, which provides 100% backwards compatibility with PrettyFaces (unless we have made a mistake somewhere) 🙂

    I think that we may soon release a PrettyFaces 4 library, which simply packages all of the necessary Rewrite JARs into one (all you need) JAR, that PrettyFaces has typically provided. What do you think about that?

    I’m also sorry that I haven’t gotten to look at your pull request (I think Christian resolved it?) I have been on vacation in Canada this past week, and have been trying to stay away from my computer until now.



    Also, this PrettyFaces 4 uber-jar would of course be backwards-compatible with PrettyFaces 3.



    Hi Lincoln,
    Finding annotation API was a piece of cake, just Alt+F7 (find usages) on @Join in Netbeans plus spi packages which gave me the hint)) Using SPI was excellent idea btw.

    As for rewrite-config-prettyfaces, I was just afraid that was just a compatibility layer with less support and no further development. Now, when I have all the sources, I understand that I might have been wrong. But, being wrong, I still don’t understand why would you need to develop both the rewrite-config-prettyfaces and rewrite-integration-faces and why would you create new faces-specific annotations like @Deferred or @IgnorePostback when you already have Prettyfaces at hand? Maybe I’m still lacking the overall picture of the project and don’t get where is it going with regard to faces support.

    Regarding why I don’t like the design of rewrite-intergation-faces – mostly because it does not support class inheritance and does not allow multiple @Join annotations, it’s one of the major design flaws, not a MVC style at least. Plus the necessity of mixing annotations from both rewrite-servlet and rewrite-integration-faces, with one of them (@Deferred) being always necessary when developing JSF – a bit clumsy approach imho.


    Hmmm, well I think you’ve convinced me that it’s important to release a stack dependency “org.ocpsoft.prettyfaces:prettyfaces:4.0.0” that includes both rewrite-servlet, rewrite-integration-faces, and rewrite-config-prettyfaces (maybe also a few others.) This way folks could simply include a newer version of prettyfaces and not have to change dependencies too much.

    What are your thoughts about this?

    Also, regarding rewrite-integration-faces, it was intended as a lower-level module that could be used to construct/re-implement prettyfaces over time as pieces of the functionality are re-implemented, but it’s going slowly since we don’t have that many contributions. However… looks like you have implemented a lot of what we need, so maybe it would be worth porting the current rewrite-config-prettyfaces to use your code instead of the current adapter design.

    Thoughts on that as well?



    Lincoln, sorry for late response, was busy to death.

    1. Actually I’m not the right person to give an advice on how to reshuffle modules or their dependencies cause my interests lie solely with JSF and I have very little knowledge of Spring or whatever else frameworks your project is targeting. But yes, that’d be great if users could have a one-stop Faces Rewrite library, and I see no cons why it shouldn’t look like the old good PrettyFaces, which still remains unbeaten even after the release of rewrite-integration-faces, imho.

    2. I don’t have much knowledge on what current rewrite-config-prettyfaces if capable of, haven’t tested it, but if my lib covers the necessary functionality, then yes, sources are free for reuse. I cant promise much of my time, though I’d be proud to contribute and look after/be responsible for some pieces of the Rewrite project. Then you take the lead, I’ll need some guidance on how to start.


    Hey 0swald,

    first of all, thank you very much for your feedback. I’m sorry that I didn’t answer earlier. I’m also very busy. 🙁

    I’m really happy to hear that you like the annotation SPI. We built it this way to allow users to build their own annotations. And it’s great to see that someone is using it with success. 🙂

    I’m really interested to have a deeper look at your easypack project. It sounds very interesting.

    Our idea while working on all this was to keep as much as possible independent from JSF. That’s where the idea of a separate @Deferred annotation came from. And yes, we also discussed if we should add a separate parameter annotation instead of adding @Deferred. We decided to go this way because it seemed cleaner and because there is not such a big difference between:

    @Deferred @Parameter
    private String param;


    private String param;

    BTW: If you are using a standard JEE stack and therefore use CDI instead of the JSF managed beans (which is best practice) you will have to use @Deferred only for view-scoped beans. For all other beans it should work without it.

    Regarding the missing support for class inheritance: I wasn’t aware that this isn’t supported yet. I thought we implemented it. But if it is missing, we should add it. I’ll create an issue for this.



    Issue for tracking the class inheritance topic:

Viewing 15 posts - 1 through 15 (of 19 total)

The forum ‘Rewrite Users’ is closed to new topics and replies.

Comments are closed.