5:13 a.m.
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
6:11 a.m.
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(a)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(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Michael Musgrove
mmusgrov(a)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)
2:02 p.m.
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(a)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(a)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(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Michael Musgrove
mmusgrov(a)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(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
If I am writing outside of normal office hours, it is my choice; you do not
need to do the same
1303
days inactive
1304
days old
2 comments
3 participants
participants (3)
-
Brian Stansberry -
Kabir Khan -
Michael Musgrove