A user wrote in to ask why his breakpoint set in the ADF PageLifecycleImpl class' prepareRender() method would fire more than once per request if his page included any images. In fact, he noticed that he would hit the breakpoint once as expected, and then again (unexpectedly) once for each image on the page. That is, if his page included three images then he'd hit this breakpoint four times. After a little digging and asking an ADF Faces team member, we got to the bottom of the problem. If you're interested in avoiding this unexpected overhead for images in your own application, read on:
A typical ADF Faces application has the FacesServlet configured in web.xml to handle requests to the application server whose URL matches "/faces/*" via the following web.xml entry:
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
I learned yesterday that if you use ADF Faces components like <af:objectImage> to display images using a relative URL like this:
<!-- Notice no leading forward slash in the relative image URL -->
<af:objectImage height="14" width="16" source="images/MyIcon.gif"/>
then the actual image URL that your browser will request will end up looking like this:
http://yourserver/YourContextRoot/faces/images/MyIcon.gif
which, due to its matching the "/faces/*" URL pattern, causes the Faces Servlet (and hence the rest of the ADF page lifecycle that is "wired" into it as a phase listener) to inadvertently kick-in again while serving up each such image. This is definitely not great for performance, so make sure that you use relative URL's that begin with a leading forward-slash like this instead:
<!-- Notice leading forward slash in the relative image URL -->
<af:objectImage height="14" width="16" source="/images/MyIcon.gif"/>
This will cause ADF Faces to generate a URL that automatically includes the J2EE Context Root, but leaves out the "/faces" part of the URL. This avoids the unnecessary triggering of the Faces servlet for serving up your images.
4:48:36 PM 
|
