Re: Question for the loader used in o.a.t.util.scan.StandardJarScanner
2013/3/20 Mark Thomas wrote: On 20/03/2013 13:55, Violeta Georgieva wrote: Hi, I have a question for the loader that is used in o.a.t.util.scan.StandardJarScanner.scan(ServletContext, ClassLoader, JarScannerCallback, SetString) (7.0.x trunk). Why don't we use the loader that is provided as a method parameter, but instead of this we are using the thread context class loader? It looks like a left over from when the code was first refactored to create the StandardJarScanner. I agree, we should use the passed in class loader. Can I introduce this change for 7.0.39 or it is late already? row 196 ClassLoader loader = row 197Thread.currentThread().getContextClassLoader(); And why don't we start scanning from its parent, but instead of this we start with it directly? Because of the possibility of external repositories having been configured. There are other ways this could be handled but the current code works. In Tomcat 8 the new resources implementation makes all this a lot simpler. I understand. I can see that in tomcat/trunk we are using the provided loader and we start scanning from its parent. The Javadoc needs correcting as well. I'll correct it also. Thanks Vily - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question for the loader used in o.a.t.util.scan.StandardJarScanner
On 21/03/2013 08:09, Violeta Georgieva wrote: 2013/3/20 Mark Thomas wrote: On 20/03/2013 13:55, Violeta Georgieva wrote: Hi, I have a question for the loader that is used in o.a.t.util.scan.StandardJarScanner.scan(ServletContext, ClassLoader, JarScannerCallback, SetString) (7.0.x trunk). Why don't we use the loader that is provided as a method parameter, but instead of this we are using the thread context class loader? It looks like a left over from when the code was first refactored to create the StandardJarScanner. I agree, we should use the passed in class loader. Can I introduce this change for 7.0.39 or it is late already? Go for it. The Base64 encoder/decoder discussion needs to be resolved first so there is plenty of time for this. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Question for the loader used in o.a.t.util.scan.StandardJarScanner
Hi, I have a question for the loader that is used in o.a.t.util.scan.StandardJarScanner.scan(ServletContext, ClassLoader, JarScannerCallback, SetString) (7.0.x trunk). Why don't we use the loader that is provided as a method parameter, but instead of this we are using the thread context class loader? row 196 ClassLoader loader = row 197Thread.currentThread().getContextClassLoader(); And why don't we start scanning from its parent, but instead of this we start with it directly? I can see that in tomcat/trunk we are using the provided loader and we start scanning from its parent. Thanks Violeta - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question for the loader used in o.a.t.util.scan.StandardJarScanner
On 20/03/2013 13:55, Violeta Georgieva wrote: Hi, I have a question for the loader that is used in o.a.t.util.scan.StandardJarScanner.scan(ServletContext, ClassLoader, JarScannerCallback, SetString) (7.0.x trunk). Why don't we use the loader that is provided as a method parameter, but instead of this we are using the thread context class loader? It looks like a left over from when the code was first refactored to create the StandardJarScanner. I agree, we should use the passed in class loader. row 196 ClassLoader loader = row 197Thread.currentThread().getContextClassLoader(); And why don't we start scanning from its parent, but instead of this we start with it directly? Because of the possibility of external repositories having been configured. There are other ways this could be handled but the current code works. In Tomcat 8 the new resources implementation makes all this a lot simpler. I can see that in tomcat/trunk we are using the provided loader and we start scanning from its parent. The Javadoc needs correcting as well. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
