[wildfly-dev] Getting ManagedThreadFactory in a subsystem

[Stuart Douglas]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150623/bc79a4e7/attachment.html