[
https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945484#comment-16945484
]
Jan Høydahl commented on SOLR-13661:
------------------------------------
{quote}You seem to have very little understanding of how classloaders work.
Putting multiple classloaders together will result in classcastexceptions which
are impossible to debug
{quote}
Who says anything about putting class loaders together? PF4J and the POC also
has isolated class loaders per plugin bundle to achieve isolation. But my POC
uses a special "MultiPluginBundleClassLoader" in SolrResourceLoader, which is
consulted after lookup in WEB-INF/lib and SOLR_HOME/lib fails, and it hunts
through all installed plugins. It also works for looking up any resource on
class path.
I'm thus *not* talking about mashing all class loaders together, but when a
configSet declares that it uses e.g. {{<package>kuromoji</package>}} and you in
{{managed-schema}} declare {{<tokenizer
class="solr.JapaneseTokenizerFactory"/>}} then Solr would first lookup that
plugin class in core/global class loader, and when not found, it will look in
the "kuromoji" package where it will be found. You still have the isolation,
and any class loading performed by Kuromoji itself to load its dependencies are
handled by the isolated package class loader, so it won't use an incompatible
version of some dependency. It is just the first main plugin class lookup that
needs to resolve packages. And then we won't need a
{{class="kuromoji:solr.JapaneseTokenizerFactory"}} syntax in every possible
piece of the product that load classes or resources.
Another related question that I thought about in my POC but never got to test
thoroughly was SPI plugins. We use SPI for most Schema plugins, so in fact as
of SOLR-13593 you an now say {{<tokenizer name="japanese"/>}} or {{<filter
name="lowercase"/>}} in your schema instead of referring to class names. This
will look up the plugin through SPI. For this to work with the package system
you would either need to bolt on a special name syntax here, e.g.
"<package>:<name>" or let SPI find the class by also looking in the declared
packages.
> A package management system for Solr
> ------------------------------------
>
> Key: SOLR-13661
> URL: https://issues.apache.org/jira/browse/SOLR-13661
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Assignee: Ishan Chattopadhyaya
> Priority: Blocker
> Labels: package
> Attachments: plugin-usage.png, repos.png
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Here's the design doc:
> https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?usp=sharing
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
