это, к сожалению, ошибка, возникающая время от времени при разработке с AspectJ.
Часто в пути к классам любого java-приложения присутствуют «мертвые» классы, то есть классы, которые находятся внутринекоторые jar, но никогда не используются.
Эти классы также часто пропускают свои зависимости.Например, Velocity (если не сказать одно, но большинство библиотек делают это) поставляется с классами для объединения многих средств ведения журналов, таких как log4j, ведение журналов Java и т. Д. Если вы хотите использовать одно из них, вам также необходимо включить его зависимость (например,log4j.jar), в противном случае, если вы не используете ее, вы не можете добавить эту зависимость.
Это само по себе не является проблемой при использовании библиотеки, поскольку эти классы никогда не будут загружены.Тем не менее, когда вы используете AspectJ, вещи немного меняются.
Предположим, у вас есть pointcut вроде:
execution(int MyClass+.getSomething())
Хотя этот pointcut кажется очень специфичным, он говорит «метод getSomething в любом подклассе».MyClass ".Это означает, что для того, чтобы узнать, соответствует ли определенный класс точечному сечению или нет, AspectJ должен проверять все суперклассы во время ткачества.
Но что произойдет, если AspectJ попытается сделать это на «мертвом классе», как указано выше??Он будет искать суперкласс и потерпит неудачу, потому что класс не используется и его зависимости не удовлетворены.
Обычно я инструктирую AspectJ, чтобы только предупредить меня в этой ситуации, вместо того, чтобы выдавать ошибку блокировки, вызвать 9 разиз 10 это происходит в мертвом коде и может быть безопасно проигнорировано.
Другой способ - определить, какой pointcut вызывает AspectJ, чтобы проверить этот класс и попытаться переписать его, чтобы область стала более строгой.Однако это не всегда возможно.
Грязный, но быстрый взлом мог бы написать:
execution(... MyClass+ ....) && !this(org.springframework.....)
Это (обычно) оптимизировано AspectJ, так что! This (....) завершается неудачно, прежде чем пытаться оценить полный pointcut выполнения .. но он связывает ваш pointcut с определенной ситуацией, поэтому полезен только для тестирования последней секунды, исправляющего работающую систему при поиске лучшего решения.
В этом случае виноват не AspectJ, а библиотеки с мертвыми классами, которые могут (и должны) быть размещены в отдельных модулях.Многие библиотеки не делают этого, чтобы избежать «распространения модулей» (например, каждая библиотека должна выпускать отдельные модули для каждой системы ведения журналов и т. Д.), Что является хорошим аргументом, но может быть легко и лучше решено с помощью недавнего управления модулями.систем (таких как Maven, Ivy и т. д.) вместо упаковки отдельных jar-файлов с тоннами классов с неудовлетворенными зависимостями, а затем с указанием в документации, что вам нужна эта зависимость для загрузки этого класса.