[infinispan-dev] Module configuration proposal

[Manik Surtani]

Modules and core will always be released in lock-step. The only reason  
modules exist is for code convenience. Even the distro packages a  
single archive with the lot and modules will never be released  
independently.

Sent from my iPhone

On 9 Nov 2009, at 15:19, Vladimir Blagojevic <vblagoje at redhat.com>  
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.
>
> 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