The summary line in the Javadoc comment for ServletContext.getRealPath(String) indicates that getRealPath "gets the real path corresponding to the given virtual path." Additional details given in the comment stipulate that the method can return null if the servlet container is "unable" to perform the translation.

Unfortunately, the javadoc comment does not fully elaborate on the definition of "unable," nor does it describe all of the scenarios where the container must, may, or shant be "able." Because of this lack of clarity, the comment itself is probably not normative, and it might be necessary to consult the official J2EE spec for the final word.

However, whenever specs are unclear or unopinionated, interpretive implementations often become de facto standards, and it is sometimes a good idea for new implementations to strive for compatibility with previous implementations.

To be clear, the javadoc comment does not say that the path must exist in order for translation to be successful.

Undertow 1.0.15's implementation of this method correctly converts the provided virtual path to a physical file system path. But then, just before returning the result, it checks to see whether the file (or folder) actually exists, and if it doesn't, it returns null instead.

It's not clear that this behavior is justified or correct. A path does not cease to be a path simply because there is no directory entry matching it. A process might, for example, be interested in describing a path to which a new file might be written.

Undertow's interpretation of this method causes some J2EE apps that used to run correctly on JBoss AS 7.1.1 to no longer run correctly on Wildfly 8.1. For example, apps that use filters to intercept first requests to particular paths, in order to generate the files just in time, may now fail when Undertow provides the servlet context, simply because they can no longer rely on getRealPath to determine the location of the file that needs to be written.