@PostConstruct and @Inject methods in superclasses

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

@PostConstruct and @Inject methods in superclasses

Mark Struberg
Hi!

JSR-250 common annotations is pretty thin about having @PostConstruct in multiple class hierarchies. It just says that there must only be one single method annotated with @PostConstruct in a class. Thus my question:

If I have


public class Animal {
 @PostConstruct

 public void doInit() {..}
 ..

}

and 

 public class Horse extends Animal {
 @PostConstruct

 public void doSomeOtherInit() {..}
 ..

}


1.) for a contextual instance of Horse, will Animal#doInit() get executed or only the one from the 'effective' class?
2.) if 1.) was yes, then In which order do they get executed? Is this specced somewhere?

3.) Same scenario with @Inject methods. Do we specify an order?

4.) Both classes have @Inject methods and @PostConstruct. Again: which order of invocaition?


Just that you understand my intention: we had a @PostConstruct method in Horse which did set a 'cached' flag in Animal. Turned out that this was a random generator depending on the intsalled server ;)


LieGrue,
strub

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct and @Inject methods in superclasses

Stuart Douglas

This is actually covered by the interceptors specification, from memory I am pretty sure the base class method is mean't to be called first, but the spec gives you the full order.

@Inject methods are called before @PostConstuct (the are called in InjectionTarget.inject, which gets called before InjectionTarget.postConstruct).

I don't think we specify an order for @Inject methods.

Stuart

On 01/10/2011, at 5:47 AM, Mark Struberg wrote:

> Hi!
>
> JSR-250 common annotations is pretty thin about having @PostConstruct in multiple class hierarchies. It just says that there must only be one single method annotated with @PostConstruct in a class. Thus my question:
>
> If I have
>
>
> public class Animal {
>  @PostConstruct
>
>  public void doInit() {..}
>  ..
>
> }
>
> and
>
>  public class Horse extends Animal {
>  @PostConstruct
>
>  public void doSomeOtherInit() {..}
>  ..
>
> }
>
>
> 1.) for a contextual instance of Horse, will Animal#doInit() get executed or only the one from the 'effective' class?
> 2.) if 1.) was yes, then In which order do they get executed? Is this specced somewhere?
>
> 3.) Same scenario with @Inject methods. Do we specify an order?
>
> 4.) Both classes have @Inject methods and @PostConstruct. Again: which order of invocaition?
>
>
> Just that you understand my intention: we had a @PostConstruct method in Horse which did set a 'cached' flag in Animal. Turned out that this was a random generator depending on the intsalled server ;)
>
>
> LieGrue,
> strub
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct and @Inject methods in superclasses

Mark Struberg
Oki found it there:
> most general superclass first.
of course the interceptors_spec_1_1 only defines this for 'Lifycycle interceptors'

But what about my example 4, the shared @Inject method + @PostConstruct case?
Do we need to invoke all superclass injection first? thus do all @Inject fields + @Inject methods + @PostConstruct first, then the one from the Horse class?
Could we also specify that all @Inject methods needs to get called before @PostConstruct?

txs and LieGrue,
strub

--- On Fri, 9/30/11, Stuart Douglas <[hidden email]> wrote:

> From: Stuart Douglas <[hidden email]>
> Subject: Re: [cdi-dev] @PostConstruct and @Inject methods in superclasses
> To: "Mark Struberg" <[hidden email]>
> Cc: "cdi-dev" <[hidden email]>
> Date: Friday, September 30, 2011, 9:58 PM
>
> This is actually covered by the interceptors specification,
> from memory I am pretty sure the base class method is mean't
> to be called first, but the spec gives you the full order.
>
> @Inject methods are called before @PostConstuct (the are
> called in InjectionTarget.inject, which gets called before
> InjectionTarget.postConstruct).
>
> I don't think we specify an order for @Inject methods.
>
> Stuart
>
> On 01/10/2011, at 5:47 AM, Mark Struberg wrote:
>
> > Hi!
> >
> > JSR-250 common annotations is pretty thin about having
> @PostConstruct in multiple class hierarchies. It just says
> that there must only be one single method annotated with
> @PostConstruct in a class. Thus my question:
> >
> > If I have
> >
> >
> > public class Animal {
> >  @PostConstruct
> >
> >  public void doInit() {..}
> >  ..
> >
> > }
> >
> > and
> >
> >  public class Horse extends Animal {
> >  @PostConstruct
> >
> >  public void doSomeOtherInit() {..}
> >  ..
> >
> > }
> >
> >
> > 1.) for a contextual instance of Horse, will
> Animal#doInit() get executed or only the one from the
> 'effective' class?
> > 2.) if 1.) was yes, then In which order do they get
> executed? Is this specced somewhere?
> >
> > 3.) Same scenario with @Inject methods. Do we specify
> an order?
> >
> > 4.) Both classes have @Inject methods and
> @PostConstruct. Again: which order of invocaition?
> >
> >
> > Just that you understand my intention: we had a
> @PostConstruct method in Horse which did set a 'cached' flag
> in Animal. Turned out that this was a random generator
> depending on the intsalled server ;)
> >
> >
> > LieGrue,
> > strub
> >
> > _______________________________________________
> > cdi-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct and @Inject methods in superclasses

