Issue using <a4j:mediaOutput> with Spring 2.0 Beans
npruehs Oct 1, 2008 10:31 AMDear 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