lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <ear...@gmail.com>
Subject Re: IndexReader plugins
Date Tue, 14 Apr 2009 20:35:41 GMT
On Wed, Apr 15, 2009 at 00:15, Mark Miller <markrmiller@gmail.com> 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".
So far we discussed per-reader component instances (I can't force
myself to call them singletons), with lifecycle callbacks. These
instances also serve as a factory for instances attached to
subreaders.

-- 
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message