Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ObserverMethod#getDeclaringBean method. #578

Merged
merged 1 commit into from Dec 7, 2021

Conversation

manovotn
Copy link
Contributor

@manovotn manovotn commented Dec 7, 2021

Fixes #563

I am deliberately keeping the return value for synth observers undefined because I understand some implementations can choose to return null but in Weld this is apparently never the case and instead synth. OMs belong to the extension declaring them.

@manovotn manovotn requested a review from Ladicek December 7, 2021 16:07
@Ladicek
Copy link
Contributor

Ladicek commented Dec 7, 2021

The Build Compatible Extension API demands that for synthetic observers, ObserverInfo.bean() returns null. Can that be implemented on top of this?

@manovotn
Copy link
Contributor Author

manovotn commented Dec 7, 2021

The Build Compatible Extension API demands that for synthetic observers, ObserverInfo.bean() returns null. Can that be implemented on top of this?

@Ladicek that sounds like a mistake we made. I think the declaring class and the declaring bean are both (in case of Portable Extensions) derived from https://github.com/eclipse-ee4j/cdi/blob/master/api/src/main/java/jakarta/enterprise/inject/spi/configurator/ObserverMethodConfigurator.java#L76-L82
According to spec, it'll always result in a non-null value. On top of that, for your StillDI impl, I expect this to default to the class of the Portable Extension via which we implement build compatible extensions.

So the way I see it, we have two options:

  • State in Lite it is undefined return value for synth observers
  • State in Lite that the return value is the extension defining it
    • I don't think this is possible because in Lite, compatible extensions are not beans

@Ladicek
Copy link
Contributor

Ladicek commented Dec 7, 2021

Actually I'm looking at it again and it seems even my ObserverInfo.isSynthetic() method implementation is wrong (because ProcessSyntheticObserverMethod.getAnnotatedMethod() is non-portable). Wow.

@Ladicek
Copy link
Contributor

Ladicek commented Dec 7, 2021

At the same time, one can distinguish synthetic observers from non-synthetic by the event type, and so it is not necessary to invoke any of these non-portable methods. So it's all good.

@Ladicek
Copy link
Contributor

Ladicek commented Dec 7, 2021

With this change weld/core#2605, all should be fine and this can be merged.

@manovotn
Copy link
Contributor Author

manovotn commented Dec 7, 2021

With this change weld/core#2605, all should be fine and this can be merged.

Thanks a lot for that!

@Ladicek Ladicek merged commit 7da8202 into jakartaee:master Dec 7, 2021
@manovotn manovotn deleted the issue563 branch December 7, 2021 17:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Portable Extension's ObserverMethod doesn't expose the declaring Bean
2 participants