Persist Klassen mit Vererbung Gilead
https://stackoverflow.com/questions/1314178
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich bin mit Gilead auf meine Einheiten in meinem GWT Projekt bestehen bleiben, und ich habe in ein Problem laufen. Ich möchte eine Elternklasse erstellen, einige Eigenschaften zu halten, die während meiner Einheiten gemeinsam sind (id, etc). Wenn persistierende erhalte ich eine Null-Zeiger-Ausnahme.
Übergeordnete Klasse:
public abstract class Entity extends LightEntity implements Serializable {
protected Long id;
public Entity(){}
}
Child-Klasse:
public class Person extends Entity {
private String firstName;
private String lastName;
public Person(){}
}
Hibernate Mapping-Datei:
<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>
Stack-Trace, wenn persistierende:
java.lang.NullPointerException bei net.sf.gilead.gwt.PersistentRemoteService.processCall (PersistentRemoteService.java:170) bei com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost (RemoteServiceServlet.java:86) bei javax.servlet.http.HttpServlet.service (HttpServlet.java:754) bei javax.servlet.http.HttpServlet.service (HttpServlet.java:847) bei org.apache.catalina.core.ApplicationFilterChain.servletService (ApplicationFilterChain.java:427) bei org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:315) bei org.apache.catalina.core.StandardContextValve.invokeInternal (StandardContextValve.java:287) bei org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:218) bei org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:648) bei org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:593) bei com.sun.enterprise.web.WebPipeline.invoke (WebPipeline.java:94) bei com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke (PESessionLockingStandardPipeline.java:98) bei org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:222) bei org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:648) bei org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:593) bei org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:587) bei org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:1096) bei org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:166) bei org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:648) bei org.apache.catalina.core.StandardPipeline.doInvoke (StandardPipeline.java:593) bei org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:587) bei org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:1096) bei org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:288) bei com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter (DefaultProcessorTask.java:647) bei com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess (DefaultProcessorTask.java:579) bei com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process (DefaultProcessorTask.java:831) bei com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask (DefaultReadTask.java:341) bei com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask (DefaultReadTask.java:263) bei com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask (DefaultReadTask.java:214) bei com.sun.enterprise.web.portunif.PortUnificationPipeline $ PUTask.doTask (PortUnificationPipeline.java:380) bei com.sun.enterprise.web.connector.grizzly.TaskBase.run (TaskBase.java:265) bei com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run (SSLWorkerThread.java:106)
Lösung
Sind Sie Gilead mit < 1.2.2?
Wenn ja, Upgrade Gilead . Und dann wieder laufen und überprüfen Sie die neue Ausnahmemeldung. Wahrscheinlich nur eine Art von Fehlkonfiguration.
Vollständige Erklärung:
Wenn Sie die Option, den Quellcode PersistentRemoteService.java in Version 1.2.1
PersistentRemoteService.java v1.2.1
in Zeile 170 sehen Sie die folgende Zeile
return RPCCopy.getInstance().encodeResponseForFailure(null, ex, rpcRequest.getSerializationPolicy());
Dies scheitert offenbar mit einem NullPointerException wenn rpcRequest null ist.
Das geschieht, wenn in Zeile 143
// Decode request
rpcRequest = RPCCopy.getInstance().decodeRequest(payload, this.getClass(), this);
Die decodeRequest-Methode löst eine IncompatibleRemoteServiceException. Welche tut es in Ihrem Fall.
Mit der Version 1.2.2 die Linie 170 Änderungen an
if (rpcRequest != null)
{
return RPCCopy.getInstance().encodeResponseForFailure(null, ex, rpcRequest.getSerializationPolicy());
}
else
{
return RPCCopy.getInstance().encodeResponseForFailure(null, ex);
}
Nun sollten Sie die richtige Ausnahme erhalten (IncompatibleRemoteServiceException), die Sie zum eigentlichen Problem verweist.
Sie können auch überprüfen, die entsprechende commit / fix in SVN
Bad Ausnahme fix (Ausgabe 2.663.344)
und die entsprechende Ausgabe Eintrag in der Bug-Tracker für Gilead
Also dieses Problem in SVN seit 7. Februar 2009 oder seit Gilead Version 1.2.2 (13. März 2009) gelöst
Andere Tipps
Nicht sicher, ob es hilft. Nur eine Spekulation. Haben Sie versucht, mit nicht-abstrakte Superklasse? Manchmal manuell zunichte gemacht / eifrig faul Objektreferenzen oder Ladelisten vor (und natürlich auch außerhalb aktuellen Transaktionsbereich) Serialisierung nur funktioniert, und es gibt keine Notwendigkeit zu Gilead.
