Petr,
Yes, you should challenge that test. Its assertions on results[0] and results[1] are both invalid because treating those two UNCHANGED context types as though they were CLEARED.
From:
cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Petr Aubrecht <aubrecht@xxxxxxxxxxxx>
Date: Thursday, July 7, 2022 at 12:12 PM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] [cu-dev] TCK test ContextServiceDefinitionServlet.testContextualFunction randomly failing
Hi,
I have a question for the developers of Glassfish-based servers and Nathan.
It seems, that there is one more test to challenge --
ContextServiceDefinitionServlet.testContextualFunction.
This test expects, that a thread with unchanged APPLICATION will have
JNDI disconnected from the app, e.g. java:module lookup will fail.
I already created a challenge for a similar issue:
https://github.com/jakartaee/concurrency/issues/224
. The test would work
best with APPLICATION in cleared.
Glassfish implements invocations in InvocationManagerImpl and stores
them in InheritableThreadLocal<InvocationArray<ComponentInvocation>>
frames. This means, that any thread created from an http thread will
have a context.
The current problem is, that RANDOMLY, some ForkJoinPool thread are
created from the http threads. Then the context is available and the
test fails.
Should I create another challenge?
Petr
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
