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