EndUserSpanProcessor integration

[amoscatelli]

Closes #34526

[quarkus-bot]

/cc @brunobat (opentelemetry), @radcortez (opentelemetry)

[brunobat]

Thanks for the PR @amoscatelli.
I think we should not add a SpanProcessor and include a ManagedExecutor just for this purpose.
I was expecting to instrument quarkus-jwt and get that information from there.
I wonder if @sberyozkin can help with that?
We also need tests.

[amoscatelli]

Thanks for the PR @amoscatelli. I think we should not add a SpanProcessor and include a ManagedExecutor just for this purpose. I was expecting to instrument quarkus-jwt and get that information from there. I wonder if @sberyozkin can help with that? We also need tests.

I think there is a misunderstanding.
Even if you inject JsonWebToken principal, you still would require a ManagedExecutor to access it.
That was my starting point, but since the beginning vertx complained about being blocked, so I had to introduce a ManagedExecutor. Probably that's because the spanprocessor, accessing the JsonWebToken, transitively access the request and so it requires RequestScope and this operation becomes blocking.

Then I switched to SecurityIdentity, hoping, among the other things, to workaroud the ManagedExecutor thing, but it is still required.
Anyway I think that using SecurityIdentity is still an upgrade, because it is agnostic of the kind of authentication/security extension you are going to use.
There is no reason to couple this with jwt ...

Of course as I said from the beginning I would like to avoid both the ManagedExecutor and the requestscope.
What do you suggest ?

[sberyozkin]

LGTM, indeed, should not be tied up with the specific type of credentials or authentication mechanism.
It only should not be enabled by default IMHO which what this PR enforces

[sberyozkin]

@amoscatelli Can you please fix the conflict ?

[brunobat]

Thanks @sberyozkin.
@amoscatelli can you please add tests?

[amoscatelli]

LGTM, indeed, should not be tied up with the specific type of credentials or authentication mechanism. It only should not be enabled by default IMHO which what this PR enforces

Thank you.
Anyway this is not enabled by default.
Default value is false for the new configuration.

[amoscatelli]

Thanks @sberyozkin. @amoscatelli can you please add tests?

Done !

[amoscatelli]

@brunobat please tell me if there is something more I can do because this is requiring a rebase after rebase :-)

[brunobat]

This looks great!
Thanks @amoscatelli

[brunobat]

@amoscatelli please build the extension and the IT test before pushing. The local build will auto format the code.

[quarkus-bot]

✖ This workflow run has failed but no jobs reported an error. Something weird happened, please check the workflow run page carefully: it might be an issue with the workflow configuration itself.

[amoscatelli]

@brunobat I think this is done, can this be merged please ?

[brunobat]

Thanks @amoscatelli. Do you have Twitter? I'd like to post about this PR.

[amoscatelli]

No sorry but I have Linkedin !
You can post on Twitter and tag me there, is this possible ?

@brunobat
https://www.linkedin.com/in/alessandromoscatelli/

[brunobat]

sure