Dear RichFaces Developer Team,

I ran into technical issues using the <a4j:mediaOutput> tag with Spring Beans instead of Managed JSF Beans on a JSPX page. The relevant part of the page looks like this:

<a4j:repeat value="#{paintBean.imageData}" var="imageTile">

 <a4j:outputPanel layout="block" style="left: #{imageTile.left}px; top: #{imageTile.top}px; width: #{paintBean.tileWidth}px; height: #{paintBean.tileHeight}px">

 <a4j:mediaOutput createContent="#{paintBean.paint}" element="img" mimeType="image/png" shape="rect" standby="loading..." value="#{imageTile}" />

 </a4j:outputPanel>

</a4j:repeat>

where the class PaintBean looks like this:

public class PaintBean {
 private int tileWidth;
 private int tileHeight;
 private ImageData[] imageData;

 public void paint(OutputStream out, Object data) throws IOException {
 // ...
 }

 // getters and setters
}

and the class ImageData looks like this:

public class ImageData {
 private int left;
 private int top;

 // getters and setters
}

If the paintBean is declared in the faces-config.xml as follows, everything works fine:

<managed-bean>
 <managed-bean-name>paintBean</managed-bean-name>
 <managed-bean-class>PaintBean</managed-bean-class>
 <managed-bean-scope>session</managed-bean-scope>
</managed-bean>

But as soon as I do declare the bean using the standard Spring 2.0 approach instead of doing that in the faces-config.xml, an exception with the following stack trace is thrown:

javax.faces.el.EvaluationException: /pages/views/main/richgraph.jspx @54,223 createContent="#{paintBean.paint}": Target Unreachable, identifier 'paintBean' resolved to null
 at com.sun.facelets.el.LegacyMethodBinding.invoke(LegacyMethodBinding.java:73)
 at org.ajax4jsf.resource.UserResource.send(UserResource.java:111)
 at org.ajax4jsf.resource.ResourceLifecycle.sendResource(ResourceLifecycle.java:223)
 at org.ajax4jsf.resource.ResourceLifecycle.send(ResourceLifecycle.java:148)
 at org.ajax4jsf.resource.InternetResourceService.serviceResource(InternetResourceService.java:227)
 at org.ajax4jsf.resource.InternetResourceService.serviceResource(InternetResourceService.java:144)
 at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:265)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at de.bmiag.gear.frontend.FrontendFilter.doFilter(FrontendFilter.java:291)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 at java.lang.Thread.run(Thread.java:595)

This is very strage, because all other a4j tags seem to resolve the respective EL expressions as expected: For example, the outputPanels are rendered correctly, which means that <a4j:repeat> and <a4j:outputPanel> seem to resolve value="#{paintBean.imageData}" and style="... width: #{paintBean.tileWidth}px; height: #{paintBean.tileHeight}px" very well.
Do you know how to solve this problem?

I am using the following components:

Java 1.5.0_15
MyFaces 1.1.5
RichFaces 3.1.4
Apache Tomcat 6.0.18 running on Windows XP SP 3

I know that a newer RichFaces version has been released, but I did not find any JIRA entry mentioning this problem, so I assume it hasn't already been fixed, has it?

Kind regards,
Nick Pruehs