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 6 years, 10 months ago.

Viewing 4 posts - 16 through 19 (of 19 total)
  • Author
  • #24625


    Hi Christian,
    yes, I do understand how difficult it was create annotations for all cases, especially in such a zoo of JSF and CDI beans, I was thinking of it too, and here is my proposal:

    1. The Rewrite engine checks the bean annotation (CDI or JSF)
    2. If it’s JSF then the engine automatically creates all the actions and bindings as deferred after the RESTORE_VIEW phase.
    3. If the user wants to fine-tune the phase, then he uses a stand-alone @Phase(before=, after=) annotation or something like that.

    As for class inheritance, the only thing you could do is to get rid of the action and parameter annotation handlers and start examining the bean class via reflection as I did in my AbstractClassHandler<A extends Annotation>. This approach isn’t flawless – when examining the class you should already know all the method- or field-level annotations you might encounter in the class. And even worse – all other non-class-level enriching annotation handlers become to no use.

    PS: and yes, I do actively use view-scoped beans when it comes to ajaxfied page, there’s no CDI equivalent for such cases.

    • This reply was modified 6 years, 10 months ago by  0swald.

    Thanks Christian, and yeah, I think maybe we could use Oswald’s code to help porting the PF3 codebase completely over to rewrite, since right now it’s pretty much the same code with an adapter. We have good tests for it, so I think this should be an interesting exercise.


    Well, instead of ViewScoped, you could use ConversationScoped, but that leads to other problems and actually has similar problems to the ViewScoped bean since it is implemented very poorly for JSF.



    Thank you very much for your suggestion. I also thought about this in the last days. Actually I like the idea of some kind of auto-detection regarding the deferral. I think this is possible.

    My thoughts on the implementation:

    Currently the ParameterHandler writes the binding to the context and then the DeferredHandler wraps it and puts it back into the context. The ParameterHandle is then able to use this wrapped binding. The current implementation isn’t very nice IMHO.

    One idea would be to define an SPI which the ParameterHandler uses to allow other modules to wrap bindings and operations. The JSF implementation of the SPI could then decide whether deferral is necessary or not. Either by checking for the @Deferred annotation (for backwards compatibility) or by checking the annotations on the class to identify JSF managed beans.

    Essentially this would mean that @Deferred isn’t processed by an annotation handler any more. Instead there would be a “binding/operation wrapper SPI”.

Viewing 4 posts - 16 through 19 (of 19 total)

You must be logged in to reply to this topic.

Comments are closed.