Абстрактный шаблон DAO и проблема Spring "Прокси не может быть приведен к ..."! - PullRequest
Новая
       34

Абстрактный шаблон DAO и проблема Spring "Прокси не может быть приведен к ..."!

9 голосов
/ 04 октября 2010

Я знаю, что это очень часто спрашивают, но я не могу найти рабочее решение:

Это мой AbstractDAO: 

public interface AbstractDao<T>
{
  public T get(Serializable id);
  //other CRUD operations
}

И это реализация моего JPA: 

public abstract class AbstractDaoJpaImpl<T> implements AbstractDao<T> , Serializable
{
  protected EntityManager em;

  protected Class<T> clazz;

  @SuppressWarnings("unchecked")
  public AbstractDaoJpaImpl()
  {
    ParameterizedType genericSuperclass = (ParameterizedType) getClass().getGenericSuperclass();
    this.clazz = (Class<T>) genericSuperclass.getActualTypeArguments()[0];
  }

  public abstract void setEntityManager(EntityManager em);  
  //implementations skipped
}

И это дао одной сущности: 

public interface PersonDao extends AbstractDao<Person>
{
  //empty
}

Вот его реализация: 

@Repository
public class PersonDaoImpl extends AbstractDaoJpaImpl<Person> implements PersonDao , OtherInterface
{
  @PersistenceContext(unitName="company")
  @Override
  public void setEntityManager(EntityManager em)
  {
    this.em = em;
  }

  @Override // implements OtherInterface.additionalMethods()
  public additionalMethods()
  {
    // implements...
  }
}

Вся архитектура проста:

Интерфейс AbstractDao определяет простые методы CRUD.

Интерфейс PersonDao расширяет AbstractDAO без каких-либо дополнительных методов.

class AbstractDaoJpaImpl определяет реализацию AbstractDao в JPA

class PersonDaoImpl расширяет AbstractDaoJpaImpl и реализует PersonDao AND OtherInterface, который добавляет aditionalMethods () ...

IF, PersonDaoImpl реализует только PersonDao, безреализуя OtherInterface.additionalMethods (), все работает отлично.

Я могу использовать 

<tx:annotation-driven transaction-manager="transactionManager" />

в XML-файле моей пружины.

НО, PersonDaoImpl реализует OtherInterface (s), при тестировании / запуске мне приходится приводить DAO из PersonDao в PersonDaoImpl или OtherInterfaces , например: 

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"classpath:app.xml"})
@TransactionConfiguration(transactionManager="transactionManager" , defaultRollback=false)
public class PersonDaoTest
{
  @Inject 
  PersonDao dao;

  @Test
  public void testAdditionalMethod()
  {
    PersonDaoImpl impl = (PersonDaoImpl) dao;
    System.out.println(impl.additionalMethod(...));
  }
}

Проблема возникает, когда (PersonDaoImpl) dao, чтоВыдает исключение «Прокси не может быть приведен к PersonDaoImpl»: 

java.lang.ClassCastException: $Proxy36 cannot be cast to foobar.PersonDaoImpl
    at foobar.PersonDaoTest.testAdditionalMethod(PersonDaoTest.java:36)

это часто спрашивают при поиске в Google, все предлагают добавить proxy-target-class="true" к <tx:annotation-driven>: 

<tx:annotation-driven transaction-manager="transactionManager" proxy-target-class="true"  />

Это сделаетиспользование CGLIB вместо динамического прокси JDK.

НО это выдает другое исключение при инициализации Spring: 

Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType

в конструкторе AbstractDaoJpaImpl: 

ParameterizedType genericSuperclass = (ParameterizedType) getClass().getGenericSuperclass();

Здесь все вопросы заканчиваются, Я не могу сейчас найти какие-либо рабочие решения.

Может кто-нибудь дать мне рабочее решение?Большое спасибо!

Среда: Spring-3.0.4, javaee-api-6.0, javax.inject, cglib-2.2, hibernate-jpa-2.0-api-1.0.0,

Ответы [ 2 ]

12 голосов
/ 04 октября 2010

Вы решаете не ту проблему. Проксированные бобы не предназначены для приведения к исходным классам, так или иначе. Это сломало бы весь смысл внедрения зависимости. В конце концов: когда вы указываете зависимость в качестве интерфейса, вы запрашиваете бин, выполняющий контракт, но не детали реализации. Приведение его к исходному классу бобов разрушает эту слабую связь.

Вы говорите, что дополнительные методы поддерживаются интерфейсом, который вы называете OtherInterface, так почему бы не использовать его вместо этого? В конце концов, прокси будет реализовывать все интерфейсы целевого класса, а не только внедренный. 

@Test
public void testAdditionalMethod()
{
    OtherInterface oi = (OtherInterface) dao;
    System.out.println(oi.additionalMethod(...));
}

В основном у вас есть следующие опции (отсортированные от чистых к грязным):

  1. Разделите ваши проблемы и используйте разные бобы для разных интерфейсы
  2. Создать мета-интерфейс, который расширяет OtherInterface и PersonDao и пусть ваш бин реализует это metainterface
  3. Привести компонент к интерфейсу вам нужно в любой момент.
0 голосов
/ 07 апреля 2011

да, Spring всегда создает прокси-классы, и именно так он на самом деле обнаружил не навязчивое переплетение и aop by xml config ... попробуйте поискать ошибки в документации по Spring, там должны быть правила, которым нужно следовать, и обходные пути

...