Validate the default JAXBContext at build time only if it is really u…

[ppalaga]

…sed in the application; do not validate if user provides his own JAXBContext bean or if there is no JAXBContext injection point

Fix #31646

[quarkus-bot]

Thanks for your pull request!

The title of your pull request does not follow our editorial rules. Could you have a look?

• title should not end up with ellipsis (make sure the title is complete)

This message is automatically generated by a bot.

[Sgitario]

Apart from the comments, these changes cause a build cycle exception in the RESTEasy Reactive Jaxb tests.

[ppalaga]

5e39264:

• Addressed the feedback by @Sgitario (thanks!)
• Solved the BuildStep methods cycle by not producing a ValidationErrorBuildItem and rather throwing a DeploymentException direcly plus consuming a JaxbContextConfigRecorder to force the container to call validateDefaultJaxbContext().

@Sgitario please feel free to re-review

[Sgitario]

lgtm! thanks @ppalaga !

btw, I still think #31651 is something we could incorporate. Let me know if you want to add this change as part of your pull request or I should add it after yours is merged.

[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.

[Sgitario]

Let's merge this as it is.

[ppalaga]

I still think #31651 is something we could incorporate.

On one hand, it looks like a nice general improvement.
OTOH, I wonder how transparent can we make it for the users to understand that in spite they have a dependency bringing org.acme.Foo class, that class might still not be available in the default JAXBContext because some extension "Bar" that the user also happens to have in his classpath chose to exclude org.acme.Foo? However well we document that behavior in extension "Bar", it can still be very surprising to the users.

Having a catch-all default JAXBContext is definitely intuitive and user friendly, but it is very hard to say who should be responsible for solving the namespace conflicts. I do not feel like it should (always) be extension devs, because they might not know what the users want. Maybe sometimes the choice is clear, e.g. when one half of the conflicting classes is deprecated or outdated. Maybe in such situations ExcludeJaxbClassesToBeBoundBuildItem would be useful.