Сохранять классы с наследованием, используя Gilead - PullRequest
Новая
       12

Сохранять классы с наследованием, используя Gilead

0 голосов
/ 22 августа 2009

Я использую Gilead для сохранения своих сущностей в моем проекте GWT, и я столкнулся с проблемой. Я хотел бы создать родительский класс для хранения некоторых свойств, общих для всех моих сущностей (id и т. Д.). При сохранении я получаю исключение нулевого указателя.

Родительский класс: 

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: 

<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 at net.sf.gilead.gwt.PersistentRemoteService.processCall (PersistentRemoteService.java:170) на com.google.gwt.user.server.rpc.RemoteServiceServlet.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.servletService (ApplicationFilterChain.java:427) в org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:315) в org.apache.catalina.core.StandardContextValve.invokeInternal (StandardContextValve.java:287) в org.apache.catalina.core.StandardContextValve.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.PESessionLockingStandardPipeline.invoke (PESessionLockingStandardPipeline.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.doInvoke (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) в 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.invokeAdapter (DefaultProcessorTask.java:647) в com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess (DefaultProcessorTask.java:579) в com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process (DefaultProcessorTask.java:831) в com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask (DefaultReadTask.java:341) на com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask (DefaultReadTask.java:263) на com.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)

Ответы [ 2 ]

3 голосов
/ 10 октября 2009

Используете ли вы Gilead <</strong> 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 бросает 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)

и соответствующая запись о проблеме в Bug-Tracker для Gilead

Неправильное исключение

Таким образом, эта проблема решается в SVN с 7 февраля 2009 г. или с версии Gilead 1.2.2 (13 марта 2009 г.)

0 голосов
/ 10 октября 2009

Не уверен, поможет ли это. Просто предположение. Вы пробовали с неабстрактным суперклассом? Иногда ручная аннулирование / активная загрузка ленивых ссылок или списков объектов перед сериализацией (и, конечно, за пределами текущей области транзакции) просто работает, и Gilead не требуется.

...