Solr native support fixes #1703 #2026
Conversation
There was a problem hiding this comment.
Great test coverage, @zbendhiba, thanks a lot! Looks good, some comments/questions inline.
integration-tests/solr/pom.xml
Outdated
| <artifactId>maven-surefire-plugin</artifactId> | ||
| <configuration> | ||
| <systemPropertyVariables> | ||
| <!-- force the locale as we want to explicitly test message interpolation --> |
There was a problem hiding this comment.
The comment is maybe a leftover and can be removed?
| <configuration> | ||
| <systemPropertyVariables> | ||
| <!-- force the locale as we want to explicitly test message interpolation --> | ||
| <javax.net.ssl.trustStore>${solr.trust-store}</javax.net.ssl.trustStore> |
There was a problem hiding this comment.
This will not work OotB on the platform, where the tests are run from test jars and the local resources are not available. I see that this also cannot be configured to pull the trust store from the jar, because the system property expects a local file. Hence a special step will be needed on the platform to unpack the test jar and set the trust store accordingly. Maybe we could make creating that preprocessing step easier by some changes here. Let me file a followup for that.
| <properties> | ||
| <quarkus.package.type>native</quarkus.package.type> | ||
| <quarkus.native.additional-build-args>-H:IncludeResources=.*ssl/.*,-J-Djavax.net.ssl.trustStore=${solr.trust-store}, | ||
| -J-Djavax.net.ssl.trustStorePassword=${solr.trust-store-password}</quarkus.native.additional-build-args> |
There was a problem hiding this comment.
Is there any reason not to put this as quarkus.native.additional-build-args to application.properties? Maybe because the local path has to be absolute?
There was a problem hiding this comment.
yes!! that's the problem. I've actually copied that way of adding these attribute from one of the tests in quarkus project
There was a problem hiding this comment.
Thanks @zbendhiba!
I'd take care for the follow up #2029 because I'd like to experiment with some options and I am not sure which one of them will work.
|
Are you looking at the test failure, @zbendhiba ? |
|
@ppalaga I can't tell if the error comes from this 👍 Caused by: io.quarkus.bootstrap.resolver.maven.DeploymentInjectionException: io.quarkus.bootstrap.resolver.maven.BootstrapMavenException: Failed to read descriptor of io.quarkus:quarkus-resteasy-jackson-deployment🫙1.10.0.Final |
[ ] An issue should be filed for the change unless this is a trivial change (fixing a typo or similar). One issue should ideally be fixed by not more than one commit and the other way round, each commit should fix just one issue, without pulling in other changes.
[ ] Each commit in the pull request should have a meaningful and properly spelled subject line and body. Copying the title of the associated issue is typically enough. Please include the issue number in the commit message prefixed by #.
[ ] The pull request description should explain what the pull request does, how, and why. If the info is available in the associated issue or some other external document, a link is enough.
[ ] Phrases like Fix # or Fixes # will auto-close the named issue upon merging the pull request. Using them is typically a good idea.
[ ] Please run mvn process-resources -Pformat (and amend the changes if necessary) before sending the pull request.
[ ] Contributor guide is your good friend: https://camel.apache.org/camel-quarkus/latest/contributor-guide.html