JiriOndrusek opened a new pull request #2859: URL: https://github.com/apache/camel-quarkus/pull/2859
fixes https://github.com/apache/camel-quarkus/issues/2651 supersedes https://github.com/apache/camel-quarkus/pull/2845 Adds support of new SPI - https://github.com/apache/camel/pull/5714 This enhancement uses vertx for the http server. Servers are started for required ports ad are managed via quarkus. Tests are still using jetty http server - but only in scope test. Unfortunatelly there is no public access to these methods (which have to be used in http server) - [HttpTranscier#readBuffers](https://github.com/justinsb/avro/blob/master/src/java/org/apache/avro/ipc/HttpTransceiver.java#L73), [HttpTransciever#writeBuffers](https://github.com/justinsb/avro/blob/master/src/java/org/apache/avro/ipc/HttpTransceiver.java#L94) and [HttpTransciever#writeLength](https://github.com/justinsb/avro/blob/master/src/java/org/apache/avro/ipc/HttpTransceiver.java#L104). For that reason, vertx request handler has to leverage [RespondServlet](https://github.com/justinsb/avro/blob/master/src/java/org/apache/avro/ipc/ResponderServlet.java), which requires creation of very simple `HttpServletRequest` and `HttpServletResponse`, which basically wraps `byte[]`. It makes sense to ask whether it is possible to make these methods public (or for example through creations of class called VertxResponder). If yes, `VertxHttpServer.java ` could be simplified - but that would be covered by follow-up issue. @ppalaga It seems, that we don't need to use any blocking feature of vertx here, camel component waits for the response of the server. But there is a small issue here. Vertx logs warnings if thread is blocked for more than 2000 ms. I'm not sure whether this could affect users. (but it doesn't affect the functionality) WDYT? <!-- Uncomment and fill this section if your PR is not trivial [ ] 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 #<issueNumber> or Fixes #<issueNumber> 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 --> -- 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
