[infinispan-dev] Module configuration proposal

Galder Zamarreno galder at redhat.com
Thu Nov 12 12:30:07 EST 2009



On 11/09/2009 04:18 PM, Vladimir Blagojevic wrote:
> Manik,
>
> No worries about the time I spent on ISPN-193. It was a challenge and
> enjoyment to figure out how to do this and if it is included or not I am
> not that concerned. I did not understand that ISPN-193 is targeted to
> our modules only. I thought that this feature leaves a door open to
> third party modules as well.
>
>
> What I am concerned is that:
>
> <infinispan>
> <namedCache name="blah">
> <modules>
> <module name="query"/>
> </modules>
> </>
> </>
>
> IMO looks simpler to end user than:
>
> <infinispan>
>     <namedCache name="blah">
>       <indexing enabled="true" localOnly="false" />
>     </>
> </>
>
> And don't forget that we can have more complex xml structure as well.<indexing>   is a skewed example:)
>
>
> Also, are you looking over module versioning? If we are always going to sync release of all modules along with core module, then it is fine. Otherwise, there will be a lot of changes to schema, each module will want to tune main Configuration bean, multiply that by number of different module releses, it is a mess! If you leave a module jar to define it own configuration bean and ship configuration along with it, it would mean that end user would simply drop a module jar on a classpath.

I think modules within Infinispan will be released at the same time. 
They share the same versioning AFAIK.

>
> As Manik already asked, I am also asking everyone else, thoughts ? :)
>
>
>
>
>
> On 09-11-09 6:41 AM, Manik Surtani wrote:
>> Hmm, I don't know.  The whole purpose behind this was to simplify our inter-module dependencies on config beans, etc.  And if simplifying means pushing more complexity on to the end user, then that's not good.  I'd rather have inter-dependencies and complexity in our codebase and a simple end-user experience than the other way around.
>>
>> I suppose the alternative is that every time a module requires some cfg params, we modify the Configuration bean in core to accommodate this.  So this will add *some* knowledge of the modules in core (only from a configuration perspective) but at least it would keep the end-user experience clean.  So in the case of querying, something like:
>>
>> Configuration.setIndexingEnabled(), Configuration.setIndexLocalOnly() and this would give us a config file that looks like the following?
>>
>> <infinispan>
>>     <namedCache name="blah">
>>       <indexing enabled="true" localOnly="false" />
>>     </>
>> </>
>>
>> If that is the case then this would mean we don't bother with ISPN-193 - sorry, I know you did put effort into investigating this :( - but we would still need ISPN-245.
>>
>> Thoughts?
>>
>> Cheers
>> Manik
>>
>>
>> ----- Original Message -----
>> From: "Vladimir Blagojevic"<vblagoje at redhat.com>
>> To: "infinispan -Dev List"<infinispan-dev at lists.jboss.org>
>> Sent: Sunday, 8 November, 2009 20:29:27 GMT +00:00 GMT Britain, Ireland, Portugal
>> Subject: Re: [infinispan-dev] Module configuration proposal
>>
>> I do understand that sentiment - not wanting to overwhelm end user with
>> complex configuration file. How about we make a trade off. Module
>> develop can specify default configuration bean setup in module.cfg (XML
>> format), end user just references that module in cache.xml. End user, of
>> course, has an option to change or overrride configuration in that
>> module.cfg file package by either modifying it inside module jar or by
>> specifying configuration directly in cache.xml as we have it now.
>>
>> <infinispan>
>> <namedCache name="blah">
>> <modules>
>> <module name="query"/>
>> </modules>
>> </>
>> </>
>>
>>
>>
>>
>> On 09-11-08 11:04 AM, Manik Surtani wrote:
>>
>>> Hmm - lets have a think about this.  Can't say I like having the<module>    tag exposed to end users.
>>>
>>> So I guess the alternative is to have module-specific config beans in the core module?  E.g., move the QueryConfiguration to the core package, and then we could have something like the following?
>>>
>>>
>>>
>>>> <infinispan>
>>>> <namedCache name="blah">
>>>> <indexing enabled="true" localOnly="false" />
>>>> </>
>>>> </>
>>>>
>>>>
>>> Cheers
>>> Manik
>>>
>>>
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache



More information about the infinispan-dev mailing list