[infinispan-dev] Module configuration proposal

Manik Surtani manik at jboss.org
Tue Nov 10 13:11:47 EST 2009 

On 10 Nov 2009, at 17:18, Vladimir Blagojevic wrote:

> Ok then. No one is stepping up to argue either way so lets proceed in 
> direction you propose. I can scrap ISPN-193 in a day or so and prepare 
> Configuration to accept <indexing> tag for query. Do you want to squeeze 
> this one in CR2? We can leave things as they are with no impact on 
> current configuration files people already use out there and then 
> proceed after CR2. What do you think?

It will take me at least another day to prepare for CR2.  If you have time to do this today/tomorrow I reckon you should go ahead and lets get this in CR2.  :)

Cheers
Manik

> On 09-11-09 12:09 PM, Manik Surtani wrote:
>> 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
>>> 
>> _______________________________________________
>> 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

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

More information about the infinispan-dev mailing list