Разрешающая типы поддокументе с Spring Data и MongoDB

Question

Я встречая ошибку с хранилищем Spring Data, как он пытается решить выражение свойства:

public interface ContractRepository 
    extends MongoRepository<Contract,String> { 
    public List<Contract> findByCodeBindings(String binding); 
} 

Вот соответствующие части Contract:

@Document(collection="CONTRACTS") 
public class PersistentContract extends BaseContract { 
    @PersistenceConstructor 
    public PersistentContract(String name, Version version, Code code) { 
     super(name, version, code); 
    } 
} 

Code - это интерфейс, реализованный CodeImpl. Он содержит свойство bindings, которое имеет геттер и сеттер в Code. Таким образом, выражение свойства запроса предназначено для поиска этих контрактов с вложенным документом кода, содержащим заданную привязку. Все идет нормально.

Однако, проблема заключается в IllegalArgumentException становится брошено:

java.lang.IllegalArgumentException: No property bindings found on my.company.Code! 
org.springframework.data.mapping.context.AbstractMappingContext.getPersistentPropertyPath(AbstractMappingContext.java:225) 

Debugging, что часть кода показывает, что Spring Data выбирает, кроме выражения и определяет, есть свойство типа Code. Однако, поскольку Code является интерфейсом, он не имеет перечисленных свойств.

Есть ли способ намекнуть на весну Данные, которые либо Code имеет это свойство, либо что CodeImpl является фактическим типом имущества code? Я удивлен, что библиотека не пытается разобрать геттеры или сеттеры интерфейса.

Это использование весенних данных для обмена данными 1.5.1.RELEASE и spring-data-mongodb 1.2.1.RELEASE.

Оцените справку.

Answer 1

Мое решение состояло в том, чтобы избежать взаимодействия вообще в постоянном объекте. Так BaseContract стали следующим:

public abstract class BaseContract<T extends Code> { 
    public T getCode(); 
} 

И PersistentContract был реализован в терминах конкретных классов:

public class PersistentContract extends BaseContract<CodeImpl> { 
} 

Это, кажется, правильный баланс между кодированием против интерфейсов в базовом классе и удовлетворяющей потребность Spring Дейтов для конкретных классов.