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:15:17 GMT
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?

- Mark

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

View raw message