Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 354427

Summary:

Overridden @PC @PD methods do not get called if the overridden version is not annotated

Product:

[Eclipse Project] Platform

Reporter:

Remy Suen <remy.suen>

Component:

Runtime

Assignee:

platform-runtime-inbox <platform-runtime-inbox>

Status:

RESOLVED INVALID

QA Contact:

Severity:

major

Priority:

CC:

ob1.eclipse, pwebster

Version:

4.1

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Context tests patch v1	none

Description Remy Suen

2011-08-10 14:37:47 EDT

If a class defines @PreConstruct and @PreDestroy methods but they get overridden and their overridden versions are not annotated with those annotations then they do not get called.

Comment 1 Remy Suen

2011-08-11 08:04:55 EDT

Created attachment 201309 [details]
Context tests patch v1

Comment 2 Oleg Besedin

2011-10-03 10:55:15 EDT

After looking into it in more details, the current behavior is in line with the JSR 330.

The JSR does not define PreConstruct / PostDestory annotations, however, it goes into some details for the @Inject annotation.

For @Inject annotations it specifies that overridden methods (overridden in the Java language sense) that do not have "@Inject" annotation should be treated as if they remove the "@Inject" annotation from the method definition.

See, for instance, test  
 Convertible.Tests.testProtectedMethodNotInjectedWhenOverrideNotAnnotated()
in the TCK.

Comment 3 Paul Webster

2011-10-05 15:13:30 EDT

Remy, do we have examples in our own code that show this problem?  Or do we have API (more or less :-) where we expect the client to subclass (and would need to explicitly tell them in javadoc they *must* extend that method)?

PW

Comment 4 Remy Suen

2011-10-05 16:04:11 EDT

(In reply to comment #3)
> Remy, do we have examples in our own code that show this problem?  Or do we
> have API (more or less :-) where we expect the client to subclass (and would
> need to explicitly tell them in javadoc they *must* extend that method)?

None of our DI'd objects are API (they're usually just interfaces instead of abstract classes).

For protected and public methods we usually explicitly say whether the client should _extend_ or _override_ it with their own implementations.