Как заставить JPA EntityListeners проверять существование интерфейса - PullRequest
2 голосов
/ 14 сентября 2011

Я работаю в J2EE 5 с использованием JPA, у меня есть рабочее решение, но я хочу очистить структуру.

Я использую EntityListeners на некоторых объектах JPA, которые я сохраняю, слушатели довольно универсальны, но зависят от bean-компонентов, реализующих интерфейс, это прекрасно работает, если вы не забудете добавить интерфейс.

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

@Entity
@EntityListener({CreateByListener.class})
public class Note implements CreatorInterface{
    private String message;....
    private String creator;
    ....
}

public interface CreatorInterface{
    public void setCreator(String creator);
}

public class CreateByListener {
    @PrePersist
    public void dataPersist(CreatorInterface data){
        SUser user = LoginModule.getUser();
        data.setCreator(user.getName());
    }
}

Это работает точно так, как я хочу, за исключением случаев, когда создается новый класс, и он использует CreateByListener, но не реализует CreatorInterface. Когда это происходит, исключение приведения к классу выдается где-то глубоко внутри движка JPA, и только если я вспомню этот симптом, я смогу выяснить, что пошло не так.

Мне не удалось найти способ требовать интерфейса или проверить наличие интерфейса, прежде чем слушатель будет запущен.

Любые идеи будут оценены.

1 Ответ

2 голосов
/ 14 сентября 2011
@PrePersist
public void dataPersist(Object data){
    if (!(data instanceof CreatorInterface)) {
        throw new IllegalArgumentException("The class " 
                                           + data.getClass() 
                                           + " should implement CreatorInterface");
    }
    CreatorInterface creatorInterface = (CreatorInterface) data;
    SUser user = LoginModule.getUser();
    creatorInterface.setCreator(user.getName());
}

Это в основном то же самое, что и вы, но по крайней мере у вас будет более читаемое сообщение об ошибке, указывающее, что не так, вместо ClassCastException.

...