[
https://issues.apache.org/jira/browse/SOLR-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542103#comment-17542103
]
Gus Heck commented on SOLR-16203:
---------------------------------
Dagger2 looks interesting, but I don't see (at a very quick glance) any
discussion on their site of javax vs jakarta. Java EE moved to eclipse
foundation and they didn't get to keep javax namespace... javax.inject is the
old namespace and will not be maintained. So adopting something that handles
the jakarta.inject name spaced classes (or used neither) would be better. This
is influenced by what jetty we are on, because Jetty 11 is are already on
jakarta specs, so there's a major hiccup if we pick something that works in
jetty 9 and the move to jetty 11... Note: I have not checked if the current
jetty dependeny actually brings in any inject dependencies right now... but
this transition is something to watch out for.
> Using SPI lookups of analysis components results in factories that don't get
> ResourceLoaderAware.inform called on them (When using
> ClassicIndexSchemaFactory)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-16203
> URL: https://issues.apache.org/jira/browse/SOLR-16203
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 9.0
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-16203_test.patch
>
>
> Ok ... this is a weird one ...
> SOLR-13593 modified {{FieldTypePluginLoader}} to add the ability for analysis
> Factories to be resolved by SPI name (ex: {{{}name="stop"{}}}, instead of by
> "short class name" (ex: {{{}class="solr.StopFilterFactory"{}}}.
> The code that deals with this just calls (for example)
> {{TokenFilterFactory.forName(name, params);}} and uses the resulting factory
> "as is" – But these means that nothing calls the {{inform(ResourceLoader)}}
> on any factories that implement {{ResourceLoaderAware}} (such as
> {{StopFilterFactory}} or {{{}SynonymGraphFilterFactory{}}})
> In the "short class name" code path (the only option prior to 9.0), the
> {{SolrResourceLoader}} is used to initialize the Factory, and
> {{SolrResourceLoader..newInstance(...)}} takes responsibility of calling
> {{factory.inform(this)}} on everything it instantiates that implements
> {{ResourceLoaderAware}} (as well as some other checks: like
> {{{}SolrCoreAware{}}})
> This discrepancy means that when using the {{name="foo"}} syntax, many
> factories won't be fully initialized – or fail on invalid input – during
> schema initialization. In the case of things like {{StopFilterFactory}} or
> {{SynonymGraphFilterFactory}}) the problem will manifest as some type of
> runtime error when the factory's {{create(...)}} method is called as part of
> creating a new index or query Analyzer.
> ----
> _*...BUT...*_
> ----
> This problem only seems to manifest itself when using
> {{ClassicIndexSchemaFactory}} -- which is why it's not readily apparent when
> using the default configset, or something like {{bin/solr -e techproducts}}
> (but is trivial to reproduce in testcases (since almost every "test"
> solrconfig uses {{ClassicIndexSchemaFactory}})
> I have no idea _why_ using {{ManagedIndexSchemaFactory}} doesn't manifest the
> same problem -- it should be using the same {{FieldTypePluginLoader}} under
> the covers -- but clearly something specific to {{ManagedIndexSchema}} is
> taking responsibility for calling {{ResourceLoaderAware.inform(...)}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
