如何从 Spring.Net Common Logging 获取日志文件位置/名称
我正在尝试接收插入到我的日志文件中的消息的最后一行（使用 Spring.NET 通用日志记录）。我的第一步是检索文件的名称，这比预期的要复杂一些，因为我找不到相关的属性/转换。
我发现了一些关于如何检索给定 log4net 文件读取器的文件名的文章，但没有从 Spring.NET Common Logging 类开始。
收到文件名后，我将使用反向文件阅读器来检索姓氏。想知道人们对于在文件可能由 Common Logging / log4net 写入时读取该文件的想法吗？
I am trying to receive the last line of a message inserted into my log file (using Spring.NET Common Logging). My first step is to retrieve the name of the file which is a little tricker than expected as I cant find the relevant properties/cast for this.
I've found a few articles of how to retrieve the filename given the log4net file reader but nothing starting from the Spring.NET Common Logging class.
After I have received the filename, I will use a reverse file reader to retrieve the last name. Wondering peoples thoughts about reading in the file whilst it's potentially being written to by Common Logging / log4net?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您应该能够打开该文件进行读取，同时该文件仍然打开以供日志记录基础设施写入，但我有点担心您计划读取“最后”行。在您发现需要打开文件的时间点和您设法打开文件以读取文件的时间点之间，其他东西可以将条目写入日志文件，使您可能很难通过以下方式获得所需的行：假设它是日志中的“最后”行。
我是否正确地假设这是一种响应某些错误条件然后获取与该错误相关的相关日志条目的方法？如果是这样，我建议不要通过读取“最后”行来从日志文件中收集此信息，而是建议您解析文件以搜索正确的日志条目（例如，按日期/时间或其他一些信息而不是“最后的'）。
否则，您可能会在简单的测试场景中获得正确的日志条目，但在任何类型的真正并行负载下的生产系统中根本无法获得正确的日志条目。这里只是我的 2 美分...
You should be able to open the file for reading while its still open for writing by the logging infrastructure, but I'm a bit worried about your plans to read the "last" line. Between the point where you discover you need to open the file and the point where you manage to open the file to read it something else can write an entry to the log file, making it potentially difficult for you to get the line you want just by assuming its the 'last' line in the log.
Am I correct in assuming that this is a kind of way to respond to some error condition and then acquire the correlated log entries related to that error? If so, I'd recommend against gathering this info from the log file by reading the 'last' line and instead recommend that you parse the file searching for the right log entry (e.g., by date/time or some other info rather than 'last').
Otherwise, you're probably going to get the right log entry back in simplistic testing scenarios but not at all in a production system under any kind of real parallel load. Just my 2-cents here...