<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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?<br>
<br>
Gytis<br>
<br>
<div class="moz-cite-prefix">On 23/06/15 16:34, Stuart Douglas
wrote:<br>
</div>
<blockquote
cite="mid:CAAoo=c5PNFpSec=PaUCQL6e-BVhzM3H-DzxJmeV9i-85NZjU5g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Stuart</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, 23 Jun 2015 at 16:21 Gytis Trikleris <<a
moz-do-not-send="true" href="mailto:gytis@redhat.com">gytis@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hello,<br>
<br>
I’ve got an issue with my subsystem (<a
moz-do-not-send="true"
href="https://github.com/wildfly/wildfly/tree/master/transactions"
target="_blank">https://github.com/wildfly/wildfly/tree/master/transactions</a>)
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
Gytis<br>
</div>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote>
</div>
</blockquote>
<br>
</body>
</html>