ManagedThreadFactory is useful only for app code, it creates threads which run its task
with the invocation context (class loader, jndi, security, etc.) present when the thread
was created. From what I understood on your previous mail you want to create a subsystem
owned thread, thus makes no sense to use the ManagedThreadFactory to create it.
By the way, JNDI is truly an app code resource, subsystem code should use a MSC service
that is injected (through a dependency) with what was bound to JNDI, for instance the
UserTransaction is managed by the service named
org.jboss.as.txn.service.UserTransactionService.SERVICE_NAME
so for a subsystem’s service to depend on it, and get injected with its value, on its
creation do:
serviceBuilder.addDependency(UserTransactionService.SERVICE_NAME, UserTransaction.class,
service.getValueToInjectWithUserTransaction());
Same recipe for BeanManager or any other resource, all you need is to find the name of the
service that manages it. But beware, the subsystem will then depend on the subsystem
managing such resource…
—E
On 24 Jun 2015, at 09:31, Gytis Trikleris <gytis(a)redhat.com>
wrote:
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
<
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
<
https://lists.jboss.org/mailman/listinfo/wildfly-dev>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev