好了,有几种方法可以实现代理对象。但是,由于您希望代理与被代理bean具有“相同”类型,因此您必须使用继承(或您随后可以实现的需求接口,但这不是每个POJO都可以是一个bean的方法)
CDI)。
也就是说,它们从您要注入的类内部扩展,围绕该类生成一些代理代码,然后为您提供该子类。
然后,该代理将处理所有魔术,以确保您始终有一个适合您上下文的bean(并且该bean的所有成员变量bean均指向正确的bean)。
因此,您实际上并没有收到要注入的bean的类型,而是该bean的代理子类。这对于最终方法和类以及私有构造函数而言效果不佳。
如果该类不是final,则代理可以扩展该类,但是它不能轻易覆盖您的final方法。但是,这可能是需要的(例如,如果您的bean已序列化,则代理需要对其进行反序列化)。
有更复杂的方法可以解决。可以通过通过代理 *** 作类的字节码来注入此功能(例如,删除最终修饰符,注入默认构造函数等),甚至可以将其与继承混合使用,但这还没有实现(和同样对支持多个JVM实现也很重要)。
在链接的资源中,有一条注释表明已计划在将来的发行版中使用:
注意
未来的Weld版本可能会使用非便携式JVM
API支持针对此限制的非标准解决方法:Sun,IcedTea,Mac:Unsafe.allocateInstance()(最高效)IBM,JRockit:ReflectionFactory.newConstructorForSerialization()但是我们还没有实现这个目标。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)