[
https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-409:
-------------------------------
Attachment: solr-350_409.patch
updated to fix typos noted by Walter;
added core name in logging operation where possible (Walter's suggestion);
moved startTime initialization of core after schema parsing (fast machine on
reload core was failing test...);
Unified patch from Solaris10 box -
created with: svn diff --diff-cmd /usr/local/bin/diff -x "-w -B -b -E -d -N
-u" > ~/solr-350_409.patch
applied with: /usr/local/bin/patch -u -p 0 < ~/solr-350_409.patch
> Allow configurable class loader sharing between cores
> -----------------------------------------------------
>
> Key: SOLR-409
> URL: https://issues.apache.org/jira/browse/SOLR-409
> Project: Solr
> Issue Type: Sub-task
> Affects Versions: 1.3
> Reporter: Henri Biestro
> Priority: Minor
> Fix For: 1.3
>
> Attachments: solr-350_409.patch, solr-350_409.patch,
> solr-350_409.patch, solr-350_409.patch, solr-350_409.patch,
> solr-350_409.patch, solr-350_409_414.patch, solr-409.patch, solr-409.patch
>
>
> WHAT:
> This patch allows to configure in the multicore.xml the parent class loader
> of all core class loaders used to dynamically create instances.
> WHY:
> Current behavior allocates one class loader per config & thus per core.
> However, there are cases where one would like different cores to share some
> objects that are dynamically instantiated (ie, where the class name is used
> to find the class through the class loader and instantiate). In the current
> form; since each core possesses its own class loader, static members are
> indeed different objects. For instance, there is no way of implementing a
> singleton shared between 2 request handlers.
> Originally from
> http://www.nabble.com/Post-SOLR215-SOLR350-singleton-issue-tf4776980.html
> HOW:
> The sharedLib attribute is extracted from the XML (multicore.xml)
> configuration file and parsed in the MultiCore load method. The directory
> path is used to create an URL class loader that will become the parent class
> loader of all core class loaders; since class resolution if performed on a
> parent-first basis, this allows sharing instances between different cores.
> STATUS:
> operational in conjunction with solr-350
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
