garydgregory commented on code in PR #3855:
URL: https://github.com/apache/logging-log4j2/pull/3855#discussion_r2465378648
##########
log4j-core/src/main/java/org/apache/logging/log4j/core/appender/FileManager.java:
##########
@@ -343,6 +344,16 @@ protected synchronized void writeToDestination(final
byte[] bytes, final int off
public String getFileName() {
return getName();
}
+
+ /**
+ * Returns the Path of the file being managed.
+ * @return The name of the file being managed.
+ * @since 2.26.0
+ */
+ public Path getPath() {
Review Comment:
> A small naming suggestion: since we already have a getFileName() method,
it might be clearer to name this new method getFilePath() instead of getPath().
Names are important and I'm glad we're discussing them.
IMO, "getFilePath()" is bad because it implies this is a Path to a file://
only, and since a Path is an interface for locating a file in a file system,
we should not set expectations that the implementation of the Path is only for
file-schemed Paths.
It doesn't matter that there's already an API called "getFileName()", a file
name is very different from a Path, where the expectation (from a NIO Path POV)
is that the file name is the last segment, the "bar.txt" in "/foo/bar.txt".
Having a common prefix between these two methods has no benefit.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
