Quarkus logging

[barreiro]

Fixes Issue

Fixes #1993

Changes proposed

• Move from org.jboss.logging.Logger to io.quarkus.logging.Log
• Use debugf, infof and other "format" methods
• String concatenation + when creating Exception mesages
• Standardize on "".formatted() instead of String.format()

Check List (Check all the applicable boxes)

• My code follows the code style of this project.
• My change requires changes to the documentation.
• I have updated the documentation accordingly.
• All new and existing tests passed.

[lampajr]

Hi @barreiro, planning to look at this either today or tomorrow, meanwhile can you please apply the formatting as it looks like there are some uncommitted changes

[lampajr]

Overall lgtm!

I've just one doubt, the quarkus doc clearly says that:

Only use the Log API in application classes, not in external dependencies. Log method calls that are not processed by Quarkus at build time will throw an exception.

But I see we are using horreum-infra-common in the Jenkins plugin that is not using Quarkus IIUC 👉🏻 https://github.com/jenkinsci/horreum-plugin/blob/bb0d263b081da6967bba3ca6e98f4d3dc9c194cd/pom.xml#L248-L253, therefore I think there could be some problem there, wdyt?

[johnaohara]

Overall lgtm!

I've just one doubt, the quarkus doc clearly says that:

Only use the Log API in application classes, not in external dependencies. Log method calls that are not processed by Quarkus at build time will throw an exception.

But I see we are using horreum-infra-common in the Jenkins plugin that is not using Quarkus IIUC 👉🏻 https://github.com/jenkinsci/horreum-plugin/blob/bb0d263b081da6967bba3ca6e98f4d3dc9c194cd/pom.xml#L248-L253, therefore I think there could be some problem there, wdyt?

good catch.
Anything in 'horreum-api', 'horreum-client' or 'horreum-infra-common' can not use Quarkus loggging

[lampajr]

lgtm

[lampajr]

I was thinking whether we want to backport this or not, if we won't.. it means that most of the next PRs that need to be backported will likely have some conflicts.. therefore I see two options:

1. Merge it and backport it as well (it should not be a problem as we are just touching loggings)
2. Merge this one as close as possible to the next 0.17 release

wdyt @johnaohara @barreiro ?

[barreiro]

I'm fine either way. I guess it will depend on how long it will take until a 0.17 release and how much will we have to backport until then.

[lampajr]

I guess it will depend on how long it will take until a 0.17 release and how much will we have to backport until then.

yeah exactly!

I would like to get #2202 merged and backported and then I think we can merge this one as well (IMO I would also backport it even if we won't release it in the 0.16 stream)

[lampajr]

I would like to get this included in the next version, @barreiro can you give it a look and resolve the existing conflicts?

[barreiro]

@lampajr rebased