Warn about interceptors on private methods

[geoand]

Resolves: #21046

P.S. Another solution would be to remove the private modifier from the method same as we do for final, but I am not sure if we want that.

[mkouba]

P.S. Another solution would be to remove the private modifier from the method same as we do for final, but I am not sure if we want that.

-1

[famod]

Thanks a lot for this! It's too easy to run into this problem, e.g. when refactoring existing code.

[geoand]

Indeed it is :)

[quarkus-bot]

Failing Jobs - Building d8d8305

Status	Name	Step	Failures	Logs	Raw logs
✖	Native Tests - Windows - hibernate-validator	Build	Failures	Logs	Raw logs

Failures

⚙️ Native Tests - Windows - hibernate-validator #

- Failing: integration-tests/hibernate-validator 

📦 integration-tests/hibernate-validator

✖ Failed to execute goal io.quarkus:quarkus-maven-plugin:999-SNAPSHOT:build (default) on project quarkus-integration-test-hibernate-validator: Failed to build quarkus application

[famod]

@geoand I colleague just lost quite a bit of time because he had @Tranasctional(REQUIRES_NEW) on a private method and he didn't see the warning (I did spot it quickly when he asked for help but I guess not everyone is so "sensitive" to warnings).

So I'm wondering if we should provide a config property to control whether to just warn or throw an exception?

[geoand]

Sure, that sounds like a good idea

[geoand]

Do you or your colleague want to open a PR for that? I can certainly do it.

[famod]

You are very welcome to do that! We are a bit in a rush for a release next week.

[geoand]

Hm... Actually the idea of this sort of conflicts with the quarkus.arc.transform-unproxyable-classes.
We don't try to transform the private method case (and we do mention this in the docs of the property), but I am not sure it will be intuitive to users if we have something like quarkus.arc.transform-unproxyable-classes=true and quarkus.arc.fail-on-private-interceptors=true...

@mkouba WDYT?

[mkouba]

Well, private intercepted observer/producer methods are legal and should work just fine so we would have to ignore these.

but I am not sure it will be intuitive to users if we have something like quarkus.arc.transform-unproxyable-classes=true and quarkus.arc.fail-on-private-interceptors=true...

Private methods don't turn a class into an unproxyable type so it should be ok I think...

[geoand]

Understood, thanks

[geoand]

#22185 takes care of it