...the only thing slightly non-standard about calling these methods
"setters" is that they aren't expected to jsut be "POJO" style setters ...
the expectation is that the class will do some work when they are called
-- hence my "tell" (or maybe "notify" or "inform" is a better verb)
suggestion.
Using the terms "aware" and "inform" makes it all sit better with me.
That makes a clean init path
1. call init( existing args )
2. For each XXXAware impl, call call informXXX( )
for now XXX is SolrCore and ResourceLoader (ClassLoader stuff refactored
out of Config)
: To sum up, I see two directions:
:
: 1. Keep existing init() apis. Add more init() functions that pass in SolrCore
: or a ResourceFinder.
:
: 2. Keep existing init() apis, but advertise they will change in the future.
: As a stop-gap measure make the parameters that will be available in the future
: available through ThreadLocal. (SOLR-414)
:
: I vote for #2 because after the 2.0 release, we will have a clean API with all
: init options available in a single place. I am ok with #1 also.
i vote for #1, but as i said: the new methods shouldn't be named "init"
since that will clearly confuse people about the semantics. this also has
the nice property that 1 year from now when we decide there's another
(new) important object we'd like plugins to have access to (if they want
it) before they are asked to do work we don't have to jump through all the
hoops of changing the init() signature again.
I change my vote to #1 -- I will modify SOLR-414 to take this strategy
ryan
