استمرار الطبقات مع الميراث باستخدام Gilead

Question

أنا أستخدم Gilead لتستمر كياناتي في مشروع GWT الخاص بي واجهت مشكلة. أرغب في إنشاء فئة أوديا لعقد بعض الخصائص الشائعة في جميع أنحاء كياناتي (معرف، إلخ). عند الاستمرار في الحصول على استثناء مؤشر فارغ.

الطبقة الأصل:

public abstract class Entity extends LightEntity implements Serializable {
    protected Long id;
    public Entity(){}
}

فئة الطفل:

public class Person extends Entity  {
    private String firstName;
    private String lastName;
    public Person(){}
}

ملف رسم الخرائط السبات:

<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>

تتبع المكدس عند الاستمرار:

java.lang.nullpointerexception في net.sf.gilead.gwt.persistentremoteservice.processcall (persistentremoteservice.java:170) في com.google.gwt.user.server.rpc.remoteservicservlet.dopost (remoteserviceservlet.java: 86) في Javax. servlet.http.httpservlet.service (httpservlet.java:754) في javax.servlet.http.httpservlet.service (httpservlet.java:847) في org.apache.catalina.core.applicationfilterchain.servletserchain.servletservice (Applicationfilterchain.java:427) org.apache.catalina.core.standardwrappervalve.invoke (StandardWraPperValve.java:315) في Org.apache.catalina.core.instardcontextvalve.invokeintnal (StandardContextvalve.java:287) في Org.apache.catalina.core.tandardcontextvalve.invoke (StandardContextValve.java:218) org.apache.catalina.core.standardpipeline.doinvoke (Standardpipeline.java:648) في Org.apache.catalina.core.standardpipeline.doinvoke (Standardpipeline.java: 593) في Com.sun. Enterprise.web.webpipeline.invoke (webpipeline.java:94) في com.sun.enterprise.web.pesessessionlockingstardpipeline.inv oke oke (psessessionlockingstandardpipeline.java:98) org.apache.catalina.core.standardhostvalve.invoke (Standardhostvalve.java:222) في Org.apache.catalina.core.standardpipeline.doinvoke (StandardPipeline.java: 648) في Org.apache .catalina.core.standardpipeline.deinvoke (Standardpipeline.java:593) في Org.apache.catalina.core.standardpipeline.invoke (Standardpipeline.java:587) في Org.apache.catalina.core.containerbase.invoke (Containerbase.java : 1096) org.apache.catalina.core.standardenginevalve.invoke (StandardengineValve.java:166) في Org.apache.catalina.core.standardpipeline.doinvoke (Standardpipeline.java:648) org.apache.catalina.core. StandardPipeline.doinvoke (StandardPipeline.java:593) or org.apache.catalina.core.standardpipeline.invoke (Standardpipeline.java:587) في Org.apache.catalina.core.containerbase.invoke (Containerbase.java:1096) في Org .apache.coyote.tomcat5.coyoteadapter.service (coyoteadapter.java:288) في com.sun.enterprise.web.connector.grizzly.defaultprocessortask.invokeadapتر (Defa ultprocessortask.java:647) at com.sun.enterprise.web.connector.grizzly.defaultprocessortask.doprocess (defaultprocessortask.java:579) في com.sun.enterprise.web.connector.grizzly.defaultprocessortask.process (defaultprocessortask.java: 831) at com.sun.enterprise.web.connector.grizzly.defaultreadtask.executeprocessortask (defaultreadtask.java:341) في com.sun.enterprise.web.connector.grizzly.defaultreadtask.dotask.dotask (defaultreadtask.java:263) في كوم .sun.enterprise.web.connector.grizzly.defaultreadtask.dotask (defaultreadtask.java:214) في com.sun.enterprise.web.portunif.portunificationpipeline $ putask.dotask (portunificationpipeline.java:380) في com.sun.enterprise .web.connector.grizzly.taskbase.run (taskbase.java:265) في com.sun.enterprise.web.connector.grizzly.ssl.sslworkerthread.run (sslworkerthread.java:106)

Answer 1

هل تستخدم Gilead < 1.2.2?

إذا كانت الإجابة بنعم، قم بترقية Gilead. وبعد ثم قم بتشغيل مرة أخرى وتحقق من رسالة الاستثناء الجديدة. على الأرجح فقط نوع من الخطر.

شرح كامل:

إذا قمت بالتحقق من شفرة المصدر في PersistentRemoteService.java في الإصدار 1.2.1

persistentremoteservice.java v1.2.1.

عند السطر 170 ترى السطر التالي

return RPCCopy.getInstance().encodeResponseForFailure(null, ex, rpcRequest.getSerializationPolicy());

هذا يفشل بوضوح مع NullPointerException إذا rpcRequest باطل.

يحدث ذلك عندما يتفق 143

// Decode request
rpcRequest = RPCCopy.getInstance().decodeRequest(payload, this.getClass(), this);

ال decodeRequest-Method يلقي an. IncompatibleRemoteServiceException. وبعد التي تفعل في قضيتك.

بدءا من الإصدار 1.2.2 الخط 170 يتغير

if (rpcRequest != null)
{
  return RPCCopy.getInstance().encodeResponseForFailure(null, ex, rpcRequest.getSerializationPolicy());
}
else
{
    return RPCCopy.getInstance().encodeResponseForFailure(null, ex);
}

الآن يجب أن تحصل على الاستثناء الصحيح (IncompatibleRemoteServiceException) مما يشيرك إلى المشكلة الحقيقية.

يمكنك أيضا التحقق من الالتزام / الإصلاح المقابل في SVN

إصلاح استثناء سيء (العدد 2663344)

وإدخال القضية المقابلة في علة تعقب ل Gilead

استثناء خاطئ

لذلك تم حل هذه المشكلة في SVN منذ 07 فبراير 2009 أو منذ إصدار Gilead 1.2.2 (13 مارس 2009)

Answer 2

لست متأكدا مما إذا كان يساعد. مجرد تكهنات. هل حاولت مع superclass غير مجردة؟ في بعض الأحيان إلغاء استئصال مراجع أو قوائم كائنات كسول يدويا قبل التسلسل (وبالطبع خارج نطاق المعاملات الحالية) يعمل فقط، وليس هناك حاجة إلى Gilead.