[infinispan-dev] Module configuration proposal

[Manik Surtani]

On 4 Nov 2009, at 14:04, Navin Surtani wrote:

>
> On 3 Nov 2009, at 18:24, Vladimir Blagojevic wrote:
>
>> On 09-11-03 12:59 PM, Galder Zamarreno wrote:
>>>
>>> On 11/03/2009 04:52 PM, Vladimir Blagojevic wrote:
>>>
>>>> Hey guys,
>>>>
>>>> I completed module configuration proposal Manik and I agreed  
>>>> upon. It is
>>>> very important to get this one right so I want to run it by you  
>>>> before
>>>> proceeding further!
>>>>
>>>> Have a look at [1] and follow proposed module configuration  
>>>> example below:
>>>>
>>>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xmlns="urn:infinispan:config:4.0">
>>>> <global>
>>>> <transport clusterName="demoCluster"/>
>>>> </global>
>>>>
>>>> <default>
>>>> <clustering mode="replication">
>>>> </clustering>
>>>> <modules>
>>>> <module name="query"
>>>> configClassName 
>>>> ="org.infinispan.query.config.QueryConfigurationBean">
>>>> <indexing enabled="true" indexLocalOnly="true"/>
>>>> </module>
>>>> </modules>
>>>> </default>
>>>> </infinispan>
>>>>
>>>> A few things to notice:
>>>>
>>>> a) Any configuration (including default and namedCache) can have a
>>>> module definition
>>>> b) Instance of configClassName is a rich object structure filled  
>>>> from
>>>> module's child XML content
>>>>
>>> I think configClassName should simply be 'class' as per the rest of
>>> situations where we're configuring FQCNs.
>>>
>>
>> Ok, makes sense!
>>>
>>>> c) Module's XML content can be arbitrary
>>>>
>>> So,<indexing enabled="true" indexLocalOnly="true"/>  is the XML  
>>> from the
>>> query module that the query module can read itself?
>>>
>>>
>> Yes, exactly. And it is read into object graph rooted in class  
>> specified
>> by configClassName.
>> XML unmarshalling into object graph is done by JAXB, just as we do it
>> elsewhere!
>
> I disagree. I could be wrong, but I think it's easiest if the  
> QueryConfigurationBean does the work of setting up stuff kind of  
> like how the QueryHelper [1] currently does. This way, if the query  
> module is to be used, once these configurations are registered the  
> appropriate interceptor can be added to the chain.

Actually, ISPN-245 will take care of this.  So you would write a hook  
into the lifecycle of the cache to take care of what the QueryHelper  
currently does (once ISPN-245 is complete and these hooks are  
available).

> Just a quick question on general Cache setup. Currently the  
> QueryInterceptor is added to chain after the locking interceptor.  
> Just wondering that if things are done this way, i.e. we create and  
> add the QueryInterceptor to the chain when a new instance of the  
> QueryConfigurationBean is created, is that going to cause problems  
> about where on the chain the QueryInterceptor sits? [Just thinking  
> out loud]

Irrelevant.  Configuration parsing happens before any interceptors or  
components are created.  Only after the entire cfg is parsed and the  
necessary cfg beans are available, the ComponentRegistry starts the  
process of creating components and wiring them together.  And at this  
point, the ComponentRegistry will call in to any available module hooks.

>> d) Custom module configuration bean is accessed by module name:
>>>>
>>>>
>>>>         Configuration def = c.parseDefaultConfiguration();
>>>>         ModuleConfigurationBean extensionConfig =
>>>> def.getModuleConfigurationBean("query");
>>>>         QueryConfigurationBean bean = (QueryConfigurationBean)
>>>> extensionConfig.getConfigurationBean();
>>>>         assert bean.isEnabled();
>>>>         assert bean.isIndexLocalOnly();
>>>>
>>>>
>
>
> </SNIP>
>
> [1] http://fisheye.jboss.org/browse/Infinispan/trunk/query/src/main/java/org/infinispan/query/backend/QueryHelper.java?r=trunk
>
> Navin Surtani
>
> Intern Infinispan
> Intern JBoss Cache Searchable
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20091104/0d5b7112/attachment-0002.html