Claus Ibsen created CAMEL-25820:
-----------------------------------
Summary: camel-jbang - the default log4j configuration leaves log
files in ~/.camel, such as ${sys:pid}.log
Key: CAMEL-25820
URL: https://issues.apache.org/jira/browse/CAMEL-25820
Project: Camel
Issue Type: Bug
Components: camel-jbang
Reporter: Claus Ibsen
Fix For: 4.24.0
{{camel-jbang-core/src/main/resources/log4j2.properties}} is the configuration
that {{camel run}} uses (with color). It is also the configuration that log4j
finds on the classpath of any JVM with camel-jbang-core, when nothing
configures logging. Its file appender writes to
{{$\{sys:user.home\}/.camel/$\{sys:pid\}.log}}. That leaves log files in
{{~/.camel}} in three ways. One machine had 17 such files, from Oct 15 to Oct
19.
# *A file named {{$\{sys:pid\}.log}}.* Only {{CamelJBangMain.execute()}} and
{{RuntimeUtil.configureLog()}} set the {{pid}} system property. A JVM that uses
camel-jbang-core without them writes its first log line to a file of that
literal name. An example is a test of a module that depends on camel-jbang-core
and has no log4j configuration of its own. Reproduced with a test in
camel-jbang-plugin-validate that logs one warning with SLF4J. The file on the
machine (Oct 16) had one line, logged in a test with JUnit parallel mode
(thread ForkJoinPool-1-worker-1):
{noformat}WARN 31691 --- [Pool-1-worker-1]
knt.schema.keyword.UnknownKeywordFactory : Unknown keyword templateEntry - you
should define your own Meta Schema. ...{noformat}
That warning comes from the Kamelet schema that {{YamlValidator}}
(camel-yaml-dsl-validator) builds. The schema keeps a subschema under the root
key {{templateEntry}}, which is not a JSON schema keyword. The warning is
logged each time a Kamelet is validated.
# *{{<pid>.log}} of {{camel test run}}.* The command sets {{pid}}, and log4j
then loads this configuration, so a Citrus test run writes
{{~/.camel/<pid>.log}}. Only {{camel run}} removes its log, so the file stays.
9 files on the machine, such as one of the camel-jbang-examples
({{CamelRunIntegrationAction : Starting Camel integration 'rest-code-first'}}).
The tests of camel-jbang-plugin-test write one too.
# *{{<pid>.log}} of tests that run Camel.* The file is under
{{$\{sys:user.home\}}}, not under the home directory that the CLI uses
({{CommandLineHelper.getCamelDir()}}). A test that runs Camel in its JVM, with
a home directory of its own, logs into the real {{~/.camel}}. The run looks for
its log in its own home directory, so the file stays. 7 files of about 450 KB
on the machine, from the tests of camel-jbang-plugin-kubernetes.
A fix could:
* Make the {{log4j2.properties}} that log4j finds on the classpath log to the
console only. The configuration of {{camel run}} gets a name of its own, such
as {{log4j2-color.properties}} next to {{log4j2-no-color.properties}}.
{{RuntimeUtil}} loads it by name in two places.
* Name the log file after a property that {{RuntimeUtil}} sets from
{{CommandLineHelper.getCamelDir()}}, so a CLI with another home directory logs
there.
* Keep the Kamelet subschema of {{YamlValidator}} under {{$defs}}, so that
validating a Kamelet logs no warning.
The PR of CAMEL-25784 removes a {{<pid>.log}} of a process that is gone after a
day, when no status file names it. That clears these files away, but does not
stop them.
_Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
