-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discovery of annotated type parameter doesn't work #3671
Comments
@ericbottard example didn't reproduce the NPE for me. I noted a difference in the output though. Instead of:
When I run the sample it instead prints:
Probably due to me using a different Graal JVM version:
Modifying the example slightly I was still able to reproduce the bug however. It just requires that we try to explicitly pry the information in the I added this to the sample code:
And it produces an NPE when calling
|
I was able to get the example working by adding some stuff to
The rest of the json files were left unchanged (i.e. as generated by the java tracing agent). Just adding the Not sure what it means for this bug report. Is it expected to behave this way? (I'm inclined to say, even though I got it working, it should still be considered as a failing/bug of the tracing agent, since it is producing incomplete info in |
@ericbottard does the solution provided by @kdvolder solved your issue? |
Sadly it did not (it does solve the issue with the simple testcase I came up with above, but does not solve the real-life usecase we're encountering). Let me try to complexify the testcase a bit (involving Hibernate Validator) |
Sooo... The following more involved testcase public class Exhibit {
private List<@NotBlank String> strings = List.of("hello", "");
public static void main(String[] args) throws Exception {
Exhibit e = new Exhibit();
ValidatorFactory factory = Validation.byDefaultProvider().configure()
.messageInterpolator(new ParameterMessageInterpolator()).buildValidatorFactory();
Validator validator = factory.getValidator();
final Set<ConstraintViolation<Exhibit>> violations = validator.validate(e);
System.out.println(violations);
}
} works* with native compilation, using what is captured by the agent (nothing extraordinary jumps at me there) BUT prints the following message:
Re-compiling with Adding what he suggested (about
So, to recap:
|
@ericbottard Please add --report-unsupported-elements-at-runtime and try again |
Did that already, which results in the NPE at runtime with no extra info. This is why I focused on reporting about |
@ericbottard please check out this issue, where this error has been fixed |
@mcraj017 For context, Eric and I are working together on this (trying to get past that error in our project). I've taken a look at #2736 but I'm not sure how it helps. Did I understand correctly that its telling us that if we add Eric's more elaborate example isn't solved by the extra json config. Perhaps there's other extra reflection config that could be added to make it work but we are unsure how to figure out what extra things we could try to add.
Sure, will do. I'm repackaging Eric's more complex example at the moment to make it publically available somewhere. I'll provide a link shortly. |
Sample project: To reproduce see the
... to point to where you have graalvm installed. For reference here's the full output I get running that script:
|
@kdvolder As I see it is a spring boot app |
@mcraj017 It is not a spring boot app. That's probably not obvious because of the boot parent pom still being present. However, it just uses the spring boot parent pom as a convenience to allow building an executable jar and run it easier from commandline. However, there are no spring boot features being used in the code at all (i.e. zero boot annotations, and it is launching as plain Java app. Any spring and boot features in this sample have been deliberately disabled in an attempt to remove them as |
@mcraj017 To avoid confusion around how / if spring and spring boot are involved in this bug I've stripped down the sample a bit further and removed all spring boot references from the pom. It is now plain java project with but one dependency hibernate (+ transitive dependencies it needs). We are also no longer using spring boot fatjar to launch. The 'build-and-run-native' script has been updated accordingly. It now downloads maven dependencies into With all that in place the non-native run produces the following expected output:
Running the native image results in this:
Maven native image plugin is used with the following config:
This is the reworked sample in full: graal-bug-3671.zip |
@kdvolder thanks for the clarification, I will check the reproducer and get back to you |
@kdvolder I have raised the bug with Dev team |
Hello, |
Any update ? |
I'm also experiencing the same issue. Any update on this? Thanks! |
Please tag this issue with the |
Ping? |
Closing as this issue has been fixed since 22.1 |
Describe the issue
Code that tries to access annotations on type parameters currently fails at runtime with an NPE:
The above is from the sample program below, which works fine when run as a regular java program.
Moreover, this still fails after trying to re-compile it natively with hints created by the agent (it doesn't capture much, only the following:)
reflect-config.json
Steps to reproduce the issue
This small program reproduces the issue:
Describe GraalVM and your environment:
GraalVM 21.2.0 on Mac OS:
More details
This issue is not as "corner case" as it may seem, as this is a typical usage pattern when using bean validation (jsr 380).
The text was updated successfully, but these errors were encountered: