Hi,
I am currently working on porting context propagation from the WildFly
Reactive Feature Pack to WildFly itself, and have a question about how to
proceed.
In the feature pack I have the following setup
* A microprofile-context-propagation layer, which contains the core
subsystem and propagation providers for:
- CDI
- Application (Just TCCL)
* A microprofile-context-propagation-jta layer which provides propagation
for transactions
During the porting process I am finally revisiting some long outstanding
things:
* Extending Application to also propagate the NamespaceContextSelector
(Jakarta EE naming)
* JAX-RS context propagation
* Servlet context propagation
Now, a lot of providers are starting to rely on more stuff in layers which
might not be provisioned. One thing I could do is have a layer for each of
these, so e.g:
- microprofile-context-propagation-jaxrs would provide propagation of the
RestEasy context and make sure the JAX-RS layers are available
- microprofile-context-propagation-servlet would provide propagation of the
Servlet context and make sure the undertow layers are available
and so on.
While ^^ is the cleanest solution, I think it is way too fine-grained, and
the list of what people need to provision might become quite long.
I am currently working on something where you just have the
microprofile-context-propagation layer, which contains all the providers,
and does a check when the deployment is first initialised. If when loading,
say, the RestEasy provider, and RestEasy is not there, it will log an INFO
message along the lines of:
Class
org.wildfly.extension.microprofile.context.propagation.providers.jaxrs.JaxRsThreadContextSnapshotFactory
could not be loaded, because the underlying layers are not provisioned. You
will not get context propagation for the 'JAX-RS' thread context type
This message is printed when the deployment's context manager is first
loaded (i.e. on deploy) and not on every attempt to do propagation.
Does anybody see any problems with this approach? To me it is more
user-friendly, but others might have different opinions.
Thanks,
Kabir