9:18 a.m.
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(a)redhat.com>
To: "infinispan -Dev List"<infinispan-dev(a)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(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