Custom annotation dropped on classes implementing ItemReader. Writer, Processor, etc.
alejandrorabinovitz opened this issue · comments
Created sample application to show the problem:
- Uses JBeret 0.0.5 extension
- Created a custom annotation (HostName)
- Created interface TestInterface that extends ItemProcessor
- Created class HostNameMMS that implements TestInterface and has HostName custom annotation plus Dependent and Named annotations
- Created class ApplicationScopedTest which is annotatied with @ApplicationScoped and observes StartupEvent. Also injects any TestInterface
On the init method of ApplicationScopedTest I am printing out the annotations for the injected class
Only Dependant is printed, the HostName annotation is gone
If I remove extends ItemProcessor and run the app again, all 3 annotation are being printed.
Result:
With extends ItemProcessor
@javax.enterprise.context.Dependent()
2021-06-12 06:12:19,856 ERROR [org.acm.ApplicationScoredTest_Subclass] (Quarkus Main Thread) Annotation NOT found
Removing extends ItemProcessor
@javax.enterprise.context.Dependent()
@javax.inject.Named(value="")
@org.acme.HostName(name="MMS")
2021-06-12 06:13:37,107 INFO [org.acm.ApplicationScoredTest_Subclass] (Quarkus Main Thread) Annotation HostName found
This works ok up to Quarkus 1.12.2. The zip with the code points to 1.12.2, If you change to 1.13.0 (gradle.properties) and above you will see the problem
custom-annotation.zip
Hi @alejandrorabinovitz. Thanks for the reproducer. I'll have a look.
I couldn't reproduce the issue with the current code. I've tried every Quarkus versions from 1.13.x and also 2.x. Maybe your ItemProcessor was marked as an @ApplicationScoped bean? Or some other qualifier that created a proxy and looses the annotations? With @Dependant this won't happen because you get an instance of the concrete class and not a proxy.
Can you have another look and provide me more context / information? Thanks!
Hi @radcortez,
With the reproducer I attached you should see the issue on 13.x.
If you use 12.2.0 this is the output
@javax.enterprise.context.Dependent()
@javax.inject.Named(value="")
@org.acme.HostName(name="MMS")
If you use 13.x this is the output
@javax.enterprise.context.Dependent()
Just retested the code I attached and got the above results.
The only class that has ApplicationScoped annotation is ApplicationScoredTest
The annotations on the HostNameMMS class are
@dependent
@nAmed
@hostname(name = "MMS")
Let me know if you still cannot reproduce
Hum, can't reproduce it. Here is my output:
> Task :test
Caching disabled for task ':test' because:
Build cache is disabled
Task ':test' is not up-to-date because:
One or more additional actions for task ':test' have changed.
Java version: 11
Quarkus version: 1.13.0.Final
Starting process 'Gradle Test Executor 6'. Working directory: /Users/radcortez/Downloads/custom-annotation/custom-annotation Command: /Users/radcortez/.sdkman/candidates/java/11.0.7.hs-adpt/bin/java -DOUTPUT_SOURCES_DIR=/Users/radcortez/Downloads/custom-annotation/custom-annotation/build/classes/java/main,/Users/radcortez/Downloads/custom-annotation/custom-annotation/build/classes/java/test -Dnative.image.path=/Users/radcortez/Downloads/custom-annotation/custom-annotation/build/custom-annotation-1.0.0-SNAPSHOT-runner -Dorg.gradle.native=false -Dquarkus-internal.serialized-app-model.path=/Users/radcortez/Downloads/custom-annotation/custom-annotation/build/tmp/test/quarkus-app-model.dat @/private/var/folders/qd/bwfdn669095__70_s6r0_k9c0000gn/T/gradle-worker-classpath11409906681834642506txt -Xmx512m -Dfile.encoding=UTF-8 -Duser.country=PT -Duser.language=en -Duser.variant -ea worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 6'
Successfully started process 'Gradle Test Executor 6'
GreetingResourceTest STANDARD_ERROR
Jun 21, 2021 5:16:56 PM org.jboss.threads.Version <clinit>
INFO: JBoss Threads version 3.2.0.Final
Jun 21, 2021 5:16:58 PM org.jboss.threads.Version <clinit>
INFO: JBoss Threads version 3.2.0.Final
Jun 21, 2021 5:16:58 PM org.jberet.schedule.JobScheduler getJobScheduler
INFO: JBERET072500: Created JobScheduler: io.quarkiverse.jberet.runtime.QuarkusJobScheduler@26a44dac, based on resource: null
GreetingResourceTest STANDARD_OUT
@javax.enterprise.context.Dependent()
@javax.inject.Named(value="")
@org.acme.HostName(name="MMS")
GreetingResourceTest STANDARD_ERROR
Jun 21, 2021 5:16:58 PM org.acme.ApplicationScoredTest init
INFO: Annotation HostName found
Jun 21, 2021 5:16:58 PM io.quarkus.bootstrap.runner.Timing printStartupTime
INFO: Quarkus 1.13.0.Final on JVM started in 2.964s. Listening on: http://localhost:8081
Jun 21, 2021 5:16:58 PM io.quarkus.bootstrap.runner.Timing printStartupTime
INFO: Profile test activated.
Jun 21, 2021 5:16:58 PM io.quarkus.bootstrap.runner.Timing printStartupTime
INFO: Installed features: [agroal, cdi, jberet, jberet-rest, jdbc-mssql, mutiny, narayana-jta, rest-client, rest-client-jsonb, resteasy, resteasy-jsonb, smallrye-context-propagation]
Gradle Test Executor 6 STANDARD_ERROR
Jun 21, 2021 5:17:00 PM io.quarkus.bootstrap.runner.Timing printStopTime
INFO: Quarkus stopped in 0.048s
Gradle Test Executor 6 finished executing tests.I've only changed the gradle script to output java version and quarkus version with the test log, so we can assert that is running the correct versions. I get the prints for all annotations.
Decided to run the code on another machine and it worked ok using 13.7...
Going to clean local repo on the machine where I saw the issue and test again.
Sorry for reporting a non-issue.
Just ran gradlew quarkusDev and there I see the problem on the 2 machines.
java -jar .... works fine on both machines.
So it seems the issue is related to quarkusDev
Hope you are able to reploduce
Ok, I can see reproduce now. Thanks!
Let me have a look.
A Quarkus enhancement to monitor CDI beans in Dev mode, turned that bean into a subclass:
quarkusio/quarkus#15040
You can disable this feature with quarkus.arc.dev-mode.monitoring-enabled=false. Alternately, you could also write the code to look for the annotation in the super class (and make it recursive). I would probably do that, because that would allow you to also subclass and still find the annotation.
Anyway, if you don't mind, I'm closing this issue, because there is nothing more I can do from the JBeret side.