Marking beans as unremovable in AdditionalBeanBuildItem

[azzazzel]

Hi there,

I'm building an extension that discovers some classes and adds a scope to them. My BuildStep looks like this:

    @BuildStep
    AutoAddScopeBuildItem addScopeBuildItem() {
        return AutoAddScopeBuildItem.builder()
                .anyMethodMatches(method -> {
                    // logic here
                })
                .unremovable()
                .defaultScope(BuiltinScope.APPLICATION)
                .build();
    }

The processed classes and not injected anywhere, so from Quarkus perspective, they are "unused beans" and should be removed.
Thus the unremovable(). But it seems it doesn't work, I can't get the beans from the container after the application starts. It seems the classes have been removed after this step.

If I annotate those classes with @Unremovable (or add them to quarkus.arc.unremovable-types list), everything works as expected. However, this way each application needs to configure the unremovable classes. I'd like the extension to take care of that instead.

Is this a bug, or am I doing something wrong, or am I making wrong assumptions about what unremovable() should do?

[gsmet]

@azzazzel unremovable() is exactly what you think it is so if it doesn't work, there's something odd.

Are you sure your condition matches? If you're sure everything's right, then we would probably need a reproducer.

[azzazzel]

Am I sure? Of course, I'm not. I'm too new to Quarkus to be sure about anything!

But here is my thinking.

• without the Build Step, the classes cannot be found in the container. This is normal as they don't have bean-defining annotations.
• even if I add them to quarkus.arc.unremovable-types, they are still not there without the Build Step. So it's not that the config magically adds them
• when I have the Build Step and add them to the quarkus.arc.unremovable-types - everything works as expected. So I assume it's the Build Step that adds them.
• when I remove them from quarkus.arc.unremovable-types they are not in the container. So either something removes them, or the build step does not add them without the property.

To me, the above leads to the conclusion that the condition matches, the Build Step adds the beans but something removes them later on despite .unremovable(). But I can't be sure.

I'd love to provide a reproducer, but I'm unsure how. Testing extensions is still on my TODO list, I'm afraid.

[gsmet]

You can just provide a zip with the code of the extension and a project using it that shows the issue. That will be enough for us to reproduce the issue.

[azzazzel]

Hey @gsmet

I created a minimal reproducer here: https://github.com/azzazzel/quarkus-unremovable-issue

As I changed how I get the bean and enabled debug, it now clearly indicates the bean is removed. When I run

mvn clean package && java -jar sample/target/quarkus-app/quarkus-run.jar`

I get:

...
2022-08-09 01:25:26,050 INFO  [io.quarkus] (main) Installed features: [cdi]
2022-08-09 01:25:26,055 WARN  [io.qua.arc.impl] (main)
================================================================================
CDI: programmatic lookup problem detected
-----------------------------------------
At least one bean matched the required type and qualifiers but was marked as unused and removed during build

Stack frame: issues.quarkus.unremovable.sample.HelloApplication.run(HelloApplication.java:20)
Required type: class issues.quarkus.unremovable.sample.NotBean
Required qualifiers: []
Removed beans:
	- CLASS bean  [types=[class issues.quarkus.unremovable.sample.NotBean], qualifiers=null]
Solutions:
	- Application developers can eliminate false positives via the @Unremovable annotation
	- Extensions can eliminate false positives via build items, e.g. using the UnremovableBeanBuildItem
	- See also https://quarkus.io/guides/cdi-reference#remove_unused_beans
	- Enable the DEBUG log level to see the full stack trace
================================================================================

2022-08-09 01:25:26,057 DEBUG [io.qua.arc.impl] (main)
CDI: programmatic lookup stack trace:
io.quarkus.arc.impl.ArcContainerImpl.getMatchingBeans(ArcContainerImpl.java:684)
	io.quarkus.arc.impl.ArcContainerImpl.getBeans(ArcContainerImpl.java:501)
	io.quarkus.arc.impl.BeanManagerImpl.getBeans(BeanManagerImpl.java:95)
	issues.quarkus.unremovable.sample.HelloApplication.run(HelloApplication.java:20)
	issues.quarkus.unremovable.sample.HelloApplication_ClientProxy.run(Unknown Source)
	io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:129)
	io.quarkus.runtime.Quarkus.run(Quarkus.java:67)
	io.quarkus.runtime.Quarkus.run(Quarkus.java:41)
	io.quarkus.runner.GeneratedMain.main(Unknown Source)
	io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:60)
	io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:31)
2022-08-09 01:25:26,057 DEBUG [io.qua.run.Application] (main) Stopping application
...

If I uncomment the

#quarkus.arc.unremovable-types=\
#  issues.quarkus.unremovable.sample.NotBean

in application.properties, then it all works as expected:

...
2022-08-09 01:24:56,130 INFO  [io.quarkus] (main) Installed features: [cdi]
CLASS bean [class=issues.quarkus.unremovable.sample.NotBean, id=2f0ad6d2a8b9b90933bbfa15b69265c3e7b409ed]
2022-08-09 01:24:56,134 DEBUG [io.qua.run.Application] (main) Stopping application
...

[gsmet]

@mkouba could you have a look at this one now that we have a reproducer?

[mkouba]

It's definitely a bug. I will create a new issue right away.

[mkouba]

I've sent a PR that should fix the problem. An additional UnremovableBeanBuildItem should be used as a workaround for the moment.