Removed Panache marker and annotation processor in favour of Jandex use-site indexing

[FroMage]

We now use Jandex use-site indexing to find classes to process, it should be faster than Panache markers set by the annotation processor because we only find classes using the entities, and not instrument the entire jars.

Let's see how much CI I break with this change 😱

[FroMage]

Well, it was worth a try :(

I'm not sure what went wrong though, it should work, minus the removal of producing AdditionalApplicationArchiveMarkerBuildItem, but I'm very unsure what this is supposed to do in the first place, and why archives with Panache entities had to be marked as application archives.

@aloubyansky I see your name in the commits of ApplicationArchiveBuildStep, do you happen to know why jars containing Panache entities had to be marked as application archives, as opposed to other classes?

[FroMage]

In particular, this change appears to not break the ORM/Panache tests, but does break the HR/Panache tests, where they fail to get a transaction. I really don't think this is due to improper entity instrumentation. It could be the application-archive marker change, perhaps.

[FroMage]

[INFO] Running io.quarkus.it.panache.reactive.PanacheFunctionalityTest
2024-01-17 17:13:19,614 ERROR [io.qua.ver.htt.run.QuarkusErrorHandler] (vert.x-eventloop-thread-2) HTTP Request to /test/8254 failed, error id: ffa6969b-d715-4c03-986f-71aeb68f39df-1: java.lang.IllegalStateException: No current Mutiny.Session found
	- no reactive session was found in the Vert.x context and the context was not marked to open a new session lazily
	- a session is opened automatically for JAX-RS resource methods annotated with an HTTP method (@GET, @POST, etc.); inherited annotations are not taken into account
	- you may need to annotate the business method with @WithSession or @WithTransaction
	at io.quarkus.hibernate.reactive.panache.common.runtime.SessionOperations.getSession(SessionOperations.java:159)
	at io.quarkus.hibernate.reactive.panache.common.runtime.AbstractJpaOperations.getSession(AbstractJpaOperations.java:364)
	at io.quarkus.hibernate.reactive.panache.common.runtime.AbstractJpaOperations.persist(AbstractJpaOperations.java:37)
	at io.quarkus.hibernate.reactive.panache.PanacheEntityBase.persist(PanacheEntityBase.java:57)
	at io.quarkus.it.panache.reactive.TestEndpoint.testBug8254(TestEndpoint.java:1849)
	at io.quarkus.it.panache.reactive.TestEndpoint$quarkusrestinvoker$testBug8254_02f9d9aa14635b140b88059ca50c75cfd4fd7872.invoke(Unknown Source)
	at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29)

This stack trace appears to indicate that WithTransactionInterceptor is not being applied. Even though the method is explicitly annotated with @WithTransaction.

[FroMage]

@mkouba do you know how I could check why the interceptor is not being applied?

[FroMage]

Actually, it's weird, because it turns out that WithTransactionInterceptor was not being registered in the processor, unlike the other interceptors. Adding it makes the HR/Panache tests pass:

    @BuildStep
    void registerInterceptors(BuildProducer<AdditionalBeanBuildItem> additionalBeans) {
        AdditionalBeanBuildItem.Builder builder = AdditionalBeanBuildItem.builder();
        builder.addBeanClass(WithSessionOnDemandInterceptor.class);
        builder.addBeanClass(WithSessionInterceptor.class);
        builder.addBeanClass(ReactiveTransactionalInterceptor.class);
// this was missing
        builder.addBeanClass(WithTransactionInterceptor.class);
        additionalBeans.produce(builder.build());
    }

But now, the mystery is: how could it possibly have worked before I added this?

[aloubyansky]

@aloubyansky I see your name in the commits of ApplicationArchiveBuildStep, do you happen to know why jars containing Panache entities had to be marked as application archives, as opposed to other classes?

"Application archives" are indexed, while the rest of the classpath isn't.

[FroMage]

"Application archives" are indexed, while the rest of the classpath isn't.

OK, so, before, we used to mark jars having Panache in their classpath as requiring indexing, so we could find the users of Panache, to instrument them.

Now, I want to use Jandex to find users of the entities, but for that I need to find the entities, which means I need jars containing entities to be indexed. If they're not indexed, this won't work.

And yet, Hibernate ORM also finds entities using the index, and they manage to do it without having any marker. Well, not true, they say you need a beans.xml marker file, which is fine and common: https://quarkus.io/guides/hibernate-orm#defining-entities-in-external-projects-or-jars

So, we could have the same requirement, instead of requiring an APT processor, and it should Just Work™.

[FroMage]

CI failure looks totally unrelated, let's rebase and try again.

[mkouba]

Actually, it's weird, because it turns out that WithTransactionInterceptor was not being registered in the processor, unlike the other interceptors. Adding it makes the HR/Panache tests pass:

    @BuildStep
    void registerInterceptors(BuildProducer<AdditionalBeanBuildItem> additionalBeans) {
        AdditionalBeanBuildItem.Builder builder = AdditionalBeanBuildItem.builder();
        builder.addBeanClass(WithSessionOnDemandInterceptor.class);
        builder.addBeanClass(WithSessionInterceptor.class);
        builder.addBeanClass(ReactiveTransactionalInterceptor.class);
// this was missing
        builder.addBeanClass(WithTransactionInterceptor.class);
        additionalBeans.produce(builder.build());
    }

But now, the mystery is: how could it possibly have worked before I added this?

I think that it worked before because the quarkus-hibernate-reactive-panache-common artifact contained the panache-archive.marker and thus became part of the application index (as described in the annotation processor).

[FroMage]

I think that it worked before because the quarkus-hibernate-reactive-panache-common artifact contained the panache-archive.marker and thus became part of the application index (as described in the annotation processor).

😂😂😂😂😂😂😂

That's such an incredible side-effect, but indeed it makes sense, you cracked it! Wow!

[famod]

I think we need the flag file integration-tests/locales/app/disable-unbind-executions so that quarkus-integration-test-locales-app is always installed (and is therefore always available, whether or not affected by changes).
E.g. 91f0034#diff-4602d5ba96dac621404540b73956ec108eebeb605dc883499e514238c88c7454

[geoand]

#38282 is an implementation of the above suggestion

[geoand]

Try rebasing onto main please

[FroMage]

Thanks!

[FroMage]

2024-01-18T16:23:39.3679711Z Caused by: java.io.IOException: Cannot run program "/home/runner/work/quarkus/quarkus/integration-tests/grpc-tls/target/com.google.protobuf-protoc-linux-x86_64-exe": error=26, Text file busy

I'm going to assume this can't possibly be related to anything and restart this job.

[geoand]

Yeah, that should be a random failure

[FroMage]

Not convinced by those test failures either :(

[geoand]

Likely unrelated, but having a fresh run wouldn't hurt

[FroMage]

Yeah, I restarted the failed runs.

[quarkus-bot]

✔️ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[FroMage]

Looks like it runs. Let's merge it and I'll update the docs in a new PR, to save on a rebuild.

[FroMage]

Docs at #38327
I'll also add migration notes.

[FroMage]

Migration guide: https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.9#ormhrmongo-panache-annotation-processor-removed