JPA和GWT失败(JPA and GWT failing)

2019-11-03 05:51发布

站内文章 / 后端开发
110 0 0

我试图使用JPA与GWT。

我serviceImpl电话

UserDAO.exists(user);

当我运行一个测试案例，它调用了同样的方法，用同样的参数，它运行正常。 当我做了RPC调用，如果失败可怕（末尾的错误）。

当我重新命名的persistence.xml到someothername.xml，我得到了同样的错误，所以我倾向于认为，GWT（在开发模式BTW），不读我的persistence.xml。

错误： 

Starting Jetty on port 8888
   [WARN] Exception while dispatching incoming RPC call
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract hobarrera.client.dto.main.UserRegDTO hobarrera.client.services.AuthService.selfRegisterUser(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws hobarrera.client.exceptions.MyCustomizedException' threw an unexpected exception: java.lang.ExceptionInInitializerError
 at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:378)
 at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:581)
 at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:188)
 at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:224)
 at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
 at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
 at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
 at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
 at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
 at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:49)
 at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.Server.handle(Server.java:324)
 at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
 at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
 at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
 at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)
Caused by: java.lang.ExceptionInInitializerError
 at hobarrera.server.DAO.EntityManagerFactory.createEntityManager(EntityManagerFactory.java:13)
 at hobarrera.server.DAO.UsuarioDAO.userNameExists(UsuarioDAO.java:52)
 at hobarrera.server.services.AuthServiceImpl.selfRegisterUser(AuthServiceImpl.java:60)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:562)
 ... 22 more
Caused by: javax.persistence.PersistenceException: No resource files named META-INF/services/javax.persistence.spi.PersistenceProvider were found. Please make sure that the persistence provider jar file is in your classpath.
 at javax.persistence.Persistence.findAllProviders(Persistence.java:167)
 at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:103)
 at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
 at hobarrera.server.DAO.EntityManagerFactory$RealEntityManagerFactoryContainer.<clinit>(EntityManagerFactory.java:9)
 ... 30 more
[ERROR] 500 - POST /desarrollonew/greet (0:0:0:0:0:0:0:1) 57 bytes
   Request headers
      Host: localhost:8888
      User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100216 Fedora/3.5.8-1.fc12 Firefox/3.5.8
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
      Accept-Language: en-us,en;q=0.5
      Accept-Encoding: gzip,deflate
      Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
      Keep-Alive: 300
      Connection: keep-alive
      Referer: http://localhost:8888/desarrollonew/hosted.html?desarrollonew
      Cache-Control: no-cache
      X-GWT-Permutation: HostedMode
      X-GWT-Module-Base: http://localhost:8888/desarrollonew/
      Content-Type: text/x-gwt-rpc; charset=utf-8
      Content-Length: 187
      Pragma: no-cache
   Response headers
      Content-Type: text/plain

[编辑]
这似乎GWT有它自己的persistence.xml文件的地方（供内部使用我猜）。 这就是为什么我重命名到的persistence.xml仍然somethingelse.xml了同样的错误：这是读取persistence.xml文件是GWT的所有的时间。

所以，现在我的问题是：我如何覆盖它，迫使另外一个用途，或没有它？

Answer 1:

你有没有在DataNucleus将罐子WEB-INF/lib ？



Answer 2:

你没有在你的classpath中添加JPA实现。 在classpath将DataNucleus将罐子（或排名靠前的链接，或者你使用任何），它照顾实体管理器创建的。



Answer 3:

参考： http://code.google.com/webtoolkit/articles/using_gwt_with_hibernate.html

为什么当他们到达浏览器世界的Hibernate对象不能被理解？

那么，什么地方出了错？ 纵观托管模式控制台，你会“而调度传入RPC调用异常”被记录到控制台上看到的警告消息。 选择警告消息，下面的窗格中会显示一个比较长的堆栈跟踪。

这是要注意的部分：

