Hi Alan, > LUCENE-9281 moved the `lookupSPIName` method from > AbstractAnalysisFactory to AnalysisSPILoader; the method is mostly the same, > but one line has been changed from Class.getField() to > Class.getDeclaredField(). > This can fall foul of the Security Manager, which wants a higher level of > permission for getDeclaredField. Was this an intentional change? As I
This was intentional because the previous code wasn't fully correct, because I had some safety check in mind: The main reason for the getDeclaredField() is to lookup the field only in this class; while getField() also looks into superclasses. E.g. if the superclass has a NAME field because of a programming error it would pick that up, which would be wrong. When investigating other implementations using "named" lookups out there (even in JDK), they used getDeclaredField() when accessing a static member. There are 2 solutions: - Change to getField(), but in the if statement below check the actual class: (field.getDeclaringClass()==service) (see https://github.com/apache/lucene-solr/pull/1360/files#diff-6a65d91199a18bc4ee2d00a1e9dc283aedc4134846e0d7aafdc484f8263e250bR159-R162) - Wrap with doPrivileged in Lucene code. As far as I remember Lucene needs the permission anyways. With doPrivileged you would delegate responsibility. I'd open a JIRA issue, I can fix this. It only affects Lucene 9.0. > understand it it’s looking for a NAME static field on the class in question, > which > should always be public. I’m in the process of upgrading elasticsearch to use > a > lucene 9 snapshot, and this change means that I need to wrap SPI reloading > code in doPrivileged() blocks, which is a bit of a pain. Thansk for doing this. Is Elasticsearch now using the Analysis Factory framework instead of their own factories? > Thanks, Alan No problem, Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
