Quarkus: Annotations with default private Class fields can cause runtime exception

Created on 13 May 2020  路  5Comments  路  Source: quarkusio/quarkus

Describe the bug
I'm trying to use both ConfigProperty and picocli.CommandLine.Option annotations on same field, to implement extension which will allow to parse configuration from command line parameters. Unfortunately annotation classes which have Class fields with default pointing to private Class will not work with injected fields.

For example, following class:

````java
import org.eclipse.microprofile.config.inject.ConfigProperty;
import picocli.CommandLine;

import javax.enterprise.context.Dependent;

@Dependent
public class Configuration {
@CommandLine.Option(names = {"-m", "--message"})
@ConfigProperty(name = "message", defaultValue = "testValue")
String message;
}
````

Will cause exception at runtime:

````
Caused by: java.lang.IllegalAccessError: failed to access class picocli.CommandLine$NoCompletionCandidates from class org.mgorniew.quarkus.picocli.Configuration_Bean (picocli.CommandLine$NoCompletionCandidates is in unnamed module of loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @197d671; org.mgorniew.quarkus.picocli.Configuration_Bean is in unnamed module of loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @7bd69e82)

at org.mgorniew.quarkus.picocli.Configuration_Bean.<init>(Configuration_Bean.zig:209)
at io.quarkus.arc.setup.Default_ComponentsProvider.addBeans1(Default_ComponentsProvider.zig:153)

````
I have fix prepared which will initialize such defaults using static fields from Shared Annotation Literal. This will not work however with non-shared literals: https://github.com/mgorniew/quarkus/commit/313736733c198de2557b650dfc493d2171d04f8d

Alternative solution would be just not initialize defaults which point to private classes.

Expected behavior
Annotation with private classes references doesn't cause runtime error.

arearc kinbug

Most helpful comment

OK, just wanted to clarify.

@mkouba sounds like something we should fix, right?

All 5 comments

Hm... This seems like a weird pattern... What would happen if both values were set?

Hm... This seems like a weird pattern... What would happen if both values were set?

You mean using both, @CommandLine.Option and @ConfigProperty on one field? This is just one of proposition to consider. This is to allow setting configuration with usage of picocli options. Idea is that we would generate ConfigSource for all @ConfigProperty fields which have also @CommandLine.Option. Such ConfigSource would pick values from command line arguments.

But this is separate topic. In any case I don't think that Quarkus should fail at runtime when annotations with default private Class is used.

Hm... This seems like a weird pattern... What would happen if both values were set?

You mean using both, @CommandLine.Option and @ConfigProperty on one field? This is just one of proposition to consider. This is to allow setting configuration with usage of picocli options. Idea is that we would generate ConfigSource for all @ConfigProperty fields which have also @CommandLine.Option. Such ConfigSource would pick values from command line arguments.

Seems reasonable

But this is separate topic. In any case I don't think that Quarkus should fail at runtime when annotations with default private Class is used.

Which default private class are you referring to?

Which default private class are you referring to?

@CommandLine.Option annotation has default values which points to private inner classes from CommandLine, e.g.:

Class<? extends IDefaultValueProvider> defaultValueProvider() default NoDefaultProvider.class;

This causes exception mentioned in issue description.

OK, just wanted to clarify.

@mkouba sounds like something we should fix, right?

Was this page helpful?
0 / 5 - 0 ratings