PawaStation 能猫环岛 » java

无尽欢乐 JasperReport

pawaca — Sun, 06 Jan 2008 06:48:04 +0000

上个月很磕了一下 JasperReport，再次亲身印证了 80/20 法则。。。今天抽空列出几个“看上去”都用不了多少时间就可以搞定的问题。

空白 pdf 报表

我用的是 Spring 中的 JasperReportsPdfView 来帮助整合生成 pdf，这本来应该是一个非常简单的过程：Controller 返回一个标识 JasperReportsPdfView 的 ModelAndView，然后 Spring 自动生成报表。我最开始尝试的时候这样写的 Controller：

1
2
3
4
5

protected ModelAndView handleRequestInternal(HttpServletRequest request,
HttpServletResponse response) throws Exception
{
return new ModelAndView("pdfReport");
}

pdfReport 对应一个 JasperReportsPdfView，并配置指向了一个不需要任何动态数据的 report.jrxml 模板。打开浏览器访问 controller ，会返回生成后的 pdf，不过内容是空的。。。改来改去，折腾了半天，最后发现原来 即使模板不需要任何动态数据，还是要传递一个 dummy 过去，才可以 render 出结果 。

1
2
3
4
5
6
7
8

protected ModelAndView handleRequestInternal(HttpServletRequest request,
HttpServletResponse response) throws Exception
{
Map<Object> model = new HashMap<Object>();
// Spring 配置的默认 jasper datasource 在 map 中的名称是 'datasource'，这个名字可以配置。
model.put("datasource", new JRBeanCollectionDataSource(new ArrayList<Object>()));
return new ModelAndView("pdfReport",model);
}

文字消失

开始在 dev 环境下生成好好的 pdf，放到 product 环境下变得无法完全显示所有文字。推测是嵌入字体问题，换来换去都不行。最后想起 product 环境是 windows，而 dev 环境是 linux，digg 了许久文档，终于找出原因。原来 JasperReport 在生成 pdf 的时候 text 的 layout 是以 fontName 这个属性为基准，用 Java 的 AWT 里算出字的高度，而最终显示在 Adobe Reader 中的事根据 pdfFontName 这个属性。很显然， Linux 和 Windows 下面算出的文字高度不同。Linux下面可以显示，但是 Windows 下面高度就不够了，所以出现了缺字的现象。解决办法就是把 TextField 的高度加 4 px 左右。后来还想出一个方法是设置 stretch with overflow 那个属性，不过没有具体测试。

isStretchWithOverflow 失灵

用户输入的多行文字不能完全显示，只显示了在 iReport 里面设计时候的那部分，仿佛 isStretchWithOverflow 设置了跟没设置一样。又是昏天黑地的 digg，最后发现原因在客户端录入，Flex 的文本域 line separator 竟然是 \r 。Java 这边则是 \n，JasperReport 的文本 stretch 很可能是数文本有多少个 line separator 然后算出总高度，结果当然是算不出实际的行数。解决的办法是在把文本发到 JasperReport 之前，先 correct line separator。

总结

是福不是祸，是祸躲不过。上面的问题每一个都耗掉 2 hours+ 的时间来 debug，记在这里，希望可以造福后人。另外有一点比较奇怪的是，JasperReport 的论坛好像完全没有被 google index，出了问题一定要到这里和这里才可以啊。囧

我佛慈悲。。。

AMF3 Integer/Number 与 GDS

pawaca — Sat, 24 Nov 2007 07:42:24 +0000

AMF3 里面的 integer 类型使用 4 bytes 来传输，但是是以一种诡异的形式，摘 osflash 上的一段描述：

Integer-data is probably the single most used item in AMF3. To save space it is an integer that can be 1-4 bytes long. The first bit of the first three bytes determine if the next byte is included (1) in this integer-data or not (0). The last byte, if present, is read completely (8 bits). The first bits are then removed from the first three bytes and the remaining bits concatenated to form a big-endian integer.

这里的重点是：为了省地方， amf3 的 integer 牺牲了部分范围，只能表示 -268435456(int.MIN_VALUE»3) 到 268435455(int.MAX_VALUE»3) 范围内的数。

这引出了一个问题，如果在 java 中一个 integer 的数值大于 amf3 可允许的范围传输的时候怎么办？ survey 了一些 implement 代码，发现这种时候会用范围更大的 8 bytes number 类型来传输。

[分隔线若干条...]

最近程序 (Flex + GDS + Hibernate + 其他) 被 User 用出一个神秘的 exception：

javax.persistence.PersistenceException: org.hibernate.TypeMismatchException: Provided id of the wrong type. Expected: class java.lang.Integer, got class java.lang.Double

