[
https://issues.redhat.com/browse/JBTM-3243?page=com.atlassian.jira.plugin...
]
Thomas Jenkinson commented on JBTM-3243:
----------------------------------------
Given that
https://jakarta.ee/specifications/platform/8/apidocs/javax/enterprise/con...
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-j...
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/Pos...
instead of looking for the initialized event? Especially given until the
https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j...
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/Pre... on
LRAService instead? I note
https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j...
seems to be a no-op - I would wonder why
https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...
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)