Re: [infinispan-dev] Module configuration proposal

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&quot;&lt;vblagoje(a)redhat.com&gt; > To: "infinispan -Dev List&quot;&lt;infinispan-dev(a)lists.jboss.org&gt; > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev