quarkus: Static producer methods and fields causes containing class being recognized as beans

Describe the bug

When defining a static producer method or field, quarkus is interpreting the (method or field) containing class as bean, causing problems

  • when the containing class itself is defined as bean via a producer
  • when the containing class itself declares “dependencies” (via constructor), that have never been meant to be fulfillfed.

In this example, not only a bean of type Role (as producer field) is registered, but also a bean of type User (as class).

record Role(String value) {
}

@Entity
class User {

	@Produces
	public static final Role ADMINISTRATOR = new Role("admin");
}

Expected behavior

static producer method or field should not cause the containing class being registered as bean, if no other non-static member is annotated with CDI annotations.

Actual behavior

static producer method or field should cause the containing class being registered as bean, though no other bean-defining annotation is used.

How to Reproduce?

See example above

Output of uname -a or ver

Darwin sl-macbook.fritz.box 19.6.0 Darwin Kernel Version 19.6.0: Tue Feb 15 21:39:11 PST 2022; root:xnu-6153.141.59~1/RELEASE_X86_64 x86_64

Output of java -version

openjdk version “18” 2022-03-22 OpenJDK Runtime Environment Homebrew (build 18+0) OpenJDK 64-Bit Server VM Homebrew (build 18+0, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.8.1.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.5

Additional information

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 26 (18 by maintainers)

Most upvoted comments

I believe that this issue should be closed. @slinstaedt @geoand @manovotn WDYT?

So should we close this?

It’s definitely not a bug. On the other hand, we could extend the functionality of quarkus.arc.detect-wrong-annotations and detect this use case and fail the build…

I agree

During deployment time? Try this code in a vanilla quarkus project, just using only the basic quarkus-resteasy extension. Unfortunately this works pretty well, not even throwing an IllegalStateException.

Hm in this case, the MultipleConstructor is simply ignored (it’s not registered as a CDI bean) because it does not have an appropriate constructor. And that’s the reason why resteasy reactive throws an IllegalArgumentException and the message reads “To fix the problem, make sure this class is a CDI bean.”.