ryantxu wrote:
>
> but I fear we are turning the initialization into a jumbled spaghetti of
> interface looparounds, callbacks and pending lists
> of soon-to-be-initialized stuff.
> (not just this patch - but the combination of requirements we have had for
> all the plugin stuff)
>
I agree thi
Henrib wrote:
Just pinging on the subject and the related solr-399 patch; I understand the
priority for this is low, just seeking some comment to determine whether
this is the expected track (and how low the priority is).
I started working on adding configuration to the search components in
S
ryantxu wrote:
>
> Is the patch ready for a serious review? or are you still working on it?
>
Not sure if this I'm supposed to answer but anyway, I was expecting comments
before 'generalizing' the patch. Right now, it only applies to filter &
tokenizer factories. The foundation should be soli
: dooh - I was hoping Chris may take this one up as he started the thread on
: changing the init method :)
:
: If this is not an issue for Chris, I can take a look sometime in the next few
sorry ... i didn't mean to suggest that i had a specific need to change
the method ... i was approaching i
Chris Hostetter wrote:
: Just pinging on the subject and the related solr-399 patch; I understand the
: priority for this is low, just seeking some comment to determine whether
: this is the expected track (and how low the priority is).
It's in my mailbox of things to look at but there are
: Just pinging on the subject and the related solr-399 patch; I understand the
: priority for this is low, just seeking some comment to determine whether
: this is the expected track (and how low the priority is).
It's in my mailbox of things to look at but there are things on that
list fro
Just pinging on the subject and the related solr-399 patch; I understand the
priority for this is low, just seeking some comment to determine whether
this is the expected track (and how low the priority is).
--
View this message in context:
http://www.nabble.com/SolrConfig.Initializable-tf46650
Updated the patch which is now functional (solr-399).
--
View this message in context:
http://www.nabble.com/SolrConfig.Initializable-tf4665036.html#a13470794
Sent from the Solr - Dev mailing list archive at Nabble.com.
I took the liberty of creating solr-399 to track this (and allow posting a
patch).
hossman wrote:
>
>
> The SolrConfig.Initializable interface was introduced as part of SOLR-215
> to give Token(izer|Filter)Factories access to the SolrConfig (i believe
> just because StopFilter and SynonymFi
: On the functional side, it might be beneficial to keep the newInstance as is
: but introduce an initInstance.
: We might want instances to be initialized with some of their current
: arguments before we set the core.
that was kind of my main point ... i just got sidetracked by the sexiness
of
: Interesting, instances of SolrCoreAware would be queued up until the config is
: told what the core is - afterwards it tells them immediately. I like that.
that's what i was thinking, but i'm actually not fond of that idea ... it
seemed sexy to keep things that simple, so that the same code wo
On the functional side, it might be beneficial to keep the newInstance as is
but introduce an initInstance.
We might want instances to be initialized with some of their current
arguments before we set the core.
This way, we may unify all plugin & factory like functionality under one
hood; the sequ
HH... even better, SolrConfig could be changed to implement
SolrCoreAware, and all of the hard work could be implmented with the
addition below to SolrConfig (and all SolrCore has to do is call
solrConfig.tellAboutCore(this)) ...
private List needToTell = new List()
private Sol
Ah, yes the concern is about ... the use use of SolrCore in plugin init
methods before the SolrCore itself is fully initialized.
: We could either add a status to the core and have each high-level core
: method check this status before running (which would also allow to have
: cores logically st
I agree that the core being accessible whilst not being fully initialized is
not very "comfortable".
We could either add a status to the core and have each high-level core
method check this status before running (which would also allow to have
cores logically stopped -or marked under reload/backup
I can't help but wonder if it would make more sense to replace this with
something like "SolrCore.Initializable" ... you can get a SolrConfig from
a SolrCore, but you can't get a SolrCore from a SolrConfig.
yes, that sounds like a good idea.
The one (potential) issue is that the core may not b
I dont see any wrong or bad reason for the change since I believe we never
share an object created by one core (and dependant on it) with another core
- and we probably shouldn't.
At some point, solr-215 was passing the SolrCore to dynamically created
objects instead of the SolrConfig in init. T
17 matches
Mail list logo
