Allow `@CrossOrigin` to appear at the class level

Environment Details

• Helidon Version: 2.x, 3.x, 4.x
• Helidon SE or Helidon MP MP
• JDK version:
• OS:
• Docker version (if applicable):

---

Problem Description

Currently, the @CrossOrigin annotation applies only to methods.

If the developer wants the same CORS behavior for all resources in a given resource class, it would be convenient to annotate the class once rather than apply the same method-level annotation to multiple @Options methods.

[tjquinno]

@Captain1653 I should probably remove the wiki. We used that before we implemented the feature to describe our plans and thinking. The published documentation you linked to is authoritative, and it states that config overrides settings from the code. I have also updated the earlier comment on this issue to restate that.

Do you see a way in which the coding changes to address this issue would be affected by the precedence? It’s possible but that is not what I would expect.

[tjquinno]

@Captain1653 You are now also assigned. Thanks. I’ll look forward to your PR.

@spericas Yes, very good idea. Today the CDI extension stops the server start-up if @CrossOrigin appears on a non-OPTIONS method. The extension should also throw an exception if there is a class-level @CrossOrigin annotation but no methods with an @OPTIONS annotation.

It will be OK to have a class-level @CrossOrigin even if all @OPTIONS methods have their own @CrossOrigin annotation. The class-level one will be ignored; we will log a FINE message in that case.

With these refinements, here is the mini-functional spec:

1. The @CrossOrigin annotation changes so it can appear on a method or a type.
2. The class-level annotation applies to all @OPTIONS methods in the class which do not have their own annotation.
3. If the annotation appears both places, the method-level one takes precedence. They are not “merged”.
4. If the annotation appears at the class level but there are no @OPTIONS methods in the class, the CorsCdiExtension throws an exception identifying the offending class and ending the server start-up.
5. If the annotation appears at the class level but is never used (because all @OPTIONS methods in the class have their own annotation), the extension logs a FINE-level message identifying the class where we are ignoring the class-level annotation.

The overall task list: (with responsible person’s initials)

• Change the microprofile/cors code to add the feature with the behavior described in the mini-functional spec. (AA)
• Update the tests in microprofile/cors to test the new behavior, adding positive and negative tests. (AA)
• Update the examples/microprofile/cors example to use a class-level annotation, making sure there is an @OPTIONS method in the resource class that does not have its own annotation. Update the example’s tests accordingly. (AA)
• Update the docs/mp/cors/cors.adoc doc page. (TQ)

Note that I will plan to do the doc update myself, unless you really want to do that part also Andrei!