Replace Boilerplate Logging with Quarkus Log Class

[SergioRuyDev]

This is my first contribution to the project. I replace the boilerplate logging with Quarkus Log class, which helped me explore and better understand the project. I'm able to do it in the all project. I work with Quarkus and really like this extension. I was inspired by a Quarkus Club live session with Matheus Cruz and Helber Belmiro and want to support the project. Once I get more familiar with the codebase, I'll start tackling issues.

Here's the Quarkus Logging documentation I referenced. If anything needs adjustment, please let me know! 😊

Please make sure that your PR meets the following requirements:

• [ x ] You have read the contributors guide
• [ x ] Your code is properly formatted according to our code style
• [ x ] Pull Request title contains the target branch if not targeting main: [0.9.x] Subject
• Pull Request contains link to the issue
• [ x ] Pull Request contains link to any dependent or related Pull Request
• [ x ] Pull Request contains description of the issue
• [ x ] Pull Request does not include fixes for issues other than the main ticket

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-quarkus2 to backport the original PR to the quarkus2 branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.

If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

[mcruzdev]

Nice catch! It looks great. However, we have other runtime classes that aren't using this approach. I tested the io.quarkus.logging.Log on deployment module, and it works well.

However, I have a doubt about this statement:

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.

@SergioRuyDev I created this topic on Zulip asking the use of this approach on extension side.

[fjtirado]

Nice catch! It looks great. However, we have other runtime classes that aren't using this approach. I tested the io.quarkus.logging.Log on deployment module, and it works well.

However, I have a doubt about this statement:

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.

@SergioRuyDev I created this topic on Zulip asking the use of this approach on extension side.

I do not think the savings of code (just one static log field) compensates the "risk" of this not getting processed by quarkus during build time (I guess that, in order to be usable, Quarkus process both deployment and runtime classes and this works).
Anyway if we are doing this, in order to be consistent, we should do that for all logger instances, not just this class

[fjtirado]

Im not sure we should do that, but if we do, we should change all logger instances in the extension, not just this class

[SergioRuyDev]

Thanks for the review.
Yes, I can handle it. I kept it in one class initially to ensure it aligned with expectations, but I’m happy to refactor if needed.

[hbelmiro]

Thank you and congratulations on your first contribution @SergioRuyDev.

I agree with @fjtirado on all points.
Regarding the risk of changing it, it seems easy to validate if it works in build time.

I'm more concerned about the amount of lines changed. It will be a big (in the sense of the number of lines) change.
Big changes may cause conflicts, be hard to revert, and this kind of stuff. I'm kinda reluctant to do these changes nowadays. For example, we recently had a big PR that has been causing a lot of bugs.
I'm not saying that we should not do big changes. But we should reflect on the benefits we get from them.

@SergioRuyDev do you know if we would have any other benefits besides reducing boilerplate?

It would be nice to have the opinion of @ricardozanini and @mcruzdev.

Sorry if I'm overthinking (I feel like I am). I'm not against doing this change. I just wanted to express my concerns. I'll be happy to accept if you guys think we should do it.

[ricardozanini]

Our log platform is Log4j; please don't change it. What we can do in this PR is to actually revert this Jboss Logging to slf4j, which is already used by many projects and users.