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

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s