inject:csrf is not retrieved in Qute template

[angelozerr]

In https://github.com/ia3andy/quarkus-blast/blob/aa969f34616ec63be0268fee20a40097d2ec1ba4/src/main/resources/templates/layout/page.html#L11 the crsfis marked as Undefined.

This inject is defined in https://github.com/quarkusio/quarkus/blob/4f843d57f97048fc5fc499dab2ba1fdd1549d48d/extensions/csrf-reactive/runtime/src/main/java/io/quarkus/csrf/reactive/runtime/CsrfTokenParameterProvider.java#L13

I think the problems comes from our isValidBean method It is because

quarkus-ls/qute.jdt/com.redhat.qute.jdt/src/main/java/com/redhat/qute/jdt/utils/CDIUtils.java

Line 77 in dd9791a

IType type = ((IType) javaElement);

which should respect the spec https://jakarta.ee/specifications/cdi/3.0/jakarta-cdi-spec-3.0#what_classes_are_beans
(the only thing that we don't support is the @Inject inconstructor parameter).

But when I read https://jakarta.ee/specifications/cdi/3.0/jakarta-cdi-spec-3.0#what_classes_are_beans the https://github.com/quarkusio/quarkus/blob/4f843d57f97048fc5fc499dab2ba1fdd1549d48d/extensions/csrf-reactive/runtime/src/main/java/io/quarkus/csrf/reactive/runtime/CsrfTokenParameterProvider.java#L13 have a construcor parameter (it should not be a proper bean). Perhaps it misses Inject for the construr parameter?

@ia3andy have you some idea?

[angelozerr]

@FroMage have you some idea too?

[FroMage]

Oh, that's a CDI question, ask @mkouba :)

[angelozerr]

Ok thanks @FroMage for your answer, I'm waiting for an answer from @mkouba

[mkouba]

But when I read https://jakarta.ee/specifications/cdi/3.0/jakarta-cdi-spec-3.0#what_classes_are_beans the https://github.com/quarkusio/quarkus/blob/4f843d57f97048fc5fc499dab2ba1fdd1549d48d/extensions/csrf-reactive/runtime/src/main/java/io/quarkus/csrf/reactive/runtime/CsrfTokenParameterProvider.java#L13 have a construcor parameter (it should not be a proper bean). Perhaps it misses Inject for the construr parameter?

In Quarkus, we don't require @Inject to be declared on a single constructor. See https://quarkus.io/guides/cdi-reference#simplified-constructor-injection.

I assume that you're trying to validate that a bean with the name crsf exists. But I'm afraid that you won't be able to perform the validation correctly. Mainly because not all beans are backed by a Java class (https://quarkus.io/guides/cdi-integration#synthetic_beans). Also note that producer beans can declare the name too.

[fbricon]

@mkouba could we imagine quarkus (deployment) jars embed some metadata files describing beans available at runtime?

[fbricon]

@angelozerr we'll probably need to hardcode such metadata in quarkus-ls for a bit

[mkouba]

@mkouba could we imagine quarkus (deployment) jars embed some metadata files describing beans available at runtime?

I don't think we would be able to automate the generation of such metadata so it wouldn't be very convenient from the extension author's point of view 🤷.

[ia3andy]

@mkouba could we imagine quarkus (deployment) jars embed some metadata files describing beans available at runtime?

I don't think we would be able to automate the generation of such metadata so it wouldn't be very convenient from the extension author's point of view 🤷.

We must have something similar to generate the native data, no?

cc @geoand

[geoand]

Yes, we do generate a JSON file for the native stuff.

@mkouba why would generating a metadata file be a problem?

[mkouba]

could we imagine quarkus (deployment) jars embed some metadata files describing beans available at runtime?

We must have something similar to generate the native data, no?

Yes, we do generate a JSON file for the native stuff.

@mkouba why would generating a metadata file be a problem?

First of all, this is something different. We do generate for example reflect-config.json for the native image during application build. But this would need to be part of the -deployment jars of an extension, i.e. generated by the maven plugin. So the maven plugin would need to collect all information without executing build steps. Which is not a trivial task because we don't know which classes will be registered as additional beans, which synthetic beans are created, etc. I think that the only feasible way would be to instruct the extension authors to write the metadata manually. Which is IMO extremely inconvenient, error-prone and difficult to maintain.

[ia3andy]

@mkouba can't we generate it as part of the target app?

[geoand]

I don't see why we are talking about the deployment module and not the target application.