[infinispan-dev] Module configuration proposal

[Vladimir Blagojevic]

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.

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
>