Stuart Douglas

On 01/10/2011, at 7:47 PM, Mark Struberg wrote:

Oki found it there:
most general superclass first.
of course the interceptors_spec_1_1 only defines this for 'Lifycycle interceptors'

The spec is not very clear on this point, but @PostConstruct methods on a bean are considered lifecycle interceptors. There is actually a fair bit of deviation between CDI and the interceptors and Managed bean spec on some points: 

- CDI beans don't support interceptor methods on the beans themselves (at least Weld does not, the interceptors spec allows you to have an @AroundInvoke method on the managed bean itself).
- @Resource @Psersitence* @EJB etc annotation of CDI managed beans do not create JNDI bindings like they are supposed to according to the EE platform spec.

As far as I know no one actually really uses these 'features' anyway, but it is a deviation from the spec that we should probably clarify.

Stuart



But what about my example 4, the shared @Inject method + @PostConstruct case?
Do we need to invoke all superclass injection first? thus do all @Inject fields + @Inject methods + @PostConstruct first, then the one from the Horse class?
Could we also specify that all @Inject methods needs to get called before @PostConstruct?

txs and LieGrue,
strub

--- On Fri, 9/30/11, Stuart Douglas <[hidden email]> wrote:

From: Stuart Douglas <[hidden email]>
Subject: Re: [cdi-dev] @PostConstruct and @Inject methods in superclasses
To: "Mark Struberg" <[hidden email]>
Cc: "cdi-dev" <[hidden email]>
Date: Friday, September 30, 2011, 9:58 PM

This is actually covered by the interceptors specification,
from memory I am pretty sure the base class method is mean't
to be called first, but the spec gives you the full order.

@Inject methods are called before @PostConstuct (the are
called in InjectionTarget.inject, which gets called before
InjectionTarget.postConstruct).

I don't think we specify an order for @Inject methods.

Stuart

On 01/10/2011, at 5:47 AM, Mark Struberg wrote:

Hi!

JSR-250 common annotations is pretty thin about having
@PostConstruct in multiple class hierarchies. It just says
that there must only be one single method annotated with
@PostConstruct in a class. Thus my question:

If I have


public class Animal {
  @PostConstruct

  public void doInit() {..}
  ..

}

and

  public class Horse extends Animal {
  @PostConstruct

  public void doSomeOtherInit() {..}
  ..

}


1.) for a contextual instance of Horse, will
Animal#doInit() get executed or only the one from the
'effective' class?
2.) if 1.) was yes, then In which order do they get
executed? Is this specced somewhere?

3.) Same scenario with @Inject methods. Do we specify
an order?

4.) Both classes have @Inject methods and
@PostConstruct. Again: which order of invocaition?


Just that you understand my intention: we had a
@PostConstruct method in Horse which did set a 'cached' flag
in Animal. Turned out that this was a random generator
depending on the intsalled server ;)


LieGrue,
strub

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev




_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct and @Inject methods in superclasses

Pete Muir
Administrator
There is no need to refer to the interceptors spec to understand this. But the discussions about the interceptors spec is interesting :-)

>> But what about my example 4, the shared @Inject method + @PostConstruct case?
>> Do we need to invoke all superclass injection first? thus do all @Inject fields + @Inject methods + @PostConstruct first, then the one from the Horse class?
>> Could we also specify that all @Inject methods needs to get called before @PostConstruct?

JSR-330 says that injected fields happen before methods, and always superclass-first i.e.

class X extends Y { ... }

any injected field in Y, followed by any injected method in Y followed by any injected field in X followed by any injected method in X.

CDI then covers the @PostConstruct in 5.5.2 of the CDI spec.

