Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using console-capture with StdErrLog results in empty log file #4620

Closed
TezzerFX opened this issue Mar 1, 2020 · 8 comments · Fixed by #4630 or #4689
Closed

Using console-capture with StdErrLog results in empty log file #4620

TezzerFX opened this issue Mar 1, 2020 · 8 comments · Fixed by #4630 or #4689
Assignees

Comments

@TezzerFX
Copy link

TezzerFX commented Mar 1, 2020

The "jetty.console-capture.dir" was set and the server created the ...jetty.log file on launch, but the log messages were still being written to the console's Stderr and Stdout. As a workaround I replaced the
StdErrLog.class in the jetty-util-9.4.27.v20200227.jar with the version from jetty-util-9.4.26.v20200117.jar which restored the 9.4.26 behavior, writing the messages to the log file as per the 9.4.27 documentation.

@joakime
Copy link
Contributor

joakime commented Mar 1, 2020

Interesting ...

@joakime joakime self-assigned this Mar 1, 2020
joakime added a commit that referenced this issue Mar 2, 2020
@joakime
Copy link
Contributor

joakime commented Mar 2, 2020

A minimal fix to console-capture.xml can be found at in commit 6bf868e

https://github.com/eclipse/jetty.project/blob/6bf868e03b5982aa067238b1c8cd6dbaf1f4580d/jetty-util/src/main/config/etc/console-capture.xml#L20-L23

Line 21

joakime added a commit that referenced this issue Mar 2, 2020
@joakime joakime linked a pull request Mar 2, 2020 that will close this issue
@joakime
Copy link
Contributor

joakime commented Mar 2, 2020

Opened PR #4630

@joakime
Copy link
Contributor

joakime commented Mar 2, 2020

The minimal fix to console-capture.xml (in commit 6bf868e) would make console-capture dependent on StdErrLog, which it historically hasn't been.

So the behaviors of StdErrLog with regards to alternate PrintStream has been restored, allowing console-capture to do it's thing.

@TezzerFX
Copy link
Author

TezzerFX commented Mar 2, 2020

Thanks Joakim, that did the trick... Prior to the quick fix there was warning message
"...WARN:oejx.XmlConfiguration:main: Ignored arg: <Arg name="threadpool"><Ref refid="threadPool"/></Arg>", what was that about?

@joakime
Copy link
Contributor

joakime commented Mar 2, 2020

@TezzerFX opened Issue #4631 about the WARN on threadpool. It's harmless, and works in spite of the warning message, but still needs to be fixed (in PR #4632)

joakime added a commit that referenced this issue Mar 3, 2020
Issue #4620 - Better support for alt PrintStream in StdErrLog
@joakime
Copy link
Contributor

joakime commented Mar 3, 2020

Merged PR #4630

@joakime joakime closed this as completed Mar 3, 2020
@joakime joakime changed the title Jetty’s StdErrLog console-capture Using console-capture with StdErrLog results in empty log file Mar 20, 2020
@joakime joakime reopened this Mar 21, 2020
@joakime
Copy link
Contributor

joakime commented Mar 21, 2020

This fix didn't get merged to Jetty 10.0.x properly.

joakime added a commit that referenced this issue Mar 21, 2020
+ The console-capture jetty module will reset System.err to
  RollingFileOutputStream.  But that's too late, as StdErrAppender
  has already grabbed and is holding onto the System.err from
  earlier, which means it is not writing to the new System.err.

Signed-off-by: Joakim Erdfelt <[email protected]>
joakime added a commit that referenced this issue Mar 23, 2020
…e-capture

Issue #4620 - support alt PrintStream in StdErrAppender properly
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants