What you propose sounds ok, Kabir; the rest of this is just food for thought.

Is this a layers thing or a modules thing?

IOW layers don't exist at runtime, they are just a convenience for building. What matters at runtime is whether a module is provisioned.

And there are things that can be done with Galleon and modules that result in modules getting installed if their deps are present and not installed if they are not.

So it might not be necessary to have a bunch of layers (for sure that sounds wrong) but it might not also be necessary to package classes representing all the providers in one module and then fail because some dependency like RESTEasy isn't present. You could package the provider class in a module and it only gets installed if all its deps (e.g. RESTEasy) are present.

That kind of thing might be more effort than it's worth (e.g. if we're talking about a single class per provider it's kind of overkill.)

One thing we should think carefully about is using the word 'layer' in runtime messages. That's kind of a slippery slope as layers really are a convenience for provisioning and are not a runtime concept. So talking about them at runtime starts to blur those lines.

On Tue, Apr 27, 2021 at 6:12 AM Michael Musgrove <mmusgrov@redhat.com> wrote:

I think your proposal is the most extensible one (in the sense that it will still work unchanged if microprofile-context-propagation adds more providers). In particular, it seems reasonable for the JTA context provider.

On Tue, Apr 27, 2021 at 11:14 AM Kabir Khan <kkhan@redhat.com> wrote:
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

--
Michael Musgrove
mmusgrov@redhat.com

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

_______________________________________________
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