The container must ensure that:
• Initializer methods declared by a class X in the type hierarchy of the bean are called after all injected fields declared by X or by superclasses of X have been initialized, and after all Java EE component environment resource dependencies declared by X or by superclasses of X have been injected.
• Any @PostConstruct callback declared by a class X in the type hierarchy of the bean is called after all initializer meth- ods declared by X or by superclasses of X have been called, after all injected fields declared by X or by superclasses of X have been initialized, and after all Java EE component environment resource dependencies declared by X or by su- perclasses of X have been injected.

Thus,

You can be assured that the @PostConstruct for Y happens after injection, and the same for X. However you can't be certain that the @PostConstruct for Y happens before the injection for X.

Do we need to clarify this? I'm not sure we do? If we do, why?

On 1 Oct 2011, at 06:21, Stuart Douglas wrote:

>
> On 01/10/2011, at 7:47 PM, Mark Struberg wrote:
>
>> Oki found it there:
>>> most general superclass first.
>> of course the interceptors_spec_1_1 only defines this for 'Lifycycle interceptors'
>
> The spec is not very clear on this point, but @PostConstruct methods on a bean are considered lifecycle interceptors.

Correct. I think this would need clarifying in the interceptors spec - Mark could you file an EJB spec issue for this?

> There is actually a fair bit of deviation between CDI and the interceptors and Managed bean spec on some points:
>
> - CDI beans don't support interceptor methods on the beans themselves (at least Weld does not, the interceptors spec allows you to have an @AroundInvoke method on the managed bean itself).

Wow, I totally missed that before. I think this is just a bug in Weld. Could you create an issue?

> - @Resource @Psersitence* @EJB etc annotation of CDI managed beans do not create JNDI bindings like they are supposed to according to the EE platform spec.

This is partly a Weld bug, partly a Java EE integration issue, which never got resolved properly. The CDI spec doesn't define this, where is it in Java EE? If it's there, then it's an impl bug, not a spec clarification I think.

>
> As far as I know no one actually really uses these 'features' anyway, but it is a deviation from the spec that we should probably clarify.
>
> Stuart
>


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct and @Inject methods in superclasses

Stuart Douglas

On 02/10/2011, at 2:16 PM, Pete Muir wrote:

There is no need to refer to the interceptors spec to understand this. But the discussions about the interceptors spec is interesting :-)

But what about my example 4, the shared @Inject method + @PostConstruct case?
Do we need to invoke all superclass injection first? thus do all @Inject fields + @Inject methods + @PostConstruct first, then the one from the Horse class?
Could we also specify that all @Inject methods needs to get called before @PostConstruct?

JSR-330 says that injected fields happen before methods, and always superclass-first i.e.

class X extends Y { ... }

any injected field in Y, followed by any injected method in Y followed by any injected field in X followed by any injected method in X.

CDI then covers the @PostConstruct in 5.5.2 of the CDI spec.

The container must ensure that:
Initializer methods declared by a class X in the type hierarchy of the bean are called after all injected fields declared by X or by superclasses of X have been initialized, and after all Java EE component environment resource dependencies declared by X or by superclasses of X have been injected.
Any @PostConstruct callback declared by a class X in the type hierarchy of the bean is called after all initializer meth- ods declared by X or by superclasses of X have been called, after all injected fields declared by X or by superclasses of X have been initialized, and after all Java EE component environment resource dependencies declared by X or by su- perclasses of X have been injected.

Thus,

You can be assured that the @PostConstruct for Y happens after injection, and the same for X. However you can't be certain that the @PostConstruct for Y happens before the injection for X.

Do we need to clarify this? I'm not sure we do? If we do, why?

I don't think this needs clarification.


On 1 Oct 2011, at 06:21, Stuart Douglas wrote:


On 01/10/2011, at 7:47 PM, Mark Struberg wrote:

Oki found it there:
most general superclass first.
of course the interceptors_spec_1_1 only defines this for 'Lifycycle interceptors'

The spec is not very clear on this point, but @PostConstruct methods on a bean are considered lifecycle interceptors.

Correct. I think this would need clarifying in the interceptors spec - Mark could you file an EJB spec issue for this?

There is actually a fair bit of deviation between CDI and the interceptors and Managed bean spec on some points:

- CDI beans don't support interceptor methods on the beans themselves (at least Weld does not, the interceptors spec allows you to have an @AroundInvoke method on the managed bean itself).

Wow, I totally missed that before. I think this is just a bug in Weld. Could you create an issue?



