[
https://issues.apache.org/jira/browse/SOLR-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tricia Jenkins updated SOLR-4536:
---------------------------------
Attachment: SOLR-4536.patch
I think I see what's happening now. As the comment in TestHarness states,
"Creates a container based on infos needed to create one core," the intention
appears to be to create a single core to test with specified schema,
solrconfig, etc. The assumption I was working under was that I could test one
(or more) of my cores in a multi-core setup with sharedLib using the
test-framework.
The SolrResourceLoader that h.getCore().getResourceLoader() references is the
one stored in the SolrConfig object. Resources are added from the
solrHome/coreName directory only. The SolrResourceLoader that contains the
'empty-file-main-lib.txt' in classes logged as added in my test is in the
CoreContainer (protected h.getCoreContainer().loader) object. Resources here
are added from the solrHome directory. This also explains why if I move the
sharedLib to a lib directory inside the core the resources are loaded and
available in the test framework.
Then again maybe I don't quite understand... if you look at the test in my
patch the SolrResourceLoader from the SolrCore/SolrConfig opens 'README' file
but not the 'classes/empty-file-main-lib.txt'. My understanding would mean
that it shouldn't be able to open either file.
Regardless, the items added to the classloader that appear in the logs are from
when the CoreContainer is initialized. The SolrResourceLoader that it used in
the test is a different object.
Is my understanding correct? Is my desire to test a core from a multi-core
setup with a sharedLib unreasonable?
If it's not unreasonable, I'm thinking of adding to SolrTestCase4J an
initCoreFromMultiCore( coreName, solrHome, 'solr.xml') method which would call
a new TestHarness constructor TestHarness(String coreName, String solrHome,
String multicoreConfig) which in turn would call container = new CoreContainer(
String, File) and hopefully be able to set all the important TestHarness fields
starting by using the container.getCore(String) method. The big thing that I'm
not sure about with this approach is how or if I would need to get around
TestHarness.Initializer/CoreContainer.Initializer.
> unable to access resources loaded from sharedLib in solr-test-framework
> ------------------------------------------------------------------------
>
> Key: SOLR-4536
> URL: https://issues.apache.org/jira/browse/SOLR-4536
> Project: Solr
> Issue Type: Bug
> Components: Tests
> Affects Versions: 4.2, 5.0
> Reporter: Tricia Jenkins
> Priority: Minor
> Labels: sharedLib, solr-test-framework
> Attachments: SOLR-4536.patch, SOLR-4536.patch
>
>
> Files (jars for me) from a sharedLib directory defined in solr.xml outside of
> the coreName's dataDir not being available to coreName's TestHarness despite
> it being logged as added to classpath.
> I don't see the 'sharedLib' tested anywhere else but it seems to work outside
> of the test-framework.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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
