Build fails for @Provider exception mapper

[blsouthr]

starting with 0.23.2 I get
[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:0.25.0:build (default) on project demo: Failed to build a runnable JAR: Failed to build a runner jar: Failed to augment application classes: Build failure: Build failed due to errors
[ERROR] [error]: Build step io.quarkus.arc.deployment.ArcProcessor#registerBeans threw an exception: javax.enterprise.inject.spi.DefinitionException: Bean class com.demo.excmapper.IllegalArgumentExceptionMapper declares multiple scope type annotations: javax.enterprise.context.Dependent, javax.inject.Singleton

Steps to reproduce the behavior:

1. Create sample hello project
2. Add the class

import org.eclipse.microprofile.metrics.Counter;
import org.eclipse.microprofile.metrics.annotation.Metric;

import javax.inject.Inject;

import javax.ws.rs.core.Response;
import javax.ws.rs.ext.ExceptionMapper;
import javax.ws.rs.ext.Provider;

@Provider
public class IllegalArgumentExceptionMapper implements ExceptionMapper<IllegalArgumentException> {
   
    @Inject
    @Metric(absolute = true, name = "error_count", description = "count", displayName = "error_count")
    private Counter counter;

    @Override
    public Response toResponse(IllegalArgumentException exception) {
        counter.inc();
        return Response.status(500).entity("illegal").build();
    }
}

3. run mvn package
   getting-started.zip

[gsmet]

@jmartisk @mkouba I wonder if this is related to us automatically adding conflicting scopes because we have Metrics there too.

[jmartisk]

Yeah, resteasy extension as well as metrics extension add scopes to beans, but in this case they both add different scopes because they don't know about each other. I this case the Metrics extension clearly should not add the @Dependent scope.
It may get quite hard to "guess" when Metrics should NOT add a scope. So far we have logic in place that this is skipped for JAX-RS endpoints, apparently we need to add JAX-RS providers to this exception as well.

[jmartisk]

For the future we might need to think of a more sophisticated algorithm to decide which extension should attach scopes in case multiple extensions want to add conflicting scopes... For now I sent a PR which tells Metrics extension to skip this for classes with a @Provider annotation, that seems to work for this use case

[mkouba]

So AnnotationsTransformer can be ordered and TransformationContext.getAnnotations() always returns the current set of annotations.You can easily test the presence of a built-in scope by means of io.quarkus.arc.processor.BuiltinScope.isIn(Iterable<AnnotationInstance>).

[jmartisk]

Yeah you can test whether another extension already added a scope before you, but we can't generally assume much about the ordering of the processors, right? In this case Metrics processor seems to run first, so it can't just check "hey, resteasy extension already added a different scope, so I'll skip this".

[jmartisk]

We could do this check instead of the BuiltinScope.isDeclaredOn(ctx.getTarget().asClass() that we have now, that will be a bit safer because it will account for scopes added by different extensions, but we still need to guess that another extension running later will want to add a different scope, and that one has higher priority

[mkouba]

we can't generally assume much about the ordering of the processors, right?

Well, each AnnotationsTransformer has a priority, BuildExtension.DEFAULT_PRIORITY by default. If you know that you would like to run your transformer after some other transformer just modify the priorities accordingly.

so it can't just check "hey, resteasy extension already added a different scope, so I'll skip this"

In general, any transformer that adds a scope annotation should check the current set of annotations and if there's a built-in scope it should not add any scope.

We could do this check instead....

I'm not sure I understand your point but again, a transformer should always check the current set of annotations. If needed and possible, a custom priority value should be used.

[jmartisk]

Oh, now I get it, so we'll make the Metrics AnnotationsTransformer run after the one for Resteasy, and also when checking whether there is a scope present already, instead of doing BuiltinScope.isDeclaredOn(ctx.getTarget().asClass()), we will do BuiltinScope.isIn(ctx.getAnnotations()) (so it will see scopes added by other transformers), does that sound good?

I guess we could then discard the checks (in the Metrics transformer) whether the bean is a JAX-RS endpoint/provider, but for being extra safe I would maybe keep them.. (?)

[gsmet]

Fixed by #4688 .