Nav*_*Nav 3 java gwt hibernate jpa eclipselink
我在表示层使用eclipselink JPA实现(Entity)和GWT 2.0框架.一切都正常.但是当我将我的JPA实现更改为Hibernate时,当我传递实体bean时,我会在GWT层上获得序列化/反序列化异常但是在eclipselink JPA上没问题.什么事真的发生了？Hibernate也是JPA和eclipselink的实现,为什么这些行为不同？
我应该怎么做才能在Hibernate上解决这个异常？使用Hibernate4gwt？
哪个JPA实现更适合GWT？
问候
我建议阅读整个使用GWT和Hibernate的文章,它很好地解释了为什么增强类(无论你使用代理还是编织)对GWT来说都是"有问题的":
为什么Hibernate对象到达浏览器世界时无法被理解
...
当您获取一个对象并将其转换为Hibernate对象时,该对象现在被增强为持久化.没有对象的某种类型的仪器,这种持久性就没有了.在Hibernate的情况下,Javassist库实际上用持久实体替换和重写这些对象的字节码,以使Hibernate神奇工作.这对于GWT RPC来说意味着,当对象准备好通过线路传输时,它实际上不是编译器认为要传输的对象,因此在尝试反序列化时,GWT RPC机制不再知道类型是什么,并拒绝反序列化它.
事实上,如果您要更深入地查看之前的调用
loadAccounts(),并进入该RPC.invokeAndEncodeResponse()方法,您会看到我们尝试反序列化的对象现在已变为ArrayListAccount类型,其java.util.Set记录由org.hibernate.collection.PersistentSet类型替换 .在Google App Engine上使用的其他持久性框架(如JDO或JPA)也会出现类似问题.
...
所以我理解这不是一个Hibernate特定的问题,如果你使用静态或动态编织,你也可能遇到替代JPA实现的麻烦,包括EclipseLink (你不会被迫使用编织但是你会错过像懒惰这样的功能加载或获取组).
本文提出了几种集成策略,可以解决这些问题:
它还讨论了它们的优点和缺点,只需查看它.
首先,我认为GWT没有"最佳"的JPA实现,他们都面临同样的问题.如果你可以在没有延迟加载的情况下生活,那么没有编织的EclipseLink 可能会更简单.但是你会以某种方式把头埋在沙子里,问题就在那里,你将无法使用其他实现.
其次,虽然两个第一个"集成策略"将适用于任何JPA提供程序,但Hibernate是目前Gilead目前支持的唯一JPA实现(但OpenJPA和EclipseLink支持计划).
选你的毒药:)
| 归档时间： |
|
| 查看次数： |
1390 次 |
| 最近记录： |