4:52 p.m.
Hey guys,
I completed module configuration proposal Manik and I agreed upon. It is
very important to get this one right so I want to run it by you before
proceeding further!
Have a look at [1] and follow proposed module configuration example below:
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:infinispan:config:4.0">
<global>
<transport clusterName="demoCluster"/>
</global>
<default>
<clustering mode="replication">
</clustering>
<modules>
<module name="query"
configClassName="org.infinispan.query.config.QueryConfigurationBean">
<indexing enabled="true" indexLocalOnly="true"/>
</module>
</modules>
</default>
</infinispan>
A few things to notice:
a) Any configuration (including default and namedCache) can have a
module definition
b) Instance of configClassName is a rich object structure filled from
module's child XML content
c) Module's XML content can be arbitrary
d) Custom module configuration bean is accessed by module name:
Configuration def = c.parseDefaultConfiguration();
ModuleConfigurationBean extensionConfig =
def.getModuleConfigurationBean("query");
QueryConfigurationBean bean = (QueryConfigurationBean)
extensionConfig.getConfigurationBean();
assert bean.isEnabled();
assert bean.isIndexLocalOnly();
The proposal achieves full flexibility when it comes to having rich
object configuration structure that modules define themselves.
Furthermore, core module is completely isolated from module
configuration extensions. Schema easily accommodates this model and
there is no adverse effect on performance!
[1] https://jira.jboss.org/jira/browse/ISPN-193
6:59 p.m.
On 11/03/2009 04:52 PM, Vladimir Blagojevic wrote:
Hey guys,
I completed module configuration proposal Manik and I agreed upon. It is
very important to get this one right so I want to run it by you before
proceeding further!
Have a look at [1] and follow proposed module configuration example below:
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:infinispan:config:4.0">
<global>
<transport clusterName="demoCluster"/>
</global>
<default>
<clustering mode="replication">
</clustering>
<modules>
<module name="query"
configClassName="org.infinispan.query.config.QueryConfigurationBean">
<indexing enabled="true" indexLocalOnly="true"/>
</module>
</modules>
</default>
</infinispan>
A few things to notice:
a) Any configuration (including default and namedCache) can have a
module definition
b) Instance of configClassName is a rich object structure filled from
module's child XML content
I think configClassName should simply be 'class' as per the rest of
situations where we're configuring FQCNs.
c) Module's XML content can be arbitrary
So, <indexing enabled="true" indexLocalOnly="true"/> is the XML
from the
query module that the query module can read itself?
d) Custom module configuration bean is accessed by module name:
Configuration def = c.parseDefaultConfiguration();
ModuleConfigurationBean extensionConfig =
def.getModuleConfigurationBean("query");
QueryConfigurationBean bean = (QueryConfigurationBean)
extensionConfig.getConfigurationBean();
assert bean.isEnabled();
assert bean.isIndexLocalOnly();
The proposal achieves full flexibility when it comes to having rich
object configuration structure that modules define themselves.
Furthermore, core module is completely isolated from module
configuration extensions. Schema easily accommodates this model and
there is no adverse effect on performance!
Nice work!
[1] https://jira.jboss.org/jira/browse/ISPN-193
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
7:24 p.m.
On 09-11-03 12:59 PM, Galder Zamarreno wrote:
On 11/03/2009 04:52 PM, Vladimir Blagojevic wrote:
> Hey guys,
>
> I completed module configuration proposal Manik and I agreed upon. It is
> very important to get this one right so I want to run it by you before
> proceeding further!
>
> Have a look at [1] and follow proposed module configuration example below:
>
> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:infinispan:config:4.0">
> <global>
> <transport clusterName="demoCluster"/>
> </global>
>
> <default>
> <clustering mode="replication">
> </clustering>
> <modules>
> <module name="query"
> configClassName="org.infinispan.query.config.QueryConfigurationBean">
> <indexing enabled="true" indexLocalOnly="true"/>
> </module>
> </modules>
> </default>
> </infinispan>
>
> A few things to notice:
>
> a) Any configuration (including default and namedCache) can have a
> module definition
> b) Instance of configClassName is a rich object structure filled from
> module's child XML content
>
I think configClassName should simply be 'class' as per the rest of
situations where we're configuring FQCNs.
Ok, makes sense!
> c) Module's XML content can be arbitrary
>
So,<indexing enabled="true" indexLocalOnly="true"/> is the XML
from the
query module that the query module can read itself?
Yes, exactly. And it is read into object graph rooted in class specified
by configClassName.
XML unmarshalling into object graph is done by JAXB, just as we do it
elsewhere!
> d) Custom module configuration bean is accessed by module name:
>
>
> Configuration def = c.parseDefaultConfiguration();
> ModuleConfigurationBean extensionConfig =
> def.getModuleConfigurationBean("query");
> QueryConfigurationBean bean = (QueryConfigurationBean)
> extensionConfig.getConfigurationBean();
> assert bean.isEnabled();
> assert bean.isIndexLocalOnly();
>
>
> The proposal achieves full flexibility when it comes to having rich
> object configuration structure that modules define themselves.
> Furthermore, core module is completely isolated from module
> configuration extensions. Schema easily accommodates this model and
> there is no adverse effect on performance!
>
Nice work!
>
> [1] https://jira.jboss.org/jira/browse/ISPN-193
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
3:04 p.m.
On 3 Nov 2009, at 18:24, Vladimir Blagojevic wrote:
On 09-11-03 12:59 PM, Galder Zamarreno wrote:
>
> On 11/03/2009 04:52 PM, Vladimir Blagojevic wrote:
>
>> Hey guys,
>>
>> I completed module configuration proposal Manik and I agreed upon.
>> It is
>> very important to get this one right so I want to run it by you
>> before
>> proceeding further!
>>
>> Have a look at [1] and follow proposed module configuration
>> example below:
>>
>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns="urn:infinispan:config:4.0">
>> <global>
>> <transport clusterName="demoCluster"/>
>> </global>
>>
>> <default>
>> <clustering mode="replication">
>> </clustering>
>> <modules>
>> <module name="query"
>> configClassName
>> ="org.infinispan.query.config.QueryConfigurationBean">
>> <indexing enabled="true" indexLocalOnly="true"/>
>> </module>
>> </modules>
>> </default>
>> </infinispan>
>>
>> A few things to notice:
>>
>> a) Any configuration (including default and namedCache) can have a
>> module definition
>> b) Instance of configClassName is a rich object structure filled
>> from
>> module's child XML content
>>
> I think configClassName should simply be 'class' as per the rest of
> situations where we're configuring FQCNs.
>
Ok, makes sense!
>
>> c) Module's XML content can be arbitrary
>>
> So,<indexing enabled="true" indexLocalOnly="true"/> is the
XML
> from the
> query module that the query module can read itself?
>
>
Yes, exactly. And it is read into object graph rooted in class
specified
by configClassName.
XML unmarshalling into object graph is done by JAXB, just as we do it
elsewhere!
I disagree. I could be wrong, but I think it's easiest if the
QueryConfigurationBean does the work of setting up stuff kind of like
how the QueryHelper [1] currently does. This way, if the query module
is to be used, once these configurations are registered the
appropriate interceptor can be added to the chain.
Just a quick question on general Cache setup. Currently the
QueryInterceptor is added to chain after the locking interceptor. Just
wondering that if things are done this way, i.e. we create and add the
QueryInterceptor to the chain when a new instance of the
QueryConfigurationBean is created, is that going to cause problems
about where on the chain the QueryInterceptor sits? [Just thinking out
loud]
>> d) Custom module configuration bean is accessed by module name:
>>
>>
>> Configuration def = c.parseDefaultConfiguration();
>> ModuleConfigurationBean extensionConfig =
>> def.getModuleConfigurationBean("query");
>> QueryConfigurationBean bean = (QueryConfigurationBean)
>> extensionConfig.getConfigurationBean();
>> assert bean.isEnabled();
>> assert bean.isIndexLocalOnly();
>>
>>
</SNIP>
[1]
http://fisheye.jboss.org/browse/Infinispan/trunk/query/src/main/java/org/...
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable
4:15 p.m.
These are completely orthogonal issues (configuration and setup). Module
configuration bean loads configuration from XML into object tree and
does nothing else! Cache factory, component registry and such should
allow module developers an easy way to additionally setup created cache
given a configuration.
I am not sure if we have such API but if not we need to. Anyone?
On 09-11-04 9:04 AM, Navin Surtani wrote:
I disagree. I could be wrong, but I think it's easiest if the
QueryConfigurationBean does the work of setting up stuff kind of like
how the QueryHelper [1] currently does. This way, if the query module
is to be used, once these configurations are registered the
appropriate interceptor can be added to the chain.
Just a quick question on general Cache setup. Currently the
QueryInterceptor is added to chain /after/ the locking interceptor.
Just wondering that if things are done this way, i.e. we create and
add the QueryInterceptor to the chain when a new instance of the
QueryConfigurationBean is created, is that going to cause problems
about where on the chain the QueryInterceptor sits? [Just thinking out
loud]
[1]
http://fisheye.jboss.org/browse/Infinispan/trunk/query/src/main/java/org/...
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:19 p.m.
On 4 Nov 2009, at 15:15, Vladimir Blagojevic wrote:
These are completely orthogonal issues (configuration and setup).
Module configuration bean loads configuration from XML into object
tree and does nothing else! Cache factory, component registry and
such should allow module developers an easy way to additionally
setup created cache given a configuration.
I am not sure if we have such API but if not we need to. Anyone?
Yes, configuration and setup are different. ISPN-193 only handles
configuration. For setup, see ISPN-245 [1]
[1] https://jira.jboss.org/jira/browse/ISPN-245
On 09-11-04 9:04 AM, Navin Surtani wrote:
>
>
>
> I disagree. I could be wrong, but I think it's easiest if the
> QueryConfigurationBean does the work of setting up stuff kind of
> like how the QueryHelper [1] currently does. This way, if the query
> module is to be used, once these configurations are registered the
> appropriate interceptor can be added to the chain.
>
> Just a quick question on general Cache setup. Currently the
> QueryInterceptor is added to chain after the locking interceptor.
> Just wondering that if things are done this way, i.e. we create and
> add the QueryInterceptor to the chain when a new instance of the
> QueryConfigurationBean is created, is that going to cause problems
> about where on the chain the QueryInterceptor sits? [Just thinking
> out loud]
>
>
> [1]
http://fisheye.jboss.org/browse/Infinispan/trunk/query/src/main/java/org/...
>
> Navin Surtani
>
> Intern Infinispan
> Intern JBoss Cache Searchable
>
>
> _______________________________________________
> 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
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
6:23 p.m.
On 4 Nov 2009, at 14:04, Navin Surtani wrote:
On 3 Nov 2009, at 18:24, Vladimir Blagojevic wrote:
> On 09-11-03 12:59 PM, Galder Zamarreno wrote:
>>
>> On 11/03/2009 04:52 PM, Vladimir Blagojevic wrote:
>>
>>> Hey guys,
>>>
>>> I completed module configuration proposal Manik and I agreed
>>> upon. It is
>>> very important to get this one right so I want to run it by you
>>> before
>>> proceeding further!
>>>
>>> Have a look at [1] and follow proposed module configuration
>>> example below:
>>>
>>> <infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns="urn:infinispan:config:4.0">
>>> <global>
>>> <transport clusterName="demoCluster"/>
>>> </global>
>>>
>>> <default>
>>> <clustering mode="replication">
>>> </clustering>
>>> <modules>
>>> <module name="query"
>>> configClassName
>>> ="org.infinispan.query.config.QueryConfigurationBean">
>>> <indexing enabled="true" indexLocalOnly="true"/>
>>> </module>
>>> </modules>
>>> </default>
>>> </infinispan>
>>>
>>> A few things to notice:
>>>
>>> a) Any configuration (including default and namedCache) can have a
>>> module definition
>>> b) Instance of configClassName is a rich object structure filled
>>> from
>>> module's child XML content
>>>
>> I think configClassName should simply be 'class' as per the rest of
>> situations where we're configuring FQCNs.
>>
>
> Ok, makes sense!
>>
>>> c) Module's XML content can be arbitrary
>>>
>> So,<indexing enabled="true" indexLocalOnly="true"/> is
the XML
>> from the
>> query module that the query module can read itself?
>>
>>
> Yes, exactly. And it is read into object graph rooted in class
> specified
> by configClassName.
> XML unmarshalling into object graph is done by JAXB, just as we do it
> elsewhere!
I disagree. I could be wrong, but I think it's easiest if the
QueryConfigurationBean does the work of setting up stuff kind of
like how the QueryHelper [1] currently does. This way, if the query
module is to be used, once these configurations are registered the
appropriate interceptor can be added to the chain.
Actually, ISPN-245 will take care of this. So you would write a hook
into the lifecycle of the cache to take care of what the QueryHelper
currently does (once ISPN-245 is complete and these hooks are
available).
Just a quick question on general Cache setup. Currently the
QueryInterceptor is added to chain after the locking interceptor.
Just wondering that if things are done this way, i.e. we create and
add the QueryInterceptor to the chain when a new instance of the
QueryConfigurationBean is created, is that going to cause problems
about where on the chain the QueryInterceptor sits? [Just thinking
out loud]
Irrelevant. Configuration parsing happens before any interceptors or
components are created. Only after the entire cfg is parsed and the
necessary cfg beans are available, the ComponentRegistry starts the
process of creating components and wiring them together. And at this
point, the ComponentRegistry will call in to any available module hooks.
> d) Custom module configuration bean is accessed by module name:
>>>
>>>
>>> Configuration def = c.parseDefaultConfiguration();
>>> ModuleConfigurationBean extensionConfig =
>>> def.getModuleConfigurationBean("query");
>>> QueryConfigurationBean bean = (QueryConfigurationBean)
>>> extensionConfig.getConfigurationBean();
>>> assert bean.isEnabled();
>>> assert bean.isIndexLocalOnly();
>>>
>>>
</SNIP>
[1]
http://fisheye.jboss.org/browse/Infinispan/trunk/query/src/main/java/org/...
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
6:27 p.m.
Nice work! Is there any way to register the module beans in code so
they don't appear in XML (which is exposed to users)? Perhaps
something like:
In core:
* look thru classpath for all instances of "infinispan-module-
cfg.properties"
* this file would contain infinispan.module.cfg-
beans=org.infinispan.query.config.QueryConfigurationBean,
org.infinispan.query.config.QueryConfigurationBean2,
org.infinispan.query.config.QueryConfigurationBean3, etc
in any given module:
* must package a "infinispan-module-cfg.properties" if it wants to
hook in to the XML cfg parsing system
* delcare any cfg beans in this file, as infinispan.module.cfg-
beans=org.infinispan.query.config.QueryConfigurationBean,
org.infinispan.query.config.QueryConfigurationBean2,
org.infinispan.query.config.QueryConfigurationBean3, etc
WDYT?
On 3 Nov 2009, at 15:52, Vladimir Blagojevic wrote:
Hey guys,
I completed module configuration proposal Manik and I agreed upon.
It is
very important to get this one right so I want to run it by you before
proceeding further!
Have a look at [1] and follow proposed module configuration example
below:
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:infinispan:config:4.0">
<global>
<transport clusterName="demoCluster"/>
</global>
<default>
<clustering mode="replication">
</clustering>
<modules>
<module name="query"
configClassName="org.infinispan.query.config.QueryConfigurationBean">
<indexing enabled="true" indexLocalOnly="true"/>
</module>
</modules>
</default>
</infinispan>
A few things to notice:
a) Any configuration (including default and namedCache) can have a
module definition
b) Instance of configClassName is a rich object structure filled from
module's child XML content
c) Module's XML content can be arbitrary
d) Custom module configuration bean is accessed by module name:
Configuration def = c.parseDefaultConfiguration();
ModuleConfigurationBean extensionConfig =
def.getModuleConfigurationBean("query");
QueryConfigurationBean bean = (QueryConfigurationBean)
extensionConfig.getConfigurationBean();
assert bean.isEnabled();
assert bean.isIndexLocalOnly();
The proposal achieves full flexibility when it comes to having rich
object configuration structure that modules define themselves.
Furthermore, core module is completely isolated from module
configuration extensions. Schema easily accommodates this model and
there is no adverse effect on performance!
[1] https://jira.jboss.org/jira/browse/ISPN-193
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
6:56 p.m.
Ok, I see where you are going. This is along the line with
https://jira.jboss.org/jira/browse/ISPN-245. No problem, even better.
Also there is no need to declare all configurations beans, only the root
class of configuration, jaxb will resolve others, as long as they are on
classpath.
How do we proceed from here? I can take over ISPN-245 as well, looks
interesting...
On 09-11-04 12:27 PM, Manik Surtani wrote:
Nice work! Is there any way to register the module beans in code so
they don't appear in XML (which is exposed to users)? Perhaps
something like:
In core:
* look thru classpath for all instances of "infinispan-module-
cfg.properties"
* this file would contain infinispan.module.cfg-
beans=org.infinispan.query.config.QueryConfigurationBean,
org.infinispan.query.config.QueryConfigurationBean2,
org.infinispan.query.config.QueryConfigurationBean3, etc
in any given module:
* must package a "infinispan-module-cfg.properties" if it wants to
hook in to the XML cfg parsing system
* delcare any cfg beans in this file, as infinispan.module.cfg-
beans=org.infinispan.query.config.QueryConfigurationBean,
org.infinispan.query.config.QueryConfigurationBean2,
org.infinispan.query.config.QueryConfigurationBean3, etc
WDYT?
On 3 Nov 2009, at 15:52, Vladimir Blagojevic wrote:
> Hey guys,
>
> I completed module configuration proposal Manik and I agreed upon.
> It is
> very important to get this one right so I want to run it by you before
> proceeding further!
>
> Have a look at [1] and follow proposed module configuration example
> below:
>
> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:infinispan:config:4.0">
> <global>
> <transport clusterName="demoCluster"/>
> </global>
>
> <default>
> <clustering mode="replication">
> </clustering>
> <modules>
> <module name="query"
> configClassName="org.infinispan.query.config.QueryConfigurationBean">
> <indexing enabled="true" indexLocalOnly="true"/>
> </module>
> </modules>
> </default>
> </infinispan>
>
> A few things to notice:
>
> a) Any configuration (including default and namedCache) can have a
> module definition
> b) Instance of configClassName is a rich object structure filled from
> module's child XML content
> c) Module's XML content can be arbitrary
> d) Custom module configuration bean is accessed by module name:
>
>
> Configuration def = c.parseDefaultConfiguration();
> ModuleConfigurationBean extensionConfig =
> def.getModuleConfigurationBean("query");
> QueryConfigurationBean bean = (QueryConfigurationBean)
> extensionConfig.getConfigurationBean();
> assert bean.isEnabled();
> assert bean.isIndexLocalOnly();
>
>
> The proposal achieves full flexibility when it comes to having rich
> object configuration structure that modules define themselves.
> Furthermore, core module is completely isolated from module
> configuration extensions. Schema easily accommodates this model and
> there is no adverse effect on performance!
>
>
> [1] https://jira.jboss.org/jira/browse/ISPN-193
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
7:24 p.m.
On 4 Nov 2009, at 17:56, Vladimir Blagojevic wrote:
Ok, I see where you are going. This is along the line with
https://jira.jboss.org/jira/browse/ISPN-245. No problem, even better.
Also there is no need to declare all configurations beans, only the
root
class of configuration, jaxb will resolve others, as long as they
are on
classpath.
How do we proceed from here? I can take over ISPN-245 as well, looks
interesting...
Sure, if you want to do this, be my guest. :)
Also, quick note, are you committing this stuff to trunk? I think its
time we branched trunk to a 4.0 branch so stuff targeted for 4.1
doesn't creep in to 4.0. WDYT?
On 09-11-04 12:27 PM, Manik Surtani wrote:
> Nice work! Is there any way to register the module beans in code so
> they don't appear in XML (which is exposed to users)? Perhaps
> something like:
>
> In core:
> * look thru classpath for all instances of "infinispan-module-
> cfg.properties"
> * this file would contain infinispan.module.cfg-
> beans=org.infinispan.query.config.QueryConfigurationBean,
> org.infinispan.query.config.QueryConfigurationBean2,
> org.infinispan.query.config.QueryConfigurationBean3, etc
>
> in any given module:
> * must package a "infinispan-module-cfg.properties" if it wants to
> hook in to the XML cfg parsing system
> * delcare any cfg beans in this file, as infinispan.module.cfg-
> beans=org.infinispan.query.config.QueryConfigurationBean,
> org.infinispan.query.config.QueryConfigurationBean2,
> org.infinispan.query.config.QueryConfigurationBean3, etc
>
> WDYT?
>
>
> On 3 Nov 2009, at 15:52, Vladimir Blagojevic wrote:
>
>
>> Hey guys,
>>
>> I completed module configuration proposal Manik and I agreed upon.
>> It is
>> very important to get this one right so I want to run it by you
>> before
>> proceeding further!
>>
>> Have a look at [1] and follow proposed module configuration example
>> below:
>>
>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns="urn:infinispan:config:4.0">
>> <global>
>> <transport clusterName="demoCluster"/>
>> </global>
>>
>> <default>
>> <clustering mode="replication">
>> </clustering>
>> <modules>
>> <module name="query"
>> configClassName
>> ="org.infinispan.query.config.QueryConfigurationBean">
>> <indexing enabled="true" indexLocalOnly="true"/>
>> </module>
>> </modules>
>> </default>
>> </infinispan>
>>
>> A few things to notice:
>>
>> a) Any configuration (including default and namedCache) can have a
>> module definition
>> b) Instance of configClassName is a rich object structure filled
>> from
>> module's child XML content
>> c) Module's XML content can be arbitrary
>> d) Custom module configuration bean is accessed by module name:
>>
>>
>> Configuration def = c.parseDefaultConfiguration();
>> ModuleConfigurationBean extensionConfig =
>> def.getModuleConfigurationBean("query");
>> QueryConfigurationBean bean = (QueryConfigurationBean)
>> extensionConfig.getConfigurationBean();
>> assert bean.isEnabled();
>> assert bean.isIndexLocalOnly();
>>
>>
>> The proposal achieves full flexibility when it comes to having rich
>> object configuration structure that modules define themselves.
>> Furthermore, core module is completely isolated from module
>> configuration extensions. Schema easily accommodates this model and
>> there is no adverse effect on performance!
>>
>>
>> [1] https://jira.jboss.org/jira/browse/ISPN-193
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
> _______________________________________________
> 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
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
7:45 p.m.
On 09-11-04 1:24 PM, Manik Surtani wrote:
Sure, if you want to do this, be my guest. :)
Also, quick note, are you committing this stuff to trunk? I think its
time we branched trunk to a 4.0 branch so stuff targeted for 4.1
doesn't creep in to 4.0. WDYT?
I would normally say lets shoot for 4.1 but if we get this module thing
in then schema should not change a lot between 4.0 and 4.1, right? How
much change in schema do you anticipate in post 4.0 releases?
7:51 p.m.
On 4 Nov 2009, at 18:45, Vladimir Blagojevic wrote:
On 09-11-04 1:24 PM, Manik Surtani wrote:
> Sure, if you want to do this, be my guest. :)
>
> Also, quick note, are you committing this stuff to trunk? I think
> its
> time we branched trunk to a 4.0 branch so stuff targeted for 4.1
> doesn't creep in to 4.0. WDYT?
>
I would normally say lets shoot for 4.1 but if we get this module
thing
in then schema should not change a lot between 4.0 and 4.1, right? How
much change in schema do you anticipate in post 4.0 releases?
It's not that I anticipate changes, it's more a case of introducing
major changes in a late-stage CR. :) Then again, we've already done
that with ISPN-251, etc...
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
8:43 p.m.
On 09-11-04 1:51 PM, Manik Surtani wrote:
It's not that I anticipate changes, it's more a case of
introducing
major changes in a late-stage CR. :) Then again, we've already done
that with ISPN-251, etc...
My gut feeling is that we go forward and implement this feature, I think
it is worth it. As soon as 4.0 is out everybody out there can write
their extension modules, experiment with extending Infinispan and so on.
We use query module as our test bunny and a guidance to others how to
extend Infinispan! For a little GA delay we get a big payoff. I doubt
that we are going to introduce some major instability. I've already
implemented module configuration loading, just have to convert it to
look for this property file. The change is not major, and ISPN-245 does
not look too hard. Maybe you can take ISPN-245? You could do it in a day
or so since you are familiar with that code inside out....
What does everyone else think?
8:56 p.m.
TBH ISPN-193 and ISPN-245 need not be joined at the hip. We could go
with 193 now since you already have it, and then 245 after GA. Or,
time permitting, I could implement 245 at some point next week maybe
and that could be rolled into the GA too, let's see, but it shouldn't
be a blocker for GA.
Sent from my iPhone
On 4 Nov 2009, at 19:43, Vladimir Blagojevic <vblagoje(a)redhat.com>
wrote:
On 09-11-04 1:51 PM, Manik Surtani wrote:
> It's not that I anticipate changes, it's more a case of introducing
> major changes in a late-stage CR. :) Then again, we've already done
> that with ISPN-251, etc...
>
>
My gut feeling is that we go forward and implement this feature, I
think
it is worth it. As soon as 4.0 is out everybody out there can write
their extension modules, experiment with extending Infinispan and so
on.
We use query module as our test bunny and a guidance to others how to
extend Infinispan! For a little GA delay we get a big payoff. I doubt
that we are going to introduce some major instability. I've already
implemented module configuration loading, just have to convert it to
look for this property file. The change is not major, and ISPN-245
does
not look too hard. Maybe you can take ISPN-245? You could do it in a
day
or so since you are familiar with that code inside out....
What does everyone else think?
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:27 a.m.
On 11/04/2009 08:56 PM, Manik Surtani wrote:
TBH ISPN-193 and ISPN-245 need not be joined at the hip. We could go
with 193 now since you already have it, and then 245 after GA. Or,
time permitting, I could implement 245 at some point next week maybe
and that could be rolled into the GA too, let's see, but it shouldn't
be a blocker for GA.
I'd wait for 245 till 4.1 cos it's better if we give ourselves time to
provide implementations for the interface so that we can nail it down.
For example, I do wanna implement a ModuleLifecycle for tree module.
If we get something wrong in the interface now and we commit it for 4.0,
it's gonna be tough to change it afterwards.
Sent from my iPhone
On 4 Nov 2009, at 19:43, Vladimir Blagojevic<vblagoje(a)redhat.com>
wrote:
> On 09-11-04 1:51 PM, Manik Surtani wrote:
>> It's not that I anticipate changes, it's more a case of introducing
>> major changes in a late-stage CR. :) Then again, we've already done
>> that with ISPN-251, etc...
>>
>>
> My gut feeling is that we go forward and implement this feature, I
> think
> it is worth it. As soon as 4.0 is out everybody out there can write
> their extension modules, experiment with extending Infinispan and so
> on.
> We use query module as our test bunny and a guidance to others how to
> extend Infinispan! For a little GA delay we get a big payoff. I doubt
> that we are going to introduce some major instability. I've already
> implemented module configuration loading, just have to convert it to
> look for this property file. The change is not major, and ISPN-245
> does
> not look too hard. Maybe you can take ISPN-245? You could do it in a
> day
> or so since you are familiar with that code inside out....
>
> What does everyone else think?
>
>
>
>
> _______________________________________________
> 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
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12:52 p.m.
Well, it's hardly public API. It isn't even SPI, it's in between an
internal interface and an SPI. :) so I'm not that concerned. No one
really should be using this interface except us.
Sent from my iPhone
On 5 Nov 2009, at 09:29, Galder Zamarreno <galder(a)redhat.com> wrote:
On 11/04/2009 08:56 PM, Manik Surtani wrote:
> TBH ISPN-193 and ISPN-245 need not be joined at the hip. We could go
> with 193 now since you already have it, and then 245 after GA. Or,
> time permitting, I could implement 245 at some point next week maybe
> and that could be rolled into the GA too, let's see, but it shouldn't
> be a blocker for GA.
I'd wait for 245 till 4.1 cos it's better if we give ourselves time to
provide implementations for the interface so that we can nail it down.
For example, I do wanna implement a ModuleLifecycle for tree module.
If we get something wrong in the interface now and we commit it for
4.0,
it's gonna be tough to change it afterwards.
>
> Sent from my iPhone
>
> On 4 Nov 2009, at 19:43, Vladimir Blagojevic<vblagoje(a)redhat.com>
> wrote:
>
>> On 09-11-04 1:51 PM, Manik Surtani wrote:
>>> It's not that I anticipate changes, it's more a case of introducing
>>> major changes in a late-stage CR. :) Then again, we've already
>>> done
>>> that with ISPN-251, etc...
>>>
>>>
>> My gut feeling is that we go forward and implement this feature, I
>> think
>> it is worth it. As soon as 4.0 is out everybody out there can write
>> their extension modules, experiment with extending Infinispan and so
>> on.
>> We use query module as our test bunny and a guidance to others how
>> to
>> extend Infinispan! For a little GA delay we get a big payoff. I
>> doubt
>> that we are going to introduce some major instability. I've already
>> implemented module configuration loading, just have to convert it to
>> look for this property file. The change is not major, and ISPN-245
>> does
>> not look too hard. Maybe you can take ISPN-245? You could do it in a
>> day
>> or so since you are familiar with that code inside out....
>>
>> What does everyone else think?
>>
>>
>>
>>
>> _______________________________________________
>> 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
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:10 p.m.
One thing that remains unclear - do we invoke lifecycle manager
interface if it is found specified on classpath even though module
extension is never used in configuration? My guess is that we need to
invoke lifecycle manager callbacks if and only if module extension is
actually specified in configuration. In that case we need to extend
LifecycleManager to have getModuleName() API signature.
On 09-11-05 6:52 AM, Manik Surtani wrote:
Well, it's hardly public API. It isn't even SPI, it's in
between an
internal interface and an SPI. :) so I'm not that concerned. No one
really should be using this interface except us.
5:01 p.m.
Well, even if the module extension is in the cfg XML file, core doesn't know how to
parse it and it may be disabled.
IMO the lifecycle callbacks should happen anyway. It is up to the lifecycle implementor
to decide whether to do anything or just be a no-op (if not enabled, etc).
----- Original Message -----
From: "Vladimir Blagojevic" <vblagoje(a)redhat.com>
To: infinispan-dev(a)lists.jboss.org
Sent: Saturday, 7 November, 2009 17:10:16 GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: [infinispan-dev] Module configuration proposal
One thing that remains unclear - do we invoke lifecycle manager
interface if it is found specified on classpath even though module
extension is never used in configuration? My guess is that we need to
invoke lifecycle manager callbacks if and only if module extension is
actually specified in configuration. In that case we need to extend
LifecycleManager to have getModuleName() API signature.
On 09-11-05 6:52 AM, Manik Surtani wrote:
Well, it's hardly public API. It isn't even SPI, it's in
between an
internal interface and an SPI. :) so I'm not that concerned. No one
really should be using this interface except us.
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:23 p.m.
On 09-11-08 11:01 AM, Manik Surtani wrote:
Well, even if the module extension is in the cfg XML file, core
doesn't know how to parse it and it may be disabled.
I am thinking end user deployment scenario, not our current setup. End
user deployment is going to have both core and module jars on
classpath. As soon as module.cfg (or whatever we call it) is found on
classpath it will potentially modify *every* cache created in that
setup. That is dangerous IMO and not something deployer intends to do!
IMO the lifecycle callbacks should happen anyway. It is up to the
lifecycle implementor to decide whether to do anything or just be a no-op (if not enabled,
etc).
Again, I think this is *not* up to module developer to decide but up to
end user creating a final cache setup deployment.....
5:29 p.m.
Ok, 193 is in. Give it a quick look and I'll see now what needs to be
done for 245.
On 09-11-04 2:56 PM, Manik Surtani wrote:
TBH ISPN-193 and ISPN-245 need not be joined at the hip. We could go
with 193 now since you already have it, and then 245 after GA. Or,
time permitting, I could implement 245 at some point next week maybe
and that could be rolled into the GA too, let's see, but it shouldn't
be a blocker for GA.
Sent from my iPhone
On 4 Nov 2009, at 19:43, Vladimir Blagojevic<vblagoje(a)redhat.com>
wrote:
> On 09-11-04 1:51 PM, Manik Surtani wrote:
>
>> It's not that I anticipate changes, it's more a case of introducing
>> major changes in a late-stage CR. :) Then again, we've already done
>> that with ISPN-251, etc...
>>
>>
>>
> My gut feeling is that we go forward and implement this feature, I
> think
> it is worth it. As soon as 4.0 is out everybody out there can write
> their extension modules, experiment with extending Infinispan and so
> on.
> We use query module as our test bunny and a guidance to others how to
> extend Infinispan! For a little GA delay we get a big payoff. I doubt
> that we are going to introduce some major instability. I've already
> implemented module configuration loading, just have to convert it to
> look for this property file. The change is not major, and ISPN-245
> does
> not look too hard. Maybe you can take ISPN-245? You could do it in a
> day
> or so since you are familiar with that code inside out....
>
> What does everyone else think?
>
>
>
>
> _______________________________________________
> 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
11:35 p.m.
Wow that was quick, dude! :) I haven't had a chance to have a look
yet, have you set up a config bean for the query module as an example
of this?
Sent from my iPhone
On 5 Nov 2009, at 16:29, Vladimir Blagojevic <vblagoje(a)redhat.com>
wrote:
Ok, 193 is in. Give it a quick look and I'll see now what needs
to be
done for 245.
On 09-11-04 2:56 PM, Manik Surtani wrote:
> TBH ISPN-193 and ISPN-245 need not be joined at the hip. We could go
> with 193 now since you already have it, and then 245 after GA. Or,
> time permitting, I could implement 245 at some point next week maybe
> and that could be rolled into the GA too, let's see, but it shouldn't
> be a blocker for GA.
>
> Sent from my iPhone
>
> On 4 Nov 2009, at 19:43, Vladimir Blagojevic<vblagoje(a)redhat.com>
> wrote:
>
>
>> On 09-11-04 1:51 PM, Manik Surtani wrote:
>>
>>> It's not that I anticipate changes, it's more a case of introducing
>>> major changes in a late-stage CR. :) Then again, we've already
>>> done
>>> that with ISPN-251, etc...
>>>
>>>
>>>
>> My gut feeling is that we go forward and implement this feature, I
>> think
>> it is worth it. As soon as 4.0 is out everybody out there can write
>> their extension modules, experiment with extending Infinispan and so
>> on.
>> We use query module as our test bunny and a guidance to others how
>> to
>> extend Infinispan! For a little GA delay we get a big payoff. I
>> doubt
>> that we are going to introduce some major instability. I've already
>> implemented module configuration loading, just have to convert it to
>> look for this property file. The change is not major, and ISPN-245
>> does
>> not look too hard. Maybe you can take ISPN-245? You could do it in a
>> day
>> or so since you are familiar with that code inside out....
>>
>> What does everyone else think?
>>
>>
>>
>>
>> _______________________________________________
>> 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
11:50 p.m.
Yes, I did! Check out QueryParsingTest in query module.
I have also finished 245, not committed yet.
Will overview code again tonight, but I think 245 is good to go as well.
Cheers
On 09-11-05 5:35 PM, Manik Surtani wrote:
Wow that was quick, dude! :) I haven't had a chance to have a
look
yet, have you set up a config bean for the query module as an example
of this?
Sent from my iPhone
On 5 Nov 2009, at 16:29, Vladimir Blagojevic<vblagoje(a)redhat.com>
wrote:
> Ok, 193 is in. Give it a quick look and I'll see now what needs to be
> done for 245.
>
> On 09-11-04 2:56 PM, Manik Surtani wrote:
>
>> TBH ISPN-193 and ISPN-245 need not be joined at the hip. We could go
>> with 193 now since you already have it, and then 245 after GA. Or,
>> time permitting, I could implement 245 at some point next week maybe
>> and that could be rolled into the GA too, let's see, but it shouldn't
>> be a blocker for GA.
>>
>> Sent from my iPhone
>>
>> On 4 Nov 2009, at 19:43, Vladimir Blagojevic<vblagoje(a)redhat.com>
>> wrote:
>>
>>
>>
>>> On 09-11-04 1:51 PM, Manik Surtani wrote:
>>>
>>>
>>>> It's not that I anticipate changes, it's more a case of
introducing
>>>> major changes in a late-stage CR. :) Then again, we've already
>>>> done
>>>> that with ISPN-251, etc...
>>>>
>>>>
>>>>
>>>>
>>> My gut feeling is that we go forward and implement this feature, I
>>> think
>>> it is worth it. As soon as 4.0 is out everybody out there can write
>>> their extension modules, experiment with extending Infinispan and so
>>> on.
>>> We use query module as our test bunny and a guidance to others how
>>> to
>>> extend Infinispan! For a little GA delay we get a big payoff. I
>>> doubt
>>> that we are going to introduce some major instability. I've already
>>> implemented module configuration loading, just have to convert it to
>>> look for this property file. The change is not major, and ISPN-245
>>> does
>>> not look too hard. Maybe you can take ISPN-245? You could do it in a
>>> day
>>> or so since you are familiar with that code inside out....
>>>
>>> What does everyone else think?
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:55 a.m.
You're a machine, dude! :)
Sent from my iPhone
On 5 Nov 2009, at 22:51, Vladimir Blagojevic <vblagoje(a)redhat.com>
wrote:
Yes, I did! Check out QueryParsingTest in query module.
I have also finished 245, not committed yet.
Will overview code again tonight, but I think 245 is good to go as
well.
Cheers
On 09-11-05 5:35 PM, Manik Surtani wrote:
> Wow that was quick, dude! :) I haven't had a chance to have a look
> yet, have you set up a config bean for the query module as an example
> of this?
>
> Sent from my iPhone
>
> On 5 Nov 2009, at 16:29, Vladimir Blagojevic<vblagoje(a)redhat.com>
> wrote:
>
>
>> Ok, 193 is in. Give it a quick look and I'll see now what needs to
>> be
>> done for 245.
>>
>> On 09-11-04 2:56 PM, Manik Surtani wrote:
>>
>>> TBH ISPN-193 and ISPN-245 need not be joined at the hip. We could
>>> go
>>> with 193 now since you already have it, and then 245 after GA. Or,
>>> time permitting, I could implement 245 at some point next week
>>> maybe
>>> and that could be rolled into the GA too, let's see, but it
>>> shouldn't
>>> be a blocker for GA.
>>>
>>> Sent from my iPhone
>>>
>>> On 4 Nov 2009, at 19:43, Vladimir Blagojevic<vblagoje(a)redhat.com>
>>> wrote:
>>>
>>>
>>>
>>>> On 09-11-04 1:51 PM, Manik Surtani wrote:
>>>>
>>>>
>>>>> It's not that I anticipate changes, it's more a case of
>>>>> introducing
>>>>> major changes in a late-stage CR. :) Then again, we've already
>>>>> done
>>>>> that with ISPN-251, etc...
>>>>>
>>>>>
>>>>>
>>>>>
>>>> My gut feeling is that we go forward and implement this feature, I
>>>> think
>>>> it is worth it. As soon as 4.0 is out everybody out there can
>>>> write
>>>> their extension modules, experiment with extending Infinispan
>>>> and so
>>>> on.
>>>> We use query module as our test bunny and a guidance to others how
>>>> to
>>>> extend Infinispan! For a little GA delay we get a big payoff. I
>>>> doubt
>>>> that we are going to introduce some major instability. I've
>>>> already
>>>> implemented module configuration loading, just have to convert
>>>> it to
>>>> look for this property file. The change is not major, and ISPN-245
>>>> does
>>>> not look too hard. Maybe you can take ISPN-245? You could do it
>>>> in a
>>>> day
>>>> or so since you are familiar with that code inside out....
>>>>
>>>> What does everyone else think?
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
> _______________________________________________
> 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
12:11 p.m.
Looks great! In the config file, can we call the cfg bean property
infinispan.module.config-beans ? Just using a plural here since we
should be able to pass in a comma delimited list of config beans...
Not just one bean. Wdyt?
Sent from my iPhone
On 5 Nov 2009, at 22:51, Vladimir Blagojevic <vblagoje(a)redhat.com>
wrote:
Yes, I did! Check out QueryParsingTest in query module.
I have also finished 245, not committed yet.
Will overview code again tonight, but I think 245 is good to go as
well.
Cheers
On 09-11-05 5:35 PM, Manik Surtani wrote:
> Wow that was quick, dude! :) I haven't had a chance to have a look
> yet, have you set up a config bean for the query module as an example
> of this?
>
> Sent from my iPhone
>
> On 5 Nov 2009, at 16:29, Vladimir Blagojevic<vblagoje(a)redhat.com>
> wrote:
>
>
>> Ok, 193 is in. Give it a quick look and I'll see now what needs to
>> be
>> done for 245.
>>
>> On 09-11-04 2:56 PM, Manik Surtani wrote:
>>
>>> TBH ISPN-193 and ISPN-245 need not be joined at the hip. We could
>>> go
>>> with 193 now since you already have it, and then 245 after GA. Or,
>>> time permitting, I could implement 245 at some point next week
>>> maybe
>>> and that could be rolled into the GA too, let's see, but it
>>> shouldn't
>>> be a blocker for GA.
>>>
>>> Sent from my iPhone
>>>
>>> On 4 Nov 2009, at 19:43, Vladimir Blagojevic<vblagoje(a)redhat.com>
>>> wrote:
>>>
>>>
>>>
>>>> On 09-11-04 1:51 PM, Manik Surtani wrote:
>>>>
>>>>
>>>>> It's not that I anticipate changes, it's more a case of
>>>>> introducing
>>>>> major changes in a late-stage CR. :) Then again, we've already
>>>>> done
>>>>> that with ISPN-251, etc...
>>>>>
>>>>>
>>>>>
>>>>>
>>>> My gut feeling is that we go forward and implement this feature, I
>>>> think
>>>> it is worth it. As soon as 4.0 is out everybody out there can
>>>> write
>>>> their extension modules, experiment with extending Infinispan
>>>> and so
>>>> on.
>>>> We use query module as our test bunny and a guidance to others how
>>>> to
>>>> extend Infinispan! For a little GA delay we get a big payoff. I
>>>> doubt
>>>> that we are going to introduce some major instability. I've
>>>> already
>>>> implemented module configuration loading, just have to convert
>>>> it to
>>>> look for this property file. The change is not major, and ISPN-245
>>>> does
>>>> not look too hard. Maybe you can take ISPN-245? You could do it
>>>> in a
>>>> day
>>>> or so since you are familiar with that code inside out....
>>>>
>>>> What does everyone else think?
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
> _______________________________________________
> 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
12:37 p.m.
A couple of comments re 193:
How would you set this stuff programmatically? Conf.setQueryConfig(qc) ?
Also, are the <module> tags and the <query: > prefix necessary in the
XML config? Any clever way to do without these, since the queryconfig
bean is detected at the beginning and doesn't have to be loaded when
specific tags are encountered, right?
Cheers
Manik
Sent from my iPhone
On 5 Nov 2009, at 22:51, Vladimir Blagojevic <vblagoje(a)redhat.com>
wrote:
Yes, I did! Check out QueryParsingTest in query module.
I have also finished 245, not committed yet.
Will overview code again tonight, but I think 245 is good to go as
well.
Cheers
On 09-11-05 5:35 PM, Manik Surtani wrote:
> Wow that was quick, dude! :) I haven't had a chance to have a look
> yet, have you set up a config bean for the query module as an example
> of this?
>
> Sent from my iPhone
>
> On 5 Nov 2009, at 16:29, Vladimir Blagojevic<vblagoje(a)redhat.com>
> wrote:
>
>
>> Ok, 193 is in. Give it a quick look and I'll see now what needs to
>> be
>> done for 245.
>>
>> On 09-11-04 2:56 PM, Manik Surtani wrote:
>>
>>> TBH ISPN-193 and ISPN-245 need not be joined at the hip. We could
>>> go
>>> with 193 now since you already have it, and then 245 after GA. Or,
>>> time permitting, I could implement 245 at some point next week
>>> maybe
>>> and that could be rolled into the GA too, let's see, but it
>>> shouldn't
>>> be a blocker for GA.
>>>
>>> Sent from my iPhone
>>>
>>> On 4 Nov 2009, at 19:43, Vladimir Blagojevic<vblagoje(a)redhat.com>
>>> wrote:
>>>
>>>
>>>
>>>> On 09-11-04 1:51 PM, Manik Surtani wrote:
>>>>
>>>>
>>>>> It's not that I anticipate changes, it's more a case of
>>>>> introducing
>>>>> major changes in a late-stage CR. :) Then again, we've already
>>>>> done
>>>>> that with ISPN-251, etc...
>>>>>
>>>>>
>>>>>
>>>>>
>>>> My gut feeling is that we go forward and implement this feature, I
>>>> think
>>>> it is worth it. As soon as 4.0 is out everybody out there can
>>>> write
>>>> their extension modules, experiment with extending Infinispan
>>>> and so
>>>> on.
>>>> We use query module as our test bunny and a guidance to others how
>>>> to
>>>> extend Infinispan! For a little GA delay we get a big payoff. I
>>>> doubt
>>>> that we are going to introduce some major instability. I've
>>>> already
>>>> implemented module configuration loading, just have to convert
>>>> it to
>>>> look for this property file. The change is not major, and ISPN-245
>>>> does
>>>> not look too hard. Maybe you can take ISPN-245? You could do it
>>>> in a
>>>> day
>>>> or so since you are familiar with that code inside out....
>>>>
>>>> What does everyone else think?
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
> _______________________________________________
> 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
3:18 p.m.
On 09-11-06 6:37 AM, Manik Surtani wrote:
A couple of comments re 193:
How would you set this stuff programmatically? Conf.setQueryConfig(qc) ?
Also, are the<module> tags and the<query:> prefix necessary in the
XML config? Any clever way to do without these, since the queryconfig
bean is detected at the beginning and doesn't have to be loaded when
specific tags are encountered, right?
Cheers
Manik
We can make it programmatic, no problem.
Prefix, we have to keep since JAXB forces it. We can avoid its usage
if we manually change generated schema.
How would you ideally align these tags?
3:57 p.m.
Ideally, something as simple as:
<infinispan>
<namedCache name="blah">
<indexing enabled="true" localOnly="false" />
</>
</>
Sent from my iPhone
On 6 Nov 2009, at 14:18, Vladimir Blagojevic <vblagoje(a)redhat.com>
wrote:
On 09-11-06 6:37 AM, Manik Surtani wrote:
> A couple of comments re 193:
>
> How would you set this stuff programmatically? Conf.setQueryConfig
> (qc) ?
>
> Also, are the<module> tags and the<query:> prefix necessary in the
> XML config? Any clever way to do without these, since the queryconfig
> bean is detected at the beginning and doesn't have to be loaded when
> specific tags are encountered, right?
>
> Cheers
> Manik
>
We can make it programmatic, no problem.
Prefix, we have to keep since JAXB forces it. We can avoid its usage
if we manually change generated schema.
How would you ideally align these tags?
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
7:46 p.m.
Can't have just arbitrary elements in cache element since schema
constrains it.
We need at least one parent element whose children are arbitrary.
I'll see if I can make:
<infinispan>
<namedCache name="blah">
<module name="query">
<indexing enabled="true" localOnly="false" />
</module>
<module name="tree">
<blah blah="true" blah="false" />
</module>
</>
</>
Just as it is now, but without<modules> being parent of<module>.
On 09-11-06 9:57 AM, Manik Surtani wrote:
Ideally, something as simple as:
<infinispan>
<namedCache name="blah">
<indexing enabled="true" localOnly="false" />
</>
</>
Sent from my iPhone
On 6 Nov 2009, at 14:18, Vladimir Blagojevic<vblagoje(a)redhat.com>
wrote:
> On 09-11-06 6:37 AM, Manik Surtani wrote:
>
>> A couple of comments re 193:
>>
>> How would you set this stuff programmatically? Conf.setQueryConfig
>> (qc) ?
>>
>> Also, are the<module> tags and the<query:> prefix necessary in
the
>> XML config? Any clever way to do without these, since the queryconfig
>> bean is detected at the beginning and doesn't have to be loaded when
>> specific tags are encountered, right?
>>
>> Cheers
>> Manik
>>
>>
> We can make it programmatic, no problem.
>
> Prefix, we have to keep since JAXB forces it. We can avoid its usage
> if we manually change generated schema.
>
> How would you ideally align these tags?
>
> _______________________________________________
> 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
5:04 p.m.
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
----- Original Message -----
From: "Vladimir Blagojevic" <vblagoje(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Friday, 6 November, 2009 18:46:20 GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: [infinispan-dev] Module configuration proposal
Can't have just arbitrary elements in cache element since schema
constrains it.
We need at least one parent element whose children are arbitrary.
I'll see if I can make:
<infinispan>
<namedCache name="blah">
<module name="query">
<indexing enabled="true" localOnly="false" />
</module>
<module name="tree">
<blah blah="true" blah="false" />
</module>
</>
</>
Just as it is now, but without<modules> being parent of<module>.
On 09-11-06 9:57 AM, Manik Surtani wrote:
> Ideally, something as simple as:
>
<infinispan>
<namedCache name="blah">
<indexing enabled="true" localOnly="false" />
</>
</>
>
> Sent from my iPhone
>
> On 6 Nov 2009, at 14:18, Vladimir Blagojevic<vblagoje(a)redhat.com>
> wrote:
>
>
>> On 09-11-06 6:37 AM, Manik Surtani wrote:
>>
>>> A couple of comments re 193:
>>>
>>> How would you set this stuff programmatically? Conf.setQueryConfig
>>> (qc) ?
>>>
>>> Also, are the<module> tags and the<query:> prefix necessary
in the
>>> XML config? Any clever way to do without these, since the queryconfig
>>> bean is detected at the beginning and doesn't have to be loaded when
>>> specific tags are encountered, right?
>>>
>>> Cheers
>>> Manik
>>>
>>>
>> We can make it programmatic, no problem.
>>
>> Prefix, we have to keep since JAXB forces it. We can avoid its usage
>> if we manually change generated schema.
>>
>> How would you ideally align these tags?
>>
>> _______________________________________________
>> 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
9:29 p.m.
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
7:10 p.m.
I just thought about something - generated docs. How does this work?
Also have you tested generated schema + docs, does it work with config
beans sitting in different modules? It should in theory, but you never
know with maven. :)
Sent from my iPhone
On 6 Nov 2009, at 14:18, Vladimir Blagojevic <vblagoje(a)redhat.com>
wrote:
On 09-11-06 6:37 AM, Manik Surtani wrote:
> A couple of comments re 193:
>
> How would you set this stuff programmatically? Conf.setQueryConfig
> (qc) ?
>
> Also, are the<module> tags and the<query:> prefix necessary in the
> XML config? Any clever way to do without these, since the queryconfig
> bean is detected at the beginning and doesn't have to be loaded when
> specific tags are encountered, right?
>
> Cheers
> Manik
>
We can make it programmatic, no problem.
Prefix, we have to keep since JAXB forces it. We can avoid its usage
if we manually change generated schema.
How would you ideally align these tags?
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5535
days inactive
5540
days old
infinispan-dev@lists.jboss.org
30 comments
5 participants
participants (5)
-
Galder Zamarreno -
Manik Surtani -
Manik Surtani -
Navin Surtani -
Vladimir Blagojevic