1

我正在尝试将 JPA 与 GWT 一起使用。

我的 serviceImpl 调用

UserDAO.exists(user);

当我运行一个使用相同参数调用相同方法的测试用例时，它运行正常。当我进行 RPC 调用时，如果严重失败（最后出错）。

当我将persistence.xml 重命名为someothername.xml 时，我得到了相同的错误，所以我倾向于认为GWT（顺便说一句在开发模式下）没有读取我的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 的。

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

4

4 回答 4

2

你有 DataNucleus 罐子WEB-INF/lib吗？

于 2010-03-06T22:55:41.383 回答
0

您没有在类路径中添加 JPA 实现。将 datanucleus（或 toplink，或您正在使用的任何东西）的 jar 放在您的类路径中，它负责创建实体管理器。

于 2010-03-06T22:43:08.303 回答
0

参考：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 序列化的类型集中，或者无法加载其 Class 对象. 出于安全目的，此类型不会被序列化。在 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 文档中读到的那样，只要通过 RPC 传输的类型不是“可序列化的”，就会引发 SerializationException。这里对serializable 的定义意味着GWT RPC 机制知道如何将类型从字节码序列化和反序列化为JSON，反之亦然。要向 GWT 编译器声明一个可序列化的类型，您可以使要通过 RPC 传输的类型实现 IsSerializable 接口，特别是为此目的创建的，或者实现标准的 java.io.Serializable 接口，前提是它的成员和方法由也可序列化的类型组成。

对于 Account 和 Record Hibernate 对象，我们正在实现 Serializable 接口，所以这些应该可以工作，不是吗？事实证明，魔鬼在细节中。

当您获取一个对象并将其转换为 Hibernate 对象时，该对象现在被增强为持久性。如果没有某种类型的对象检测，这种持久性就不会出现。在 Hibernate 的情况下，Javassist 库实际上通过持久实体替换和重写这些对象的字节码，以使 Hibernate 发挥神奇的作用。这对 GWT RPC 意味着，当对象准备好通过网络传输时，它实际上并不是编译器认为将要传输的对象，因此在尝试反序列化时，GWT RPC 机制不再知道类型是什么并拒绝反序列化它。

事实上，如果你更深入地查看之前对 loadAccounts() 的调用，并进入 RPC.invokeAndEncodeResponse() 方法，你会看到我们试图反序列化的对象现在变成了 Account 类型的 ArrayList他们的 java.util.Set 记录被替换为 org.hibernate.collection.PersistentSet 类型。

Google App Engine 上使用的其他持久性框架（例如 JDO 或 JPA）也会出现类似问题。

一个潜在的解决方案是在通过服务器端 RPC 调用返回之前再次以相反的方向替换类型。这是可行的，并且会解决我们在这里遇到的问题，但我们还不会受到伤害。使用 Hibernate 的另一个好处是我们可以在需要时延迟加载关联的对象。例如，在服务器端，我可以加载一个帐户，对其进行更改，并且仅在调用 account.getRecords() 并对这些记录执行某些操作时才加载其关联记录。当我拨打电话时，特殊的 Hibernate 仪器将负责实际获取记录，使它们仅在真正需要时可用。

As you may imagine, this will translate to strange behaviour in the GWT RPC world where these Hibernate objects traveled from the Java server-side to browser land. If a GWT RPC service tries to access associations lazily, you might see something like a LazyInitializationException being thrown.

于 2011-04-05T12:48:22.817 回答
-1

由于这就像我第 n 次建议为 GWT 切换到外部服务器一样，让我引用我之前的答案（请阅读完整答案以更深入地解释 GWT 的嵌入式 Jetty 问题）：

我建议只切换到外部 Java 服务器（如 Tomcat，您似乎已经安装了它并且可以与您的配置一起使用）——比尝试使用 GWT 附带的残缺 Jetty 更容易解决问题。

说明可以在文档中找到。如果您坚持使用 GWT 的 Jetty，您将来只会遇到更多问题。

不过，这仍然是正确的——众所周知，GWT 附带的 Jetty 存在问题。通读文档以获取有关如何将外部服务器与 GWT（简单程序，恕我直言）一起使用的说明 - 没有缺点，也没有奇怪错误/异常的问题。

于 2010-03-07T02:01:56.053 回答