Fix managedthreadfactory component context

[aubi]

Obvious copy&paste error:
txTaskResult -> lookupTaskResult.completeExceptionally()

Ad java:comp usage: is there any particular reason to use it in this test? I has a specific behavior in web app (equal to module), but EJB-bound in EAR app. If we want to use it, it must be kept EJB-bound, e.g. lookup it in the managedThreadFactoryDefinitionBean. Personally, I would prefer to use java:app as it makes me better sense to define thread factory for whole app.

[njr-11]

Obvious copy&paste error:
txTaskResult -> lookupTaskResult.completeExceptionally()

Yes, definitely appears to be a copy/paste error.

Ad java:comp usage: is there any particular reason to use it in this test? I has a specific behavior in web app (equal to module), but EJB-bound in EAR app. If we want to use it, it must be kept EJB-bound, e.g. lookup it in the managedThreadFactoryDefinitionBean.

This test does seem awkward and complex and real applications wouldn't write their code this way. I can guess the reason for using java:comp here is to be another test of ManagedThreadFactory capturing context upon lookup. Because the ManagedThreadFactory lookup occurs within the ManagedThreadFactoryDefinitionBean EJB, threads created by the ManagedThreadFactory must run with that EJB's context and be capable of performing java:comp lookups as though they are running from the EJB, so InitialContext.doLookup("java:comp/concurrent/EJBThreadFactoryB") within the task is actually valid and should not need to change.

Normally in this situation I'd ask to keep only the first change that fixes the copy/paste error and not the second (or if we had more time, replace the second with a better test). However, needing to make any change at all at this point puts us at risk of not making the deadline for spec approval for EE 10, and we certainly don't have the time for a back and forth discussion about whether to make the second change and getting the pull updated. So, because the second change is at least still valid, I'll approve and merge it so that we can the new TCK built and certified on and hopefully still be able to publish the results before the deadline passes to make EE 10.

[aubi]

@njr-11 You are right with splitting the changes, sorry.

ad context: The thread is executed from ManagedThreadFactoryDefinitionOnEJBServlet, e.g. the component doesn't match ManagedThreadFactoryDefinitionBean. Also, it is in EAR.