- @Resource @Psersitence* @EJB etc annotation of CDI managed beans do not create JNDI bindings like they are supposed to according to the EE platform spec.

This is partly a Weld bug, partly a Java EE integration issue, which never got resolved properly. The CDI spec doesn't define this, where is it in Java EE? If it's there, then it's an impl bug, not a spec clarification I think.


This is partly defined by the 'Common Annotations for the Java Platform' spec, and by chapter 5 in the EE platform spec (the section on resources naming and injection).

Stuart


As far as I know no one actually really uses these 'features' anyway, but it is a deviation from the spec that we should probably clarify.

Stuart




_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct and @Inject methods in superclasses

Stuart Douglas
In reply to this post by Pete Muir

On 02/10/2011, at 2:16 PM, Pete Muir wrote:

> There is no need to refer to the interceptors spec to understand this. But the discussions about the interceptors spec is interesting :-)
>
>>> But what about my example 4, the shared @Inject method + @PostConstruct case?
>>> Do we need to invoke all superclass injection first? thus do all @Inject fields + @Inject methods + @PostConstruct first, then the one from the Horse class?
>>> Could we also specify that all @Inject methods needs to get called before @PostConstruct?
>
> JSR-330 says that injected fields happen before methods, and always superclass-first i.e.
>
> class X extends Y { ... }
>
> any injected field in Y, followed by any injected method in Y followed by any injected field in X followed by any injected method in X.
>
> CDI then covers the @PostConstruct in 5.5.2 of the CDI spec.
>
> The container must ensure that:
> • Initializer methods declared by a class X in the type hierarchy of the bean are called after all injected fields declared by X or by superclasses of X have been initialized, and after all Java EE component environment resource dependencies declared by X or by superclasses of X have been injected.
> • Any @PostConstruct callback declared by a class X in the type hierarchy of the bean is called after all initializer meth- ods declared by X or by superclasses of X have been called, after all injected fields declared by X or by superclasses of X have been initialized, and after all Java EE component environment resource dependencies declared by X or by su- perclasses of X have been injected.
>
> Thus,
>
> You can be assured that the @PostConstruct for Y happens after injection, and the same for X. However you can't be certain that the @PostConstruct for Y happens before the injection for X.
>
> Do we need to clarify this? I'm not sure we do? If we do, why?
>
> On 1 Oct 2011, at 06:21, Stuart Douglas wrote:
>
>>
>> On 01/10/2011, at 7:47 PM, Mark Struberg wrote:
>>
>>> Oki found it there:
>>>> most general superclass first.
>>> of course the interceptors_spec_1_1 only defines this for 'Lifycycle interceptors'
>>
>> The spec is not very clear on this point, but @PostConstruct methods on a bean are considered lifecycle interceptors.
>
> Correct. I think this would need clarifying in the interceptors spec - Mark could you file an EJB spec issue for this?
>
>> There is actually a fair bit of deviation between CDI and the interceptors and Managed bean spec on some points:
>>
>> - CDI beans don't support interceptor methods on the beans themselves (at least Weld does not, the interceptors spec allows you to have an @AroundInvoke method on the managed bean itself).
>
> Wow, I totally missed that before. I think this is just a bug in Weld. Could you create an issue?

Actually it looks like I was wrong, weld does support this, for some reason I did not think it did. I really should have double checked before sending.

Stuart

>
>> - @Resource @Psersitence* @EJB etc annotation of CDI managed beans do not create JNDI bindings like they are supposed to according to the EE platform spec.
>
> This is partly a Weld bug, partly a Java EE integration issue, which never got resolved properly. The CDI spec doesn't define this, where is it in Java EE? If it's there, then it's an impl bug, not a spec clarification I think.
>
>>
>> As far as I know no one actually really uses these 'features' anyway, but it is a deviation from the spec that we should probably clarify.
>>
>> Stuart
>>
>


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct and @Inject methods in superclasses

Pete Muir
Administrator
In reply to this post by Stuart Douglas

On 1 Oct 2011, at 20:44, Stuart Douglas wrote:
>>
>>> - @Resource @Psersitence* @EJB etc annotation of CDI managed beans do not create JNDI bindings like they are supposed to according to the EE platform spec.
>>
>> This is partly a Weld bug, partly a Java EE integration issue, which never got resolved properly. The CDI spec doesn't define this, where is it in Java EE? If it's there, then it's an impl bug, not a spec clarification I think.
>>
>
> This is partly defined by the 'Common Annotations for the Java Platform' spec, and by chapter 5 in the EE platform spec (the section on resources naming and injection).