由于无法 reproduce，我就把他当成了灵异事件，没有理会。没想到这个不着调的 exception 竟然在昨天出现在朕的面前！经过 3.765 秒的分析和 4.132 秒的 survey 终于发现了问题的根源。（深吸一口气）原来是有一个 proxy entity 的 id 超过了 amf integer 可允许的最大范围，这个从 java 传到 flex 还没什么问题，但是回传会来的时候由于 GDS 将 amf number 读成 double 所以造成 id 类型为 double，但实际上这个 id 被声明为 integer，所以在就出现了上面那个 exception （吐气…）

有趣的是，只有当 entity 是 hibernate proxy 的时候才会出现这个问题。看来是 GDS 某个地方写的有问题，在代码里游啊游，发现了这段：

1
2
3
4

// /graniteds/hibernate/org/granite/hibernate/HibernateProxyInstanciator.java
public void readId(ObjectInput in) throws IOException, ClassNotFoundException {
this.id = (Serializable)in.readObject();
}

上面的这个代码是从 svn 的 trunk 上粘下来的，看来这个问题还没改…（没被发现？）

总之，如果有谁不幸中招，可以试试 apply 这个 patch 到 /graniteds/hibernate/org/granite/hibernate/HibernateProxyInstanciator.java 。

Over

Spring MVC 中的中文编码问题小说一蛤

pawaca — Thu, 26 Jul 2007 04:17:02 +0000

原来以为 Java 中文支持的会很好，没想到一用 Spring 就出乱码啦，看来人家默认情况下都不吊你第三世界国家的。。。

anyway 切入正题，我股沟了一下相关的内容，发现大多数解决方法都是加个 servlet filter 来转换编码。觉得这方法不好，好像虽然有用但是比较糊弄事，不彻底明白始终不爽。所以我就在源代码里游啊游，整理出大概的思路，如下：

页面显示中文

这部分以 jsp 为例， Spring MVC 在 resolve 页面显示的时候是这么一个流程。

InternalResourceViewResolver 利用 InternalResourceView 来 build view。 InternalResourceView 则会将最终页面生成的请求转交给对应的 jsp 来通过 container 实现。

如果页面显示有乱码，问题貌似会出在 InternalResourceView 上，实际上 InternalResourceViewResolver 的父类中有一个叫 UrlBasedViewResolver 的东东，里面有个属性叫做 contentType，并且会在 buid view 的时候最终把这个属性赋值给 InternalResourceView 。貌似找到了问题的原因。我试着这样设置并窃喜：

1
2
3
4
5

id="jspViewResolver"
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
name="contentType" value="utf-8">>
...
>

页面刷新后乱码依旧。。。回到源文件中，游啊游，发现其实 InternalResourceViewResolver 虽然有给 InternalResourceView 赋值 contentType，但是 InternalResourceView 忽视了这个属性。。。然后直接转交给对应的 jsp 处理。看来问题实际上出在 jsp 上。到对应的 jsp 页面，加上下面的代码：

1	<%@ page pageEncoding="UTF-8" contentType="text/html;charset=UTF-8"%>

然后在编辑器里确保源文件也存成 utf-8，然后刷新页面，好了。

h3. 提交中文参数

原以为这样就 OK 了，后来发现还没完。。。在表单提交的时候，中文依然乱码，sun。再游！发现要改的地方有两点，第一个是针对表单的 POST，因为默认的 request body 处理的编码不是 utf-8 所以在 decode body 的时候会解出乱码来。这需要写个Interceptor 来设置 request 的 encoding ，比如：

1
2
3
4
5
6
7
8
9
10
11

public class RequestEncodingInterceptor implements HandlerInterceptor
{
@Override
public boolean preHandle(HttpServletRequest request,
HttpServletResponse response, Object handler) throws Exception
{
request.setCharacterEncoding("utf-8");
return true;
}
...
}

然后挂在对应的 handlerMapping 上面，比如：

1
2
3
4
5
6
7
8
9

id="handlerMapping">
class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping">
name="interceptors">
>
class="RequestEncodingInterceptor">
>
>
...
>

另一方面，如果 url get 中有 encode 之后的中文参数，还需要确保 url decode 也用 utf-8 来解。由于 BeanNameUrlHandlerMapping 通过 UrlPathHelper 来处理 url，所以需要这样配置：

1
2
3
4
5
6
7
8
9
10

id="handlerMapping"
class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping">
....
name="urlPathHelper">
class="org.springframework.web.util.UrlPathHelper">
name="urlDecode" value="true">>
name="defaultEncoding" value="utf-8">>
>
>
>

国际化 i18n

国际化的配置文件如果用 java 的 properties 文件是不支持 utf-8 滴，要换成 Spring 的 ReloadableResourceBundleMessageSource ，酱紫配置：

1
2
3
4
5

id="messageSource">
class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
name="basename" value="WEB-INF/i18n/messages">>
name="defaultEncoding" value="utf-8">>
>

搞定！（貌似？）