ppalaga commented on code in PR #3953:
URL: https://github.com/apache/camel-quarkus/pull/3953#discussion_r936617797
##########
integration-tests/validator/src/main/resources/application.properties:
##########
@@ -15,4 +15,5 @@
## limitations under the License.
## ---------------------------------------------------------------------------
-quarkus.native.additional-build-args
=-H:ResourceConfigurationFiles=resources-config.json
\ No newline at end of file
+quarkus.native.additional-build-args
=-H:ResourceConfigurationFiles=resources-config.json
+quarkus.ssl.native=true
Review Comment:
I see that this is needed for accessing the GitHub https URL. But I wonder
how should we help end users to get around this. Maybe we should just document
it in `usage.adoc`, something like
```
If you are accessing XSD resources via HTTPS (e.g.
`from(...).to("validator:https://acme.org/foo/schema.xsd";)`) than you need to
add `quarkus.ssl.native = true` to your `application.properties`.
```
Hardcoding SSL support (like we do in some other extensions) seems to be an
overkill in this case, IMO. I guess users will mostly use classpath resources.
WDYT @jamesnetherton?
##########
integration-tests/validator/src/main/resources/application.properties:
##########
@@ -15,4 +15,5 @@
## limitations under the License.
## ---------------------------------------------------------------------------
-quarkus.native.additional-build-args
=-H:ResourceConfigurationFiles=resources-config.json
\ No newline at end of file
+quarkus.native.additional-build-args
=-H:ResourceConfigurationFiles=resources-config.json
Review Comment:
I see that this is an old code, but we could perhaps use this occasion to
change it towards Quarkus way of doing things:
```suggestion
quarkus.native.resources.includes = *.xsd
```
##########
integration-tests/validator/src/main/java/org/apache/camel/quarkus/component/validator/it/ValidatorRouteBuilder.java:
##########
@@ -21,7 +21,14 @@
public class ValidatorRouteBuilder extends RouteBuilder {
@Override
public void configure() {
- from("direct:start")
+ from("direct:classpath")
.to("validator:message.xsd");
+
+ from("direct:filesystem")
+ .to("validator:file:src/main/resources/message.xsd");
+
+ from("direct:http")
+
.toD("validator:https://raw.githubusercontent.com/apache/camel-quarkus/main/integration-tests/validator/src/main/resources/message.xsd";);
Review Comment:
This might be risky for several reasons:
* If we change message.xsd in the future, the tests in older branches may
start failing
* GitHub might be inaccessible in some environments
* GitHub's availability will impact the reliability of this test
I'd vote for serving message.xsd from an ad hoc WireMock server. There are
plenty of examples in the source tree.
##########
integration-tests/validator/src/test/java/org/apache/camel/quarkus/component/validator/it/ValidatorTest.java:
##########
@@ -25,26 +25,75 @@
class ValidatorTest {
@Test
- public void validXML() {
+ public void validXMLFromClassPath() {
RestAssured.given()
.contentType(ContentType.XML)
.body("<message><firstName>MyFirstname</firstName><lastName>MyLastname</lastName></message>")
- .post("/validator/xml")
+ .post("/validator/classpath")
.then()
.statusCode(200);
}
Review Comment:
I'd vote for having one parameterized test for the valid case and one for
invalid case. The params being `"classpath", "filesystem", "http"`. Just grep
for `@ParameterizedTest` in the source tree to see some examples.
Less code is perhaps easier to maintain.
##########
integration-tests/validator/src/main/java/org/apache/camel/quarkus/component/validator/it/ValidatorResource.java:
##########
@@ -32,11 +32,28 @@ public class ValidatorResource {
@Inject
ProducerTemplate producerTemplate;
- @Path("/xml")
+ @Path("/classpath")
@POST
@Consumes(MediaType.APPLICATION_XML)
@Produces(MediaType.TEXT_PLAIN)
- public String processOrder(String statement) {
- return producerTemplate.requestBody("direct:start", statement,
String.class);
+ public String processOrderInXmlFromClassPath(String statement) {
+ return producerTemplate.requestBody("direct:classpath", statement,
String.class);
}
+
+ @Path("/filesystem")
+ @POST
+ @Consumes(MediaType.APPLICATION_XML)
+ @Produces(MediaType.TEXT_PLAIN)
+ public String processOrderInXmlFromFileSystem(String statement) {
+ return producerTemplate.requestBody("direct:filesystem", statement,
String.class);
+ }
+
+ @Path("/http")
+ @POST
+ @Consumes(MediaType.APPLICATION_XML)
+ @Produces(MediaType.TEXT_PLAIN)
+ public String processOrderInXmlFromHTTP(String statement) {
+ return producerTemplate.requestBody("direct:http", statement,
String.class);
+ }
Review Comment:
I'd vote for having just one parameterized endpoint instead of three
non-parameterized. Something like
```
@Path("/validate/{scheme}")
@POST
@Consumes(MediaType.APPLICATION_XML)
@Produces(MediaType.TEXT_PLAIN)
public String processOrderInXmlFromFileSystem(String statement,
@PathParam("scheme") String scheme) {
return producerTemplate.requestBody("direct:" + scheme, statement,
String.class);
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
