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

Log4j XML event with missing attributes in locationInfo is silently ignored #588

Open
JacobsRoel opened this issue Oct 29, 2021 · 2 comments

Comments

@JacobsRoel
Copy link

Would it be possible to have a more lenient parsing of log4 xml layout files?

For example, the following event parses just fine:

<log4j:event logger="SomeLogger" level="ERROR" timestamp="1635416867453" thread="16">
  <log4j:message>This is ok</log4j:message>
   <log4j:locationInfo class="" method="" file="" line="" />
</log4j:event>

While this is silently ignored:

<log4j:event logger="SomeLogger" level="ERROR" timestamp="1635416867453" thread="16">
  <log4j:message>Log event is not processed/show when locationInfo has no class attribute</log4j:message>
   <log4j:locationInfo method="" file="" line="" />
</log4j:event>

This does violate the DTD, which states that the class attribute is required.
https://raw.githubusercontent.com/apache/logging-log4j2/master/log4j-core/src/test/resources/log4j.dtd

The events are ignored without warning (maybe there is, totally missed it then), leading to possible wrong conclusions when spelunking in log files. Maybe even a sort of ghost record in the log table that indicates some issues with the event?

What do you think?

@otrebski
Copy link
Collaborator

Log4j xml support was dropped with #591 (classpath dependency to log4j 1.x with security bug). @JacobsRoel if you want to implement log parser for log4j2 xml I can help you with pull request.

@benlazaro
Copy link
Contributor

I can work on the Log4j2 XML parser, I just need to know what are the parsing rules. If anybody can point me in the right direction for finding that, I should have no problems creating the parser.

On another note, I have a quick suggestion about versioning and releases for the project, which is kind of related to this issue.
It would be very beneficial for end users if we release a new major version when a feature gets drop from the application's scope, since that is the equivalent of saying: "Some changes in this release are not backwards compatible with the previous version of the application, so you can expect different behavior in some areas of the application with this release".
We can also apply the same for when we add new features, but that would increment the minor version instead, and the major version would remain the same.
Just my 2 cents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants