On 06/05/2016 09:37, Violeta Georgieva wrote: > Let me summarize the findings till now. > > According to [1] > > 1) when Class.getResource(name) > "The resource name given to a Class method may have an initial starting "/" > that identifies it as an "absolute" name. Resource names that do not start > with a "/" are "relative". > Absolute names are stripped of their starting "/" and are passed, without > any further modification, to the appropriate ClassLoader method to locate > the resource. > Relative names are modified according to the convention described > previously and then are passed to a ClassLoader method." > > So when "name" is absolute the leading "/" slash will be removed and the > call will be delegated to ClassLoader.getResource(name) > > 2) when ClassLoader.getResource(name) > "The methods in ClassLoader use the given String as the name of the > resource without applying any absolute/relative transformation (see the > methods in Class). The name should not have a leading "/"." > > As we saw above (Konstantin's example) call with > - name without leading "/" is successful > - name with leading "/" returns null > > According to [2] > 3) when URLClassLoader.getResource(name) > "This class loader is used to load classes and resources from a search path > of URLs referring to both JAR files and directories. > findResource(name) > Finds the resource with the specified name on the URL search path." > > Now from the source code [3] > URLClassLoader.findResource delegates the call to the > sun.misc.URLClassPath.findResource > For resource in a jar file - URLClassPath.Loader is used. It just creates a > new url based on the jar file and the provided name. > When creating the URL - sun.net.www.protocol.jar.Handler (parseContextSpec) > removes the leading "/" and the URL to the resource is created successfully. > > So if we construct URLClassLoader and call with: > - name without leading "/" is successful > - name with leading "/" is again successful > > ====== > Now to the issue that the user reports. The > org.apache.naming.resources.ClasspathURLStreamHandler is implemented in a > way that > - when searching the web app loader the implementation uses > ClassLoader.getResource > - but when searches the Tomcat class loader it uses Class.getResource > > Because of this when the jar files are packed in the application and the > resource has leading "/" it cannot be found, but when moving the jar files > to the Tomcat lib the resource will be found. > > As WebappClassLoader extends URLClassLoader > We have to decide whether WebappClassLoader.getResource() should be > consistent with Java API of java.lang.ClassLoader.getResource() or > URLClassLoader.getResource() behavior. > A quick check to other web containers showed that they behave as Tomcat 8. > > I tend to implement Tomcat 7 behaviour as Tomcat 8 and support resource > names with leading "/". > But as this behaviour is not strictly specified I prefer to get more > opinions. > > With the introduction of ClasspathURLStreamHandler (7.0.66) we break user's > scenario that was working previously. > > [1] > https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html > [2] https://docs.oracle.com/javase/8/docs/api/java/net/URLClassLoader.html > [3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/
Coming back to this. Having read through this thread and looked at the svn history, it looks like a back-port of r1539623 (any any related commits) is required. I'm planning on looking at this today. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