All, recommendations for how to best resolve this?

I assume that we should create JNDI bindings for this? EE/JNDI experts?
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: @PostConstruct and @Inject methods in superclasses

Marius Bogoevici
In reply to this post by Stuart Douglas
On Sat, 2011-10-01 at 23:21 +1000, Stuart Douglas wrote:

>
> On 01/10/2011, at 7:47 PM, Mark Struberg wrote:
>
> > Oki found it there:
> > > most general superclass first.
> > of course the interceptors_spec_1_1 only defines this for 'Lifycycle
> > interceptors'
> >
>
>
> The spec is not very clear on this point, but @PostConstruct methods
> on a bean are considered lifecycle interceptors. There is actually a
> fair bit of deviation between CDI and the interceptors and Managed
> bean spec on some points:
>
>
> - CDI beans don't support interceptor methods on the beans themselves
> (at least Weld does not, the interceptors spec allows you to have an
> @AroundInvoke method on the managed bean itself).

That's not correct. In Weld you should be able to have @AroundInvoke
methods on the beans themselves alright, unless that was explicitly
disabled since 1.1. If that doesn't work, it's definitely a bug.

> - @Resource @Psersitence* @EJB etc annotation of CDI managed beans do
> not create JNDI bindings like they are supposed to according to the EE
> platform spec.
>
>
> As far as I know no one actually really uses these 'features' anyway,
> but it is a deviation from the spec that we should probably clarify.
>
>
> Stuart
>
>
>
> >
> > But what about my example 4, the shared @Inject method +
> > @PostConstruct case?
> > Do we need to invoke all superclass injection first? thus do all
> > @Inject fields + @Inject methods + @PostConstruct first, then the
> > one from the Horse class?
> > Could we also specify that all @Inject methods needs to get called
> > before @PostConstruct?
> >
> >
> > txs and LieGrue,
> > strub
> >
> > --- On Fri, 9/30/11, Stuart Douglas <[hidden email]>
> > wrote:
> >
> > > From: Stuart Douglas <[hidden email]>
> > > Subject: Re: [cdi-dev] @PostConstruct and @Inject methods in
> > > superclasses
> > > To: "Mark Struberg" <[hidden email]>
> > > Cc: "cdi-dev" <[hidden email]>
> > > Date: Friday, September 30, 2011, 9:58 PM
> > >
> > > This is actually covered by the interceptors specification,
> > > from memory I am pretty sure the base class method is mean't
> > > to be called first, but the spec gives you the full order.
> > >
> > > @Inject methods are called before @PostConstuct (the are
> > > called in InjectionTarget.inject, which gets called before
> > > InjectionTarget.postConstruct).
> > >
> > > I don't think we specify an order for @Inject methods.
> > >
> > > Stuart
> > >
> > > On 01/10/2011, at 5:47 AM, Mark Struberg wrote:
> > >
> > > > Hi!
> > > >
> > > > JSR-250 common annotations is pretty thin about having
> > > @PostConstruct in multiple class hierarchies. It just says
> > > that there must only be one single method annotated with
> > > @PostConstruct in a class. Thus my question:
> > > >
> > > > If I have
> > > >
> > > >
> > > > public class Animal {
> > > >   @PostConstruct
> > > >
> > > >   public void doInit() {..}
> > > >   ..
> > > >
> > > > }
> > > >
> > > > and
> > > >
> > > >   public class Horse extends Animal {
> > > >   @PostConstruct
> > > >
> > > >   public void doSomeOtherInit() {..}
> > > >   ..
> > > >
> > > > }
> > > >
> > > >
> > > > 1.) for a contextual instance of Horse, will
> > > Animal#doInit() get executed or only the one from the
> > > 'effective' class?
> > > > 2.) if 1.) was yes, then In which order do they get
> > > executed? Is this specced somewhere?
> > > >
> > > > 3.) Same scenario with @Inject methods. Do we specify
> > > an order?
> > > >
> > > > 4.) Both classes have @Inject methods and
> > > @PostConstruct. Again: which order of invocaition?
> > > >
> > > >
> > > > Just that you understand my intention: we had a
> > > @PostConstruct method in Horse which did set a 'cached' flag
> > > in Animal. Turned out that this was a random generator
> > > depending on the intsalled server ;)
> > > >
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > > _______________________________________________
> > > > cdi-dev mailing list
> > > > [hidden email]
> > > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > >
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev