Claus Ibsen created CAMEL-26191:
-----------------------------------
Summary: camel-docker - imagebuild with a String body logs an
error and succeeds, and the output of containerlog, attach and execstart is lost
Key: CAMEL-26191
URL: https://issues.apache.org/jira/browse/CAMEL-26191
Project: Camel
Issue Type: Bug
Components: camel-docker
Reporter: Claus Ibsen
Fix For: 4.24.0
Found while adding the catalog body types of docker (CAMEL-24961, PR #28414).
h4. 1. imagebuild with a String or byte[] body succeeds with the body unchanged
{{AsyncDockerProducer.executeBuildImageRequest}} (main 2a465aa4814c, line 239
to 252) accepts only an InputStream or File body and throws a DockerException
"Unable to location source Image" (sic) otherwise.
{{AsyncDockerProducer.process}} catches the DockerException at line 122, only
logs it, and completes the exchange: the build did not run, and the exchange
succeeds with the body unchanged. Checked on 4.24.0-SNAPSHOT with a mocked
DockerClient.
Proposed: set the exception on the exchange instead of logging it (all
operations of the async producer), and convert text/byte[] to an InputStream or
fix the message.
h4. 2. imagebuild with a stream body ends with each item's image id, null for a
tagged build
The {{BuildImageResultCallback.onNext}} (line 142) sets the body to
{{item.getImageId()}} for each build item, so the last item wins; for a tagged
build the last item has no image id and the body ends null. Checked on
4.24.0-SNAPSHOT with a mocked DockerClient.
Proposed: set the body once to {{awaitImageId()}} of the callback after the
build completed.
h4. 3. The output of containerlog, attach and execstart is lost, and imagepull,
imagepush and containerwait give the callback
{{AsyncDockerProducer.runAsyncWithFrameResponse}} (line 150 to 159) only logs
each {{Frame}} at TRACE, and {{setResponse}} (line 185 to 189) sets the
callback object as the body. The log lines or the command output are never
available to the route. imagepull, imagepush and containerwait also give the
callback object as the body, not the result (the exit code of containerwait).
Checked on 4.24.0-SNAPSHOT with a mocked DockerClient.
Proposed: collect the frames (as text or a List) and set them as the body, and
set the result of the callback (for example the status code of containerwait)
instead of the callback object.
h4. 4. The default cmdExecFactory fails on macOS
The default {{cmdExecFactory}} is {{NettyDockerCmdExecFactory}}
({{DockerConfiguration}} line 68 to 69), while
{{DockerConstants.DEFAULT_CMD_EXEC_FACTORY}} (line 36) names the Jersey
factory. On macOS the Netty factory fails on the unix socket with an
UnsatisfiedLinkError (kqueue); with
{{cmdExecFactory=com.github.dockerjava.jaxrs.JerseyDockerCmdExecFactory}} the
same calls work. Checked on 4.24.0-SNAPSHOT with a local docker daemon on macOS
(read-only calls).
Proposed: make the Jersey factory the default (as the constant says), or add
the Netty kqueue native dependency for macOS.
h4. 5. The events consumer may pass the since time in milliseconds
{{DockerEventsConsumer.processInitialEvent}} (line 81 to 90) computes the start
of the event stream from {{System.currentTimeMillis()}}, and the value is
passed to {{withSince}} (line 135); the Docker API expects seconds. Not
verified against a daemon. Read in the code, not run.
Proposed: check what docker-java expects for {{withSince}} and convert to
seconds if needed.
_Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
