重要通知:此问题已在2015年4月8日发布的PrimeFaces 5.2 final(社区版本)中修复。因此,如果您碰巧使用该版本或更新的版本,则不需要摆弄临时解决方案。
前面给出的示例现在可以安全地进行如下修改:
public StreamedContent getImage() throws IOException {
FacesContext context = FacesContext.getCurrentInstance();
if (context.getCurrentPhaseId() == PhaseId.RENDER_RESPONSE) {
return new DefaultStreamedContent();
} else {
String id = context.getExternalContext().getRequestParameterMap().get("id");
byte[] bytes = Utils.isNumber(id) ? service.findImageById(Long.parseLong(id)) : null;
return bytes == null ? null : new DefaultStreamedContent(new ByteArrayInputStream(bytes));
}
}
在我厌倦了操作/管理存储在磁盘文件系统中的图像后,我以BLOB (LONGBLOB
)的形式将图像移动到数据库(MySQL)。
因此,我在<p:dataTable>
中显示图像如下(公然从这里复制:))。
<p:column headerText="Header">
<p:graphicImage value="#{bannerBean.image}" height="200" width="200">
<f:param name="id" value="#{row.bannerId}"/>
</p:graphicImage>
<p:column>
检索图像的bean如下:
@ManagedBean
@ApplicationScoped
public final class BannerBean
{
@EJB
private final BannerBeanLocal service=null;
public BannerBean() {}
public StreamedContent getImage() throws IOException {
FacesContext context = FacesContext.getCurrentInstance();
if (context.getCurrentPhaseId() == PhaseId.RENDER_RESPONSE) {
return new DefaultStreamedContent();
}
else {
String id = context.getExternalContext().getRequestParameterMap().get("id");
byte[] bytes = service.findImageById(Long.parseLong(id));
return bytes==null? new DefaultStreamedContent():new DefaultStreamedContent(new ByteArrayInputStream(bytes));
}
}
}
只要底层数据库表的每一行都有图像,就可以正常工作。
数据库中的BLOB类型列在某些情况下是可选的,因此,它也可以包含null
值。
如果数据库中任何一行中的该列是null
,则抛出以下异常:
SEVERE: Error in streaming dynamic resource. null
WARNING: StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
java.lang.NullPointerException
at org.primefaces.application.PrimeResourceHandler.handleResourceRequest(PrimeResourceHandler.java:127)
at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:153)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
那么如何管理null
blob,使此异常消失?
返回new DefaultStreamedContent(new ByteArrayInputStream(new byte[0]))
,在这种情况下,托管bean中的字节数组为空将抑制异常,但这毕竟不应该是一个解决方案。这是理想的解决方案吗?
返回字节数组的EJB方法,尽管在本例中完全没有必要。
public byte[] findImageById(Long id)
{
CriteriaBuilder criteriaBuilder = entityManager.getCriteriaBuilder();
CriteriaQuery<byte[]>criteriaQuery=criteriaBuilder.createQuery(byte[].class);
Root<BannerImages> root = criteriaQuery.from(BannerImages.class);
criteriaQuery.multiselect(root.get(BannerImages_.bannerImage));
ParameterExpression<Long>parameterExpression=criteriaBuilder.parameter(Long.class);
criteriaQuery.where(criteriaBuilder.equal(root.get(BannerImages_.bannerId), parameterExpression));
List<byte[]> list = entityManager.createQuery(criteriaQuery).setParameter(parameterExpression, id).getResultList();
return list!=null&&!list.isEmpty()?list.get(0):null;
}
这是PrimeResourceHandler
中的一个bug(至少是一个功能/技术设计错误)。它不应该假设动态资源或其内容永远不是null
。如果是这种情况,它应该有条件地检查,然后简单地返回一个HTTP 404 "Not Found"响应。
换句话说,不是
85 streamedContent = (StreamedContent) ve.getValue(eLContext);
86
87 externalContext.setResponseStatus(200);
88 externalContext.setResponseContentType(streamedContent.getContentType());
他们应该做的
85 streamedContent = (StreamedContent) ve.getValue(eLContext);
86
87 if (streamedContent == null || streamedContent.getStream() == null) {
88 externalContext.responseSendError(HttpServletResponse.SC_NOT_FOUND, ((HttpServletRequest) externalContext.getRequest()).getRequestURI());
89 return;
90 }
91
92 externalContext.setResponseStatus(200);
93 externalContext.setResponseContentType(streamedContent.getContentType());
这样,您可以从getImage()
方法返回null
或空StreamedContent
,以生成像样的404。
那么,你能做什么呢?
报告给他们,希望他们能解决它。更新在5.2版本中修复了
和/或,把
PrimeResourceHandler
类的副本放在你的webapp项目的Java源文件夹中,在它自己的org.primefaces.application
包中,然后编辑它以包含提到的更改,最后像往常一样构建/部署你的webapp项目。/WEB-INF/classes
中的类比/WEB-INF/lib
中的jar类具有更高的类加载优先级,因此将使用修改后的类。
我建议在<p:dataTable>
迭代的对象中包含一个属性,以表示图像是否存在。这样,就没有对BannerBean.getImage()
的不必要的(或null返回)调用。
的例子:
<p:column headerText="Header">
<p:graphicImage value="#{bannerBean.image}" height="200" width="200"
rendered="#{row.hasImage}">
<f:param name="id" value="#{row.bannerId}"/>
</p:graphicImage>
<p:column>
另一个选择是获取Primefaces源代码,编辑PrimeResourceHandler.java,并构建它。(参见wiki)
另一种解决方案是设置自己的servlet来提供图像。
- 主要的好处是浏览器可以缓存图像(如果需要,您可以指定缓存超时)。
- 注意SQL注入其他安全攻击。 附加某种登录/权限检查以增加安全性。(如果需要)
的例子:
<p:column headerText="Header">
<p:graphicImage value="#{request.contextPath}/images/banner/?id=#{row.bannerId}"
height="200" width="200" />
<p:column>
@WebServlet(name = "Retrieve Banner Images", urlPatterns = "/images/banner/*")
public class BannerImageServlet extends HttpServlet
{
@EJB
private final BannerBeanLocal service;
protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
String[] ids = req.getParameterValues("id");
if(ids != null && ids.length == 1) {
byte[] bytes = service.findImageById(Long.parseLong(ids[0]));
if(bytes != null) {
// see link #3 below
}
}
}
}
资源/有用链接:
- # {request.contextPath} <
- @WebServlet教程/gh>
- 如何将字节流发送回客户端