<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.&nbsp;<div class=""><br class=""></div><div class="">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</div><div class=""><br class=""></div><div class="">org.jboss.as.txn.service.UserTransactionService.SERVICE_NAME</div><div class=""><br class=""></div><div class="">so for a subsystem’s service to depend on it, and get injected with its value, on its creation do:</div><div class=""><br class=""></div><div class="">serviceBuilder.addDependency(UserTransactionService.SERVICE_NAME, UserTransaction.class, service.getValueToInjectWithUserTransaction());</div><div class=""><br class=""></div><div class="">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…</div><div class=""><br class=""></div><div class="">—E</div><div class=""><br class=""></div><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On 24 Jun 2015, at 09:31, Gytis Trikleris &lt;<a href="mailto:gytis@redhat.com" class="">gytis@redhat.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class="">
    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 class="">
    <br class="">
    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 class="">
    <br class="">
    Gytis<br class="">
    <br class="">
    <div class="moz-cite-prefix">On 23/06/15 16:34, Stuart Douglas
      wrote:<br class="">
    </div>
    <blockquote cite="mid:CAAoo=c5PNFpSec=PaUCQL6e-BVhzM3H-DzxJmeV9i-85NZjU5g@mail.gmail.com" type="cite" class="">
      <div dir="ltr" class="">
        <div class="">I don't know if ManagedThreadFactory is a great option, as
          then you have a hard dependency on this being available,
          &nbsp;which may not be the case in some cut down configurations.&nbsp;</div>
        <div class=""><br class="">
        </div>
        <div class="">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.&nbsp;</div>
        <div class=""><br class="">
        </div>
        <div class="">If this is a per deployment thing then you can manually set
          up the per deployment contexts using the actions
          under&nbsp;org.jboss.as.server.deployment.Attachments#SETUP_ACTIONS.</div>
        <div class=""><br class="">
        </div>
        <div class="">Stuart</div>
      </div>
      <br class="">
      <div class="gmail_quote">
        <div dir="ltr" class="">On Tue, 23 Jun 2015 at 16:21 Gytis Trikleris &lt;<a moz-do-not-send="true" href="mailto:gytis@redhat.com" class="">gytis@redhat.com</a>&gt;
          wrote:<br class="">
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000" class=""> Hello,<br class="">
            <br class="">
            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" class="">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 class="">
            <br class="">
            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 class="">
            <br class="">
            Thanks,<br class="">
            Gytis<br class="">
          </div>
          _______________________________________________<br class="">
          wildfly-dev mailing list<br class="">
          <a moz-do-not-send="true" href="mailto:wildfly-dev@lists.jboss.org" target="_blank" class="">wildfly-dev@lists.jboss.org</a><br class="">
          <a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote>
      </div>
    </blockquote>
    <br class="">
  </div>

_______________________________________________<br class="">wildfly-dev mailing list<br class=""><a href="mailto:wildfly-dev@lists.jboss.org" class="">wildfly-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/wildfly-dev</div></blockquote></div><br class=""></div></div></body></html>