[jbossts-issues] [JBoss JIRA] (JBTM-3243) Observer method for ApplicationScoped bean destruction creates a new bean

[Thomas Jenkinson (Jira)]

    [ https://issues.redhat.com/browse/JBTM-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945634#comment-13945634 ] 

Thomas Jenkinson commented on JBTM-3243:
----------------------------------------

Given that https://jakarta.ee/specifications/platform/8/apidocs/javax/enterprise/context/control/ActivateRequestContext.html seems like it might also create a new bean (perhaps request scoped?), I am wondering if this hints there is actually a problem with the way the LRAService is set up to observe these events in general.

I think https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L400 would be expected to use the init param in it's initialization routine. But I also think that in order to do so we should be checking that the bean that has been initialized is actually an LRAService and not just any application scoped bean. Unless I am misunderstanding CDI and the code I don't think just any applicationscoped bean being initialized would prevent this method from firing. But I do wonder if we might be able to use https://jakarta.ee/specifications/platform/8/apidocs/javax/annotation/PostConstruct.html instead of looking for the initialized event? Especially given until the https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/internal/Implementations.java#L55 call is executed I don't think LRA would really be considered fully initialized and so perhaps race conditions could occur where the recordtypemanager was not correctly set up?

Regarding the destruction handling, does it definitely have to be after LRAService is destroyed? Perhaps the recovery module could be unloaded during a https://jakarta.ee/specifications/platform/8/apidocs/javax/annotation/PreDestroy.html on LRAService instead? I note https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L419 seems to be a no-op - I would wonder why https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/abstractrecord/RecordTypeManager.java#L85 is not called, but then PreDestroy might be too early and perhaps in that case a separate RequestScoped bean will need to be added to observe the LRAService being destroyed and perform these steps.

> Observer method for ApplicationScoped bean destruction creates a new bean
> -------------------------------------------------------------------------
>
>                 Key: JBTM-3243
>                 URL: https://issues.redhat.com/browse/JBTM-3243
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.10.1.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.next
>
>
> The LRA implementation needs to observe application shutdown in order to perform clean up activities. It achieves this using an ApplicationScoped bean. But when the destroyed event is fired a new bean may be created which is not what we want with an application scoped bean (this behaviour is seen when running as a Quarkus app). Annotating the method with `@ActivateRequestContext` will ensure the correct application scoped bean used. So instead of
> {code}
> void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore)
> {code}
> use
> {code}
>     @ActivateRequestContext
>     void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) {
> {code}



--
This message was sent by Atlassian Jira
(v7.13.8#713008)