com.google.gwt.user.client.rpc.SerializationException：通过引起类型“org.hibernate.collection.PersistentSet”没有被包括在该组的类型，其可以通过将本SerializationPolicy或其类对象被序列不能被加载。 为了安全起见，这种类型将不会被序列化。 在com.google.gwt.user.server.rpc.impl.StandardSerializationPolicy.validateSerialize（StandardSerializationPolicy.java:83）在com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize（ServerSerializationStreamWriter.java:591）

这里的关键是，当我们试图加载和检索账户抛出的SerializationException。

那么究竟是什么出了问题？ 那么，你可能会在GWT RPC文档已阅读，一个SerializationException抛出每当调过来的RPC一个类型不是“序列化”。 的序列化在这里的定义是指在GWT RPC机制，知道如何序列化和反序列化的字节码，以JSON，反之亦然类型。 要声明一个类为可序列化到GWT编译器，你可以做类型通过RPC转移实现IsSerializable接口，为此目的专门设立的，或执行标准java.io.Serializable接口，只要它的成员和方法包括这也是序列化类型。

在帐户和记录的Hibernate对象的情况下，我们正在实现Serializable接口，所以这应该工作，应该不是他们？ 事实证明，魔鬼在细节。

当你把一个对象，并把它变成一个Hibernate对象，该对象正在增强是持久的。 这持久不来没有某种类型的对象的仪器。 在休眠的情况下，Javassist是库实际上是替换和重写这些对象通过持久化实体，使Hibernate的魔法工作字节码。 这意味着什么，GWT RPC是由对象是准备好了的电线要传输的时候，它实际上是不是同一个对象，编译器想到的是将要被转移，所以尝试反序列化时，GWT的RPC机制不再知道什么类型的，并拒绝反序列化。

事实上，如果你再深入到到loadAccounts（）较早的通话，并步入RPC.invokeAndEncodeResponse（）方法，你会看到，我们正在尝试反序列化对象现在已经成为帐户类型有一个ArrayList他们的记录为java.util.Set由org.hibernate.collection.PersistentSet型所取代。

与其他持久性框架，如JDO或JPA，在谷歌App Engine的使用出现类似的问题。

一个潜在的解决办法是通过服务器侧的RPC调用返回之前再次在相反方向上替换类型。 这是可行的，而且会解决我们在这里遇到的问题，但我们不会伤害的方式，只是还没有。 使用Hibernate的另一大好处是，在需要的时候，我们可以懒洋洋地加载相关对象的事实。 例如，在服务器端，我可以加载一个帐户，改变它周围，只有被带到account.getRecords（）的调用和对这些记录的一些动作时加载其相关记录。 特别Hibernate的仪器会照顾实际获取的记录，当我拨打电话，使他们只提供真正需要的时候。

正如你可以想像，这将转化为在GWT RPC世界奇怪的行为，其中这些休眠对象从Java服务器端前往浏览器的土地。 如果GWT RPC服务试图延迟访问协会，你可能会看到类似LazyInitializationException中被抛出。



Answer 4:

由于这是像第n次，我要建议切换到GWT的外部服务器，请允许我引用我以前的答案 （请阅读GWT的嵌入式码头问题进行更深入的解释完整的答案）：

我建议你只是切换到外部Java服务器（如Tomcat，您似乎已经安装，并与您的配置工作） - 少得多的问题，不是试图用自带的GWT残废码头的工作更容易。

该指令可以在文档中找到。 如果你坚持使用GWT的码头，你将只运行在将来更多的问题。

它仍然是真实的，但 - 随GWT的码头被称为是有问题的。 通读文档有关如何使用外部服务器GWT指令（简单的程序，恕我直言） -没有缺陷，并且用奇怪的错误/异常没有问题。



文章来源: JPA and GWT failing
标签： gwt jpa datanucleus
举报

收藏的人(0)

Ta的文章 更多文章
登录 后发表评论
0条评论
还没有人评论过~