Alas, I spoke too soon; after merging in my change to the implementation classes, it looks like now both Postman AND the cpp client stubs fail to successfully pass an argument through the body of a PUT request.
The client side hasn’t changed so I believe the PUT request is still properly formatted. Interestingly, now both Postman (which sends the data in a single packet) and the cpprest client (which sends the headers and the body in separate packets)
fail the same way, so there must be something more subtle I’m just missing. At least I’m now on a supported build.
FWIW, the stub generated for the function in question is
public abstract Response twiddle(HostSpec body,SecurityContext securityContext) throws NotFoundException;
but when it’s invoked ‘body’ is a null pointer (and previously, using Postman, it would instead have the expected object format).
Any suggestions for further tweaks or tests would be appreciated. Are there means of externally enabling some logging of the Jetty internals?
Thanks all the same,
-Patrick.
Hi
Joakim,
9.2.9 is rather old, even for the EOL 9.2.x series.
Consider using 9.2.28.v20190418.
Or if you want latest stable release, use 9.4.17.v20190418
Yes, I just noticed on the Jetty web site that 9.2.x was, in fact, EOL. I’m not sure how my system ended up with 9.2.9 installed - I believe that was hard-wired in the generated SwaggerHub server stubs.
I’m not sure what incompatibilities I should look out for upgrading to 9.4.x. Offhand, just changing “jetty-version” in the generated pom.xml to 9.4.17.v20190418 makes “man clean package jetty:run” yields a complaint about the “.jar” format swagger-jaxrs-server
that gets built not being supported:
[INFO] <<< jetty-maven-plugin:9.4.17.v20190418:run (default-cli) < test-compile @ swagger-jaxrs-server <<<
[INFO]
[INFO]
[INFO] --- jetty-maven-plugin:9.4.17.v20190418:run (default-cli) @ swagger-jaxrs-server ---
[INFO] Logging initialized @6783ms to org.eclipse.jetty.util.log.Slf4jLog
[INFO] Skipping swagger-jaxrs-server : packaging type [jar] is unsupported
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.980 s
[INFO] Finished at: 2019-04-20T23:57:41-07:00
[INFO] ————————————————————————————————————
which wasn’t exactly what I was hoping for :-)
OTOH, looking back through the Jetty releases I tried the MUCH more recent 9.3.26.v20190403 and THAT seems to suddenly work as expected! Looks like this may have been an issue cleaned up since 9.2.9 hit the streets!
I think I’m good with 9.3.26.v20190403! I’ll test some other client stubs and see if this actually completely resolved the problem but it certainly appears to have fixes this issue.
Thanks for the tip!
Regards,
-Patrick.
Hi,
I’m new to Jetty - I'm experimenting with an API on SwaggerHub and I've generated both client-side (cpprest) and server-side (JAX-RS) stubs from the API. My server side is running jetty-9.2.9.v20150224.
When I use a client like Postman, which sends the complete request (headers and body) in a single packet, the server responds as expected. When I use the generated (cpprest) client stubs the request headers come in a first packet and the body in a second packet.
The strange part is that, although they re-assemble fine (I can see a valid-looking combined packet in Wireshark), it looks as if the server request is dispatched as soon as the headers arrive, without waiting for the body parameters to arrive (despite the
"Content-length" header value)?
As a result the server sees a request that's got a "null" value for the body parameter (even though the parameter is marked as "required"), as if "delayDispatchUntilContent" is false? I've tried adding a "jetty.xml" file that explicitly defaults and sets "delayDispatchUntilContent"
to "true" but that doesn't seem to make any difference. Neither does Swagger 2.0 vs. OpenAPI 3.0 use make any difference.
Any idea what I'm missing here? Any suggestions for a workaround, or a fix?
Thanks in advance!
-Patrick.
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users
mailing list
jetty-users@xxxxxxxxxxx
To
change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://nam04.safelinks.protection.outlook.com/?url="">
_______________________________________________
jetty-users
mailing list
jetty-users@xxxxxxxxxxx
To
change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://nam04.safelinks.protection.outlook.com/?url="">
