3:31 a.m.
This thread is created when transaction subsystem starts and is active
through the life cycle of the application server. If failure happens in
any of the applications, periodic recovery finds the name of the
compensation handler in tx-object-store. That handler is a CDI bean
implemented by the application and has to be invoked in order to redo
the work of the application. We use BeanManager to instantiate that
handler and currently use JNDI to get it. Also, when compensate method
is invoked it is very likely that implementation of it will need access
to JNDI as well to get UserTransaction for example.
Additionally, before invoking the compensation handler we need to enable
application's class loader (I still need to figure out the best way to
store them, but I'm thinking of providing them to periodic recovery
during the deployment of each application). Would that class loader help
to solve JNDI issue or is there extra context I should save maybe?
Gytis
On 23/06/15 16:34, Stuart Douglas wrote:
I don't know if ManagedThreadFactory is a great option, as then
you
have a hard dependency on this being available, which may not be the
case in some cut down configurations.
Does this thread run in the context of a particular deployment,
otherwise this does not make a great deal of sense, as the JNDI
context is a per deployment construct.
If this is a per deployment thing then you can manually set up the per
deployment contexts using the actions
under org.jboss.as.server.deployment.Attachments#SETUP_ACTIONS.
Stuart
On Tue, 23 Jun 2015 at 16:21 Gytis Trikleris <gytis(a)redhat.com
<mailto:gytis@redhat.com>> wrote:
Hello,
I’ve got an issue with my subsystem
(https://github.com/wildfly/wildfly/tree/master/transactions)
where I cannot access BeanManager or UserTransaction from JNDI (I
can however lookup datasources). This error is currently happening
during periodic recovery i.e. on PeriodicRecovery thread. My
assumption is that the CDI and EE JNDI environment are not
initialized because PeriodicRecovery extends Thread and was
created with the “new” operator rather than ManagedThreadFactory
and I know that EE apps are meant to use this approach to ensure
their environments are initialized correctly - does this
restriction apply to subsystems too? One issue I am coming up
against during prototyping is that I’m not sure how to get the
ManagedThreadFactory during our subsystems boot time as it does
not appear in JNDI.
I would like to know if it is possible to inject the
ManagedThreadFactory into my subsystem so I am not reliant upon
its availability in JNDI.
Thanks,
Gytis
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev