不调用@PostConstruct的抽象祖先 [英] @PostConstruct of abstract ancestors are not invoked

问题描述

我正在写一个JAX-RS库（不是应用程序）。

I'm writing a JAX-RS library (not an application).

我有：

abstract class A {

    @PostConstruct
    private void constructed_a() {} // not invoked

    @Inject
    private Some some;
}


public abstract class B extends A {

    @PostConstruct
    private void constructed_b() {} // not invoked
}

测试类：

@Path("c")
public class C extends B {

    @PostConstrct
    private void constructed_c() {} // invoked
}

我正在测试jersey test framework v2.17

I'm testing with jersey test framework v2.17

我发现只调用 construct_c（），并且不调用祖先定义的那些方法。请注意，在类 A @Inject 声明的字段（ some ） $ c>已正确注入。

I found that only constructed_c() is invoked and those method defined in ancestors are not invoked. Note that the field(some) declared with @Inject in class A is properly injected.

这是正常的吗？我该怎么办？

Is this normal? What should I do?

结论

我使用embedded-glassfish进行了测试，发现正如Antonin Stefanutti指出的那样，这些回调方法按预期顺序调用。

I tested with embedded-glassfish and found that, as Antonin Stefanutti pointed, those callback methods invoked in order as expected.

constructed_a()
constructed_b()
constructed_c()

推荐答案

根据上声明的拦截器的调用顺序 - 1-2-mrel.pdfrel =noreferrer> JSR 318 - 拦截器1.2 规范：

声明的拦截器方法在目标类或其超类
按以下顺序调用：

Interceptor methods declared on the target class or its superclasses are invoked in the following order:

• 如果目标类具有超类，则任何拦截器方法在这些超类上定义的是第一个超类。


• 拦截器方法，如果有的话，在调用目标类本身。

如果一个拦截器方法被另一个方法覆盖（无论该方法本身是否为
）一个拦截器方法），它不会被调用
。

If an interceptor method is overridden by another method (regardless of whether that method is itself an interceptor method), it will not be invoked.

这意味着在编写库/框架时，它是在父类和子类中使用 @PostConstruct 生命周期回调时可以实现可扩展性。

That means that when writing a library / framework, it is possible to achieve extensibility while using the @PostConstruct lifecyle callback both in the parent class and the child class.

机制在Camel CDI扩展中使用，它在 @PostConstruct 生命周期回调的默认Camel上下文-cdi / blob / b6f52d91b247e36eefb6f3ecde61016d681d3535 / impl / src / main / java / org / apache / camel / cdi / CdiCamelContext.java＃L37rel =noreferrer> https://github.com/astefanutti/camel-cdi/blob /b6f52d91b247e36eefb6f3ecde61016d681d3535/impl/src/main/java/org/apache/camel/cdi/CdiCamelContext.java#L37

That mechanism is used in the Camel CDI extension that declares a default Camel context with a @PostConstruct lifecycle callback in https://github.com/astefanutti/camel-cdi/blob/b6f52d91b247e36eefb6f3ecde61016d681d3535/impl/src/main/java/org/apache/camel/cdi/CdiCamelContext.java#L37

这可以是用户扩展，如 https://github.com/astefanutti/camel-cdi/blob/b6f52d91b247e36eefb6f3ecde61016d681d3535/envs/se/src/main/java/org/apache/camel/cdi/se/ bean / CustomLifecycleCamelContext.java＃L37 声明自己的 @PostConstruct 生命周期回调。

And that can be extended by users like in https://github.com/astefanutti/camel-cdi/blob/b6f52d91b247e36eefb6f3ecde61016d681d3535/envs/se/src/main/java/org/apache/camel/cdi/se/bean/CustomLifecycleCamelContext.java#L37 that declares its own @PostConstruct lifecycle callback.

两者都是按照指定的顺序由容器调用。

Both being called by the container following the specified order.

这意味着从设计的角度来看，您的方法是正确的。但是，由于泽西依赖注入基于HK2而不是CDI并依赖于像 jersey-gf-cdi 这样的桥梁，因此可能存在该级别的问题。

That means that your approach is correct from the design standpoint. However, as Jersey dependency injection is based on HK2 and not CDI and relies on bridges like jersey-gf-cdi there might be an issue at that level.

这篇关于不调用@PostConstruct的抽象祖先的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！