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> 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
https://lists.jboss.org/mailman/listinfo/wildfly-dev