[
https://issues.apache.org/jira/browse/LUCENE-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423144#comment-13423144
]
Uwe Schindler commented on LUCENE-4259:
---------------------------------------
Thanks for comment:
bq. I think solr should reload postingsformats first, then codecs? Some codecs
might call
PostingsFormat.forName in their ctor (Lucene40Codec does this, we should remove
it, its stupid).
Yes, I change that. In ym opinion we might add a utility method somewhere in
Lucene Core to do it in correct order. I know the problems of the order of
init: Codec.class itsself inits defaultCodec with forName(), which is fine as
same class, but cross-calling forName on init is not good. At the end it can to
chicken-egg bugls like in ICU4J
bq. Should the analysis loader be changed to work just like this? It would
simplify things in my opinion.
I was thinking about that. I will change the AnalysisSPILoader to support
reloading and the abtsract Factories to support this, too - so its useable by
3rd party projects.
For Solr, the current solution is much better and safe, especially with class
unloading. The problem with codecs is not solveable in a different way, because
we need the static Codec.forName() for the internals of Lucene to work, so we
have to *modify* the static instance (singleton) to reload itsself. For
analysis, we dont need this (as inside Solr, only Solr's code who owns the
AnalysisSPILoader will instantiate tokenizers) and the ResourceLoader approach
we currently use is much cleaner and allows the ClassLoader to be released if
you shutdown Solr.
> Allow reloading of codec/postings format list when classpath changes
> --------------------------------------------------------------------
>
> Key: LUCENE-4259
> URL: https://issues.apache.org/jira/browse/LUCENE-4259
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: 4.0-ALPHA
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4259.patch
>
>
> While implementing the SPI for analysis factories, Robert and me found out
> that Solr does not see codecs/postingsformats or analysis factories outside
> it's webapp/lib folder. The reason is simple: SPI uses by default the context
> classloader of the thread calling the codec API for the first time (which is
> Jetty's webapp classpath).
> We solved the problem for analysis factories, because those are loaded with
> the help of SolrResourceLoader, which exports the ClassLoader it uses, so it
> can return all analysis compoenst visible to the ResourceLoader. This is
> cool, because you can drop the analysis/smartchinese or analysis/icu module
> JAR into your plugin folder and Solr will automatically use it.
> For Codecs and PostingsFormats this is a little bit more complicated: The
> list of codecs is loaded on clinit of Codecs.class or PostingsFormat.class,
> which can be very early in Solr's startup. When Solr changes his classpath in
> ResourceLoader, the new Codecs are never seen, so you cannot drop new codecs
> into the plugin folder. Similar problems may happen with other webapps,
> because Tomcat & Jetty have crazy classloader delegations (there were
> although reports that Lucene did not find their codecs at all - Simon
> Willnauer told me!)
> This patch will change NamedSPILoader to provide similar support like
> java.util.ServiceLoader does in JDK: You can tell NamedSPILoader to reload
> (means again list the classpath's JAR files and look for new
> META-INF/services files). This API is statically exported to
> Codec.reloadCodecs() and PostingsFormat.reploadPostingsFormats(), which takes
> a ClassLoader. This Classloader will then be checked only for *new* codecs,
> old ones or those already visible are not removed/replaced.
> SolrResourceLoader can then call this static method on each change of its
> classloader on startup.
> The implementation presented here is threadsafe, the SPI map is updated in a
> copy-on-write way and assigned to a volatile field.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
