Petr,
It looks like a mistake in the test case where it is accidentally testing the ‘unchanged’ setting as though it were ‘cleared’. The `unchanged` setting leaves the context type alone, so whatever the context was on the thread before it must
remain. The mistake went unnoticed on Open Liberty because the state of the thread happens to already match the test assertion. This one should definitely be challenged for the mistaken assertion.
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Petr Aubrecht <aubrecht@xxxxxxxxxxxx>
Reply-To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Date: Wednesday, May 4, 2022 at 1:35 PM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] [cu-dev] unchanged JNDI in CompletableFuture.thenAcceptAsync() created from ManageExecutorService
Hello, I'm looking at test ManagedExecutorDefinitionTests/ManagedExecutorDefinitionServlet.testCompletedFuture, using "java:module/concurrent/ExecutorB" ManagedExecutorService,
which is configured to use this context:
This Message Is From an External Sender
|
This message came from outside your organization.
|
|
|
Hello,
I'm looking at test ManagedExecutorDefinitionTests/ManagedExecutorDefinitionServlet.testCompletedFuture, using "java:module/concurrent/ExecutorB" ManagedExecutorService, which is configured to use this context:
@ContextServiceDefinition(name = "java:module/concurrent/ContextB",
cleared = TRANSACTION,
unchanged = { APPLICATION, IntContext.NAME },
propagated = ALL_REMAINING)
E.g. the implementation must keep APPLICATION (JNDI search) unchanged during the thenAcceptAsync() call.
This test expects, that the thread's context doesn't recognize
java:module JNDI lookup. As I understand, Open Liberty starts threads with "empty contexts", so JNDI calls fail and TCK test succeeds.
This is not the case of Payara/Glassfish, which shares the context of launching thread, so the JNDI call succeed. I fear, that changing the behavior of thread in MES may break compatibility with existing application.
I would like to ask, if there is described the requirement of failing JNDI search for
java:module if using ContextServiceDefinition.unchanged(APPLICATION). I haven't found any. APPLICATION javadoc only describes behavior for cleared.
Thank you,
Petr