Hi Hoss, The bug is not really in ClassPathResourceLoader, but in the way how it handles resources and that made Robert use it incorrectly. In tests of Lucene Analysis Factories we often use new ClasspathResourceLoader(getClass()) to make loading resources easier. This instance will assume the resource is in the local Java package. This makes it easier to "test" resources, already shipped with analyzers in their package. In that test, the bug was that this easy way was not useable or incorrect. For this test "new ClasspathResourceLoader()" should have been used, which is the standard way of using them (and also the way, the user expects).
The bug is using ClassPathResourceLoader with a local class in tests when a absolute resource name was wanted. We should document that in the ClasspathResourceLoader, that the one taking a Class is only used for tests, not public code. Maybe hide that one alltogether and only make it available in BaseTokenStreamTestCase. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Chris Hostetter [mailto:[email protected]] > Sent: Friday, August 17, 2012 4:02 AM > To: [email protected] > Subject: Re: [jira] [Commented] (SOLR-3737) StempelPolishStemFilterFactory > can't find resource '/org/apache/lucene/analysis/pl/stemmer_20000.tbl' > > > : Sorry, Solr is correct. When directly passed to ResourceLoader the path > : is correct. The problem here is the way how ClasspathResourceLoader > : handles this. It uses Class.getResource() to load and thats wrong, > : because that one expects a "/" to be absolute. We have to fix this and > : maybe fix some tests not giving absolute paths. > > I'm confused ... it looks like ultimately this specific bug was fixed by changing > StempelPolishStemFilterFactory directly to not use the ResourceLoader at all, > but Uwe's comments suggest that there is still a fundemental problem in > ClasspathResourceLoader. > > Presumably that should get a new bug? Or was Uwe mistaken? > > > > -Hoss > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
