[
https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13693055#comment-13693055
]
Erick Erickson commented on SOLR-4948:
--------------------------------------
Alan:
first, I'm soooo glad you're tackling this and not me, but I'm a little jealous
that your hard work will actually live on and mine will be obsolete in 5.0
<G>....
Which of the various asserts in TestCoreContainer.testPersist fail? There are
several.... And are these with the latest patch? I have to go out for much of
today and I happen to be on California time so I won't be able to look at this
until probably after you've gone to sleep.
But here's the general rule, the instancedir that's persisted should be what
was originally specified when the core was created. So if I create a core with
a relative instancedir, what gets persisted should be a relative instance dir
and vice-versa. I'm not actually sure how all this gets handled when creating a
core from another core like happens in that test, I don't remember writing any
tests to cover this in the persistence tests I wrote lately. There are tests in
there to handle creating cores from the admin handler but not from a "template"
core.... It's entirely possible that we need to change the behavior in this
case.
Here's what I'd say (without actually looking). The persisted core should have
the same instancedir form as the template core's original definition did. But
you can't really tell this from core.getInstanceDir since that might substitute
sys vars and all that kind of thing. But we can just change the test based on
that principle...
So if the latest patch on this JIRA shows this behavior, I'll see if I can take
a whack at it later today.
> Tidy up CoreContainer construction logic
> ----------------------------------------
>
> Key: SOLR-4948
> URL: https://issues.apache.org/jira/browse/SOLR-4948
> Project: Solr
> Issue Type: Improvement
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Priority: Minor
> Attachments: SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch,
> SOLR-4948.patch
>
>
> While writing tests for SOLR-4914, I discovered that it's *really difficult*
> to create a CoreContainer. There are a bunch of constructors which
> initialise different things, one (but only one!) of which also loads all the
> cores. Then you have the Initializer object, which basically does the same
> thing. Sort of. And then the TestHarness doesn't actually use
> CoreContainer, but an anonymous subclass of CoreContainer which has it's own
> initialisation logic. It would be nice to clean this up!
--
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
