Итак, я решил это, когда я восстанавливал буфер обмена, у меня не было никаких задержек и из-за этого он не работал должным образом, теперь, после того, как я добавил небольшую задержку, все работает нормально, на случай, если у кого-то такая же проблема.
Не могу обнаружить ничего очевидного, поэтому просто предложение - вы пробовали использовать переплетение во время компиляции? Надеюсь, это приведет к согласованным результатам во время выполнения, хотя во время разработки может возникнуть немного больше проблем.
Когда инъекция не работает по какой-либо причине, код не может выполнить какую-либо проверку зависимостей, поэтому теперь возникает ошибка.
В противном случае я не вижу что-нибудь здесь, что указывало бы на случайный отказ. Можете ли вы извлечь упрощенный пример для проверки?
Во-первых, я должен сказать, что, вероятно, не рекомендуется вводить ресурсы, службы или другие bean-компоненты в классы модели данных в качестве зависимостей. Но это вопрос дизайна.
Что касается использования @Configurable, я использовал его в случаях, когда объекты создаются извне контекста Spring - например, пользовательские теги в веб-приложениях, фильтрах или сервлетах. Первый способ, которым я пытался их использовать, - это ткачество времени загрузки, как это делаете вы. Это работало довольно хорошо, но у него были некоторые недостатки, такие как развертывание горячего кода, когда отладка больше не работала.
Я также испытал именно ту проблему, которую вы описываете, и поэтому решил переключиться с ткачества времени загрузки на время компиляции. Поэтому я установил плагин AJDT в Eclipse и использовал поддержку aspecjt в Spring. Это решило мои проблемы.
Похоже, ваш процесс развертывания вызывает подозрения. Можете ли вы выполнить развертывание, которое работает, а затем скопировать его в каталог. Затем выполните еще одно развертывание, пока не получите то, что не работает. (В любом порядке) Затем, наконец, используйте такой инструмент, как Beyond compare, чтобы сравнить две структуры каталогов и файлы развертывания и посмотреть, есть ли какие-либо различия.
Удачи, ничего похожего на кажущуюся случайной проблему, которая убивает некоторую производительность.
Для меня это звучит как возникновение хорошо известной ошибки Spring: http://jira.springframework.org/browse/SPR-5401 .
Может быть, вы пытаетесь использовать Configurable в нескольких контекстах приложений? В этом случае только один из них будет подвергнут инъекции зависимости. Какой из них выиграет, зависит от того, какой контекст приложения загружается последним.
Решение? Нет :-( Планов по исправлению этой проблемы нет. По крайней мере, так сказал парень из SpringSource на конференции JAX в Германии в апреле.