好，我已经解决了问题。本质上，与一些自定义扩展一起，这是一个Spring问题。如果有人遇到类似的问题，我将尝试逐步解释正在发生的事情。
首先，我们
BeanDefintionParser在项目中有一个自定义项。此类具有以下定义：
private static class ControllerBeanDefinitionParser extends AbstractSingleBeanDefinitionParser { protected Class<?> getBeanClass(Element element) { try { return Class.forName(element.getAttribute("class")); } catch (ClassNotFoundException e) { throw new RuntimeException("Class " + element.getAttribute("class") + "not found.", e); } }// pre to parse XML omitted for brevity}现在，在读取完所有bean定义并
BeanDefinitionRegistryPostProcessor开始执行之后，就会出现问题。在此阶段，一个名为的类
ConfigurationClassPostProcessor开始浏览所有bean定义，以搜索带有注
释@Configuration或具有方法的Bean类
@Bean。
在读取bean的注释的过程中，它使用
Annotationmetadata接口。对于大多数常规bean，使用一个称为的子类
AnnotationmetadataVisitor。但是，在解析Bean定义时，如果您已重写
getBeanClass()方法以返回类实例（如我们以前的方法），则将
StandardAnnotationmetadata使用实例。当
StandardAnnotationmetadata.hasAnnotatedMethods(..)被调用时，它调用
Class.getDeclaredMethods()，这又导致的类加载器加载用作该类参数的所有类。以这种方式加载的类未正确卸载，因此从不进行编织，因为这是在AspectJ转换器注册之前发生的。
现在，我的问题是我上了这样的课：
public class Something {
private Lang lang;
public void setLang(Lang lang) {
this.lang = lang;
}
}
然后，我有了一个
Something使用我们的
custom解析的类
bean ControllerBeanDefinitionParser。这触发了错误的注释检测过程，从而触发了意外的类加载，这意味着AspectJ从未有过编织的机会
Lang。
解决方案是不重写
getBeanClass(..)，而是重写
getBeanClassName(..)，根据文档，这是更可取的：
private static class ControllerBeanDefinitionParser extends AbstractSingleBeanDefinitionParser { protected String getBeanClassName(Element element) { return element.getAttribute("class"); }// pre to parse XML omitted for brevity}每日经验教训：
getBeanClass除非您真的是认真的，否则请不要覆盖。实际上，除非您知道自己在做什么，否则不要尝试编写自己的BeanDefinitionParser。
