Announcement Announcement Module
Collapse
No announcement yet.
Problems using Spring in a JSF/icefaces Application with "Reverse-Ajax" Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problems using Spring in a JSF/icefaces Application with "Reverse-Ajax"

    Hello,

    i use spring in a jsf-webapp together with the JSF 1.2 RI from Sun, Facelets and a Framework called icefaces. We use Spring because of its very convient and powerful features, for our controllers, services, and in combination with hibernate and many other great integration-features we are really happy with our decision to use spring... but recently we come up against a problem with the combination spring/jsf/icefaces.

    In icefaces you can use so called Renderables to realize a "reverse ajax" call. They call it server initiated rendering, and it is one of icefaces' unique features, to send updates to the client based on server-side changes.

    It is possible in icefaces-applications to render individual users UI, a group of Users UI's, or all users UI's, triggerd on single changes or in periodic cycles. The typical usage is that a session-scoped, managed-bean implements a renderable-interface. And after defining a render-interval for example, the asynchronous rendering is done by a (Application-Scoped) RenderManager which uses a RenderHub for queueing Renderables and executes the rendering with the help of a configurable thread pool.

    The above described feature works very well, if all managed beans are defined inside the faces-config.xml only and it stops working if we use spring managed beans as controllers (what we normally do :-). So far we assemble our application with spring only (managed beans are in different spring scopes and get their services by DI which again get their daos by DI... and so on) and it's not wanted to use only "normal" (in faces-config.xml defined) managed beans... in the future we want to use both: the icefaces server initiated rendering AND spring.

    To outline the problem a little bit more: On one hand we use the RequestContextListener (we tried it with the Filter as well) on the other we use the DelegatingVariableResolver to "wire" jsf with spring. In almost all cases the trio "spring/jsf/icefaces" works very well for us, all spring-managed controller-beans are perfectly useable/visible. But if a asynchronous rendering from one of RenderHubs worker-threads starts, the well know "IllegalStateException: No thread-bound request found..."-Error occurs. My assumption is: as the render-call comes from it's own thread and not a normal client-request, the listener isn't passed and therefor the spring managed beans aren't accessible for the renderResponse-Phase, and the attempt to recreate them fails with this exception ... i have seen (while debugging through icefaces) that on creation of their PersistentFacesState a reference to the web app classloader is memorized, and this classloader is later tied to the Renderables thread for the reason, that render-calls outside the context of the web app are able to access the JSF artifacts... but it seems that this works with jsf-managed-beans only.... to be honest, i am not really a spring-specialist, so i would like to ask if anybody has any idea what can be done, is there a possibility to do what the RequestContextListener is doing during a client-request?

    any feedback is highly appreciated ... is it helpful to provide the sourcecode of an example?

    many thanks, many greetings
    Jens

  • #2
    Originally posted by snej View Post

    To outline the problem a little bit more: On one hand we use the RequestContextListener (we tried it with the Filter as well) on the other we use the DelegatingVariableResolver to "wire" jsf with spring. In almost all cases the trio "spring/jsf/icefaces" works very well for us, all spring-managed controller-beans are perfectly useable/visible. But if a asynchronous rendering from one of RenderHubs worker-threads starts, the well know "IllegalStateException: No thread-bound request found..."-Error occurs. My assumption is: as the render-call comes from it's own thread and not a normal client-request, the listener isn't passed and therefor the spring managed beans aren't accessible for the renderResponse-Phase, and the attempt to recreate them fails with this exception ... i have seen (while debugging through icefaces) that on creation of their PersistentFacesState a reference to the web app classloader is memorized, and this classloader is later tied to the Renderables thread for the reason, that render-calls outside the context of the web app are able to access the JSF artifacts... but it seems that this works with jsf-managed-beans only.... to be honest, i am not really a spring-specialist, so i would like to ask if anybody has any idea what can be done, is there a possibility to do what the RequestContextListener is doing during a client-request?

    any feedback is highly appreciated ... is it helpful to provide the sourcecode of an example?
    Integration with Spring Web Flow was introduced in ICEfaces 1.6, but asynchronous capabilities were not tested. From your testing, it's clear that there is some work to do. However, it may not be substantial and we're now starting intensively into additional Spring integration for an upcoming release. In this case, it is likely necessary for ICEfaces to detect that Spring is active and invoke Spring methods to prepare the context appropriately (for instance, if Spring is counting on a Servlet Filter to prepare the context, a Servlet Filter may not be appropriate to apply to the Ajax interaction, and a different approach will be required).

    So, unfortunately we do not have source code at this time, but would be very interested in working with you as we enhance the Spring integration in ICEfaces.

    Comment


    • #3
      http://weblogs.java.net/blog/felipea..._icefaces.html

      Comment

      Working...
      X