Repository navigation
Allow define a custom HTTP client for getting external resource #1776
Description
Context
Currently when we define a openapi task which has the resource (OpenAPI document) accessible through HTTP server.
do:
- findPet:
call: openapi
with:
document:
endpoint: "https://petstore.swagger.io/v2/swagger.json"We can not (in a easy way) override or to give to the engine a custom HTTP client for performing the HTTP request. Currently, the main implementation to handle external resources is the DefaultResourceLoader, which internally has a private method called buildFromURI:
private ExternalResourceHandler buildFromURI(URI uri, Optional<String> auth) {
String scheme = uri.getScheme();
if (scheme == null || scheme.equalsIgnoreCase("file")) {
return fileResource(uri.getPath());
} else if (scheme.equalsIgnoreCase("http") || scheme.equalsIgnoreCase("https")) {
try {
return new HttpResource(uri.toURL(), auth);Possible solutions
1. Turn buildFromURI protected
Changing the buildFromURI protected method, can help downstream users to give a custom ExternalResourceHandler but the logic to decide what kind of ExternalResourceHandler probably will be duplicated.
2. Define an SPI to replace the HttpResource
Create an interface (can be ResourceHttpClient) which can be injected via additional object and downstream users can override with their own implementation.
Other options
withResourceLoaderFactory()
Correcting my statement (we can not override or to give to the engine a custom HTTP client for performing HTTP request), the engine allow us to define a ResourceLoaderFactory, but this approach is so hard for downstream users. It can produce duplicated code and possible drifts from downstream vs. sdk-java code.
Activity
mathecruz commentedon Oct 19, 2026
Related issue: quarkiverse/quarkus-flow#1089
mathecruz commentedon Oct 19, 2026
@fjtirado any other solution for this case? Additionally I think we can replace the way we are doing the HTTP request using the HTTP Client API
fjtirado commentedon Oct 20, 2026
@mathecruz Yes, I think we need to do both things.
Change DefaultResourceLoader to make it easier to override default HttpResource and change HttpResource to use HTTP client API rather than the old URLConnection.
Im going to do the first thing with this issue and open another issue to do the second
PR opened for the first thing. Issue for improving HttpResource default implementation is #1778
[Fix open-workflow-specification#1776] Make DefaultResourceLoader eas…
[Fix open-workflow-specification#1776] Make DefaultResourceLoader eas…
[Fix #1776] Make DefaultResourceLoader easier to customize (#1777)