Persistir clases con herencia usando Gilead
Pregunta
Estoy usando Gilead persistir mis entidades en mi proyecto GWT y me he topado con un problema. Me gustaría crear una clase padre para mantener algunas propiedades que son comunes a lo largo de mis entidades (id, etc). Cuando persiste recibo una excepción de puntero nulo.
clase primaria:
public abstract class Entity extends LightEntity implements Serializable {
protected Long id;
public Entity(){}
}
clase de niños:
public class Person extends Entity {
private String firstName;
private String lastName;
public Person(){}
}
Hibernate archivo de asignación:
<hibernate-mapping>
<class name="com.domain.Entity" abstract="true" >
<id name="id" type="long">
<column name="ID"/>
<generator class="native" />
</id>
<union-subclass name="com.domain.Person" table="PERSON">
<property name="id" type="long" />
<property name="firstName" type="string">
<column name="FIRST_NAME" length="45" not-null="true" />
</property>
<property name="lastName" type="string">
<column name="LAST_NAME" length="45" not-null="true" />
</property>
</union-subclass>
</class>
</hibernate-mapping>
Seguimiento de la pila cuando persiste:
java.lang.NullPointerException en net.sf.gilead.gwt.PersistentRemoteService.processCall (PersistentRemoteService.java:170) en com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost (RemoteServiceServlet.java:86) en javax.servlet.http.HttpServlet.service (HttpServlet.java:754) en javax.servlet.http.HttpServlet.service (HttpServlet.java:847) en org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:427) en org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:315) en org.apache.catalina.core.StandardContextValve.invokeInternal (StandardContextValve.java:287) en org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:218) en org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:648) en org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:593) en com.sun.enterprise.web.WebPipeline.invoke (WebPipeline.java:94) en com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke (PESessionLockingStandardPipeline.java:98) en org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:222) en org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:648) en org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:593) en org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:587) en org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:1096) en org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:166) en org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:648) en org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:593) en org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:587) en org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:1096) en org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:288) en com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter (DefaultProcessorTask.java:647) en com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess (DefaultProcessorTask.java:579) en com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process (DefaultProcessorTask.java:831) en com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask (DefaultReadTask.java:341) en com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask (DefaultReadTask.java:263) en com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask (DefaultReadTask.java:214) en com.sun.enterprise.web.portunif.PortUnificationPipeline $ PUTask.doTask (PortUnificationPipeline.java:380) en com.sun.enterprise.web.connector.grizzly.TaskBase.run (TaskBase.java:265) en com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run (SSLWorkerThread.java:106)
Solución
¿Está utilizando Gilead < 1.2.2?
Si es así, actualizar Gilead . Y a continuación, ejecute de nuevo y comprobar el nuevo mensaje de excepción. Lo más probable es sólo una especie de mala configuración.
Explicación completa:
Si marca el código fuente de PersistentRemoteService.java en la versión 1.2.1
PersistentRemoteService.java v1.2.1
en la línea 170 se ve la siguiente línea
return RPCCopy.getInstance().encodeResponseForFailure(null, ex, rpcRequest.getSerializationPolicy());
Esto, obviamente, no con un NullPointerException
si rpcRequest
es nulo.
Eso sucede cuando en la línea 143
// Decode request
rpcRequest = RPCCopy.getInstance().decodeRequest(payload, this.getClass(), this);
El decodeRequest
-Método lanza una IncompatibleRemoteServiceException
. Lo cual lo hace en su caso.
A partir de la versión 1.2.2 de la línea 170 cambia a
if (rpcRequest != null)
{
return RPCCopy.getInstance().encodeResponseForFailure(null, ex, rpcRequest.getSerializationPolicy());
}
else
{
return RPCCopy.getInstance().encodeResponseForFailure(null, ex);
}
Ahora usted debe conseguir la excepción derecha (IncompatibleRemoteServiceException
) que apunta al problema real.
También puede comprobar el correspondiente cometer / fix en SVN
Bad solución excepción (tema 2663344)
y la entrada cuestión correspondiente en el Bug-Tracker para Gilead
Así que este problema se resuelve en el SVN desde febrero 07 de 2009 o desde Gilead la versión 1.2.2 (13 de marzo de 2009)
Otros consejos
No está seguro si ayuda. Sólo una especulación. ¿Probaste con superclase no abstracta? A veces, anulando manualmente / ansiosamente la carga de referencias a objetos perezosos o listas antes de la serialización (y, por supuesto, fuera del ámbito transacción actual) simplemente funciona, y no hay necesidad de Gilead.