lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: IndexReader plugins
Date Tue, 14 Apr 2009 20:55:52 GMT
Earwin Burrfoot wrote:
> On Wed, Apr 15, 2009 at 00:15, Mark Miller <> wrote:
>> Mark Miller wrote:
>>> Earwin Burrfoot wrote:
>>>> Mark Miller wrote:
>>>>> The distinction I am making with core is that we will have to call known
>>>>> methods on those
>>>>> core 'modules' that are not very generic? Doesn't that keep it from
>>>>> playing
>>>>> nice with the very generic 'attach this to this segment'?
>>>> Genericity spans binding, notifications and retrieval of a component
>>>> from a reader.
>>>> For binding and notifications you can do whatever you want inside your
>>>> component, because you're provided with the full public IndexReader
>>>> interface.
>>>> When you retrieve a component, you get your very own interface with
>>>> all your needed and totally nongeneric methods.
>>>> ObscureComponent c = reader.plugin(ObscureComponent.class);
>>>> c.performSomeObscureNonGenericLogic();
>>>> This very code can be located both in userland, dealing with custom
>>>> components and in coreland, dealing with well-known Lucene core
>>>> components.
>>> Thats sounding interesting. From what you and Mike are saying, its a
>>> dependency injection framework basically then? Impls are plugged in from a
>>> configuration class? Except you can plug in your own random stuff thats not
>>> used internally, so its also kind of an Impl cache?
>>> So IndexReader Plugins would be: per Reader impl configuration and caching
>>> - with call backs too though - I guess you could add other callbacks and get
>>> involved in some more interesting stuff as well, if you wanted?
>>> It keeps growing on me anyway.
>> Or its per Reader dependency injection with singleton support only and
>> support for lifecycle callbacks?
> I'm not really going to inject dependencies, so it's more like
> "service locator" than "dependency injection".
I don't see the distinction really - unless your saying its that a 
service locator may be happy ignoring a missing implementation. From the 
core modules perspective, it seems more like straight dependency 
injection to me.
> So far we discussed per-reader component instances (I can't force
> myself to call them singletons)
Right - I don't mean to just call them singletons, it was just part of 
the analogy. In dependency injection you generally have the option of 
getting fresh instances or a singleton. In that way, I was comparing it 
to a per reader dependency injection framework set to singleton rather 
than new instance. Its not *really* a singleton, because its per reader.

> , with lifecycle callbacks. These
> instances also serve as a factory for instances attached to
> subreaders.
I don't quite understand that. Do you mean, back to my confusing 
analogy, that we will have both per reader singletons, as well as the 
option to ask for new instances then?

LuceneGuice :)  (Thats completely a throwaway, so don't draw any 
conclusions from it :))

- Mark

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message