The intent of that test was to verify that
the defaults defined by the specification/API/JavaDoc are used
in the absence of explicit configuration.
Taking a look at ContextServiceDefinition,
these are the defaults:
String[] cleared() default {
TRANSACTION };
String[] unchanged() default {};
String[] propagated() default {
ALL_REMAINING };
* Does ALL_REMAINING mean also all
custom thread context providers?
Yes. ALL_REMAINING is literally everything
else, including all custom thread context providers, that are
not configured elsewhere. The inclusion of custom thread
context providers as part of “all” is assumed by the current
JavaDoc and not explicitly called out. I’d be happy add
something explicit about it to be as clear and precise as
possible – thanks for bringing this up!
* What should happen with the transaction, when used in
cleared? The javadoc says: context to clear whenever a
thread runs the contextual task or action. The thread's
previous context is restored afterward.
The JavaDoc for the TRANSACTION constant states the
following:
A thread with a cleared transaction context can begin a
new {@link jakarta.transaction.UserTransaction}.
This stated a bit indirectly in that in order to allow you to
begin a new transaction when there is an existing transaction
on the thread, the transaction would need to be suspended (and
resumed afterward to restore context). This has exactly the
same meaning as the execution property
ManagedTask.TRANSACTION=SUSPEND. I’ll look into updating the
JavaDoc to explicitly call this out as well. Thanks again for
identifying it.
** I tried to find this in the discussion in MicroProfile,
but it didn't help. Does it mean, that the transaction
should be suspended before executing the task in a different
thread?
Yes, it’s not surprising that MicroProfile would have the
same lack of clarity – a lot of this was copied over from
MicroProfile.
ZjQcmQRYFpfptBannerStart
|
This
Message Is From an External Sender
|
|
This
message came from outside your
organization.
|
|
|
ZjQcmQRYFpfptBannerEnd
Hello,
I'm looging at the test
ContextServiceDefinitionServlet.testContextServiceDefinitionDefaults.
It uses ContextC. The code looks like this:
@ContextServiceDefinition(name
= "java:comp/concurrent/ContextC")
...
ContextService
contextService =
InitialContext.doLookup("java:comp/concurrent/ContextC");
StringContext.set("testContextServiceDefinitionDefaults-1");
Callable<String> callable =
contextService.contextualCallable(() -> {
...
});
StringContext.set("testContextServiceDefinitionDefaults-2");
assertEquals(callable.call(),
"testContextServiceDefinitionDefaults-1",
"Third-party context type StringContext must be
propagated to contextual Callable.");
assertEquals(tx.getStatus(), Status.STATUS_ACTIVE,
"Transaction must be restored on thread after
contextual proxy completes.");
There must be something I miss, because StringContext is not
propagated. The definition with default values looks like
this:
@ContextServiceDefinition(name =
"java:comp/concurrent/ContextC", cleared=TRANSACTION,
propagated=ALL_REMAINING, unchanged={})
* Does ALL_REMAINING mean also all custom thread context
providers?
* What should happen with the transaction, when used in
cleared? The javadoc says: context to clear whenever a thread
runs the contextual task or action. The thread's previous
context is restored afterward.
** I tried to find this in the discussion in MicroProfile,
but it didn't help. Does it mean, that the transaction should
be suspended before executing the task in a different thread?
Updating the definition this way improves things:
@ContextServiceDefinition(name =
"java:comp/concurrent/ContextC", propagated = {ALL_REMAINING,
StringContext.NAME}, cleared = {})
Thank you,
Petr
