[infinispan-dev] splitting infinispan-lucene-directory.jar

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] splitting infinispan-lucene-directory.jar

Sanne Grinovero-3
Hello all,
it seems that people defining an Infinispan configuration in the
application server for the Lucene directory, and using the ad-hoc
TwoWayKey2StringMapper, need to move the
infinispan-lucene-directory.jar in the commons-lib directory of the
application server.

Since this module depends on Lucene too, people would need to move the
Lucene jar too, and this is not desirable as applications might want
to use different applications.

The mapper depends of course to the objects it creates: the only clean
option I'm seeing is to split the jar in two jars, making sure that
the keyMapper and keys are independent from Lucene, but I'm not a big
fan of this split.

Thoughts?

http://community.jboss.org/message/613078#613078

Sanne
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] splitting infinispan-lucene-directory.jar

Galder Zamarreno
Hmmmm, question:

Did you look into the possibility of using the LifecycleCallbacks to hook the LuceneKey2StringMapper at runtime?

In theory, that should allow the cache manager to hook the mapper on lucene mapper on startup assuming that the cache manager jar can successfully locate the module properties file belonging to the lucene directory deployed in the EAR.

On Jul 2, 2011, at 12:35 AM, Sanne Grinovero wrote:

> Hello all,
> it seems that people defining an Infinispan configuration in the
> application server for the Lucene directory, and using the ad-hoc
> TwoWayKey2StringMapper, need to move the
> infinispan-lucene-directory.jar in the commons-lib directory of the
> application server.
>
> Since this module depends on Lucene too, people would need to move the
> Lucene jar too, and this is not desirable as applications might want
> to use different applications.
>
> The mapper depends of course to the objects it creates: the only clean
> option I'm seeing is to split the jar in two jars, making sure that
> the keyMapper and keys are independent from Lucene, but I'm not a big
> fan of this split.
>
> Thoughts?
>
> http://community.jboss.org/message/613078#613078
>
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] splitting infinispan-lucene-directory.jar

Sanne Grinovero-3
Hi Galder,
I'm not sure I understood your suggestion. Are you thinking of having
users explicitly avoid defining it in their configuration file, and
then have the application - when it's eventually started - override
the configuration of an already started cache?

2011/7/4 Galder Zamarreño <[hidden email]>:

> Hmmmm, question:
>
> Did you look into the possibility of using the LifecycleCallbacks to hook the LuceneKey2StringMapper at runtime?
>
> In theory, that should allow the cache manager to hook the mapper on lucene mapper on startup assuming that the cache manager jar can successfully locate the module properties file belonging to the lucene directory deployed in the EAR.
>
> On Jul 2, 2011, at 12:35 AM, Sanne Grinovero wrote:
>
>> Hello all,
>> it seems that people defining an Infinispan configuration in the
>> application server for the Lucene directory, and using the ad-hoc
>> TwoWayKey2StringMapper, need to move the
>> infinispan-lucene-directory.jar in the commons-lib directory of the
>> application server.
>>
>> Since this module depends on Lucene too, people would need to move the
>> Lucene jar too, and this is not desirable as applications might want
>> to use different applications.
>>
>> The mapper depends of course to the objects it creates: the only clean
>> option I'm seeing is to split the jar in two jars, making sure that
>> the keyMapper and keys are independent from Lucene, but I'm not a big
>> fan of this split.
>>
>> Thoughts?
>>
>> http://community.jboss.org/message/613078#613078
>>
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] splitting infinispan-lucene-directory.jar

Galder Zamarreno
Yeah, something like that but configuring before starting the cache manager.

Bearing in mind my limited knowledge, shouldn't a lucene directory implementation be mandatorily configured with LuceneKey2StringMapper?

IOW, couldn't the lifecycle callback implementation be clever enough to discover whether a JdbcStringBasedCacheStoreConfig is in use and if so, configure this mapper?

If it's not mandatory, why isn't it?

On Jul 4, 2011, at 10:08 AM, Sanne Grinovero wrote:

> Hi Galder,
> I'm not sure I understood your suggestion. Are you thinking of having
> users explicitly avoid defining it in their configuration file, and
> then have the application - when it's eventually started - override
> the configuration of an already started cache?
>
> 2011/7/4 Galder Zamarreño <[hidden email]>:
>> Hmmmm, question:
>>
>> Did you look into the possibility of using the LifecycleCallbacks to hook the LuceneKey2StringMapper at runtime?
>>
>> In theory, that should allow the cache manager to hook the mapper on lucene mapper on startup assuming that the cache manager jar can successfully locate the module properties file belonging to the lucene directory deployed in the EAR.
>>
>> On Jul 2, 2011, at 12:35 AM, Sanne Grinovero wrote:
>>
>>> Hello all,
>>> it seems that people defining an Infinispan configuration in the
>>> application server for the Lucene directory, and using the ad-hoc
>>> TwoWayKey2StringMapper, need to move the
>>> infinispan-lucene-directory.jar in the commons-lib directory of the
>>> application server.
>>>
>>> Since this module depends on Lucene too, people would need to move the
>>> Lucene jar too, and this is not desirable as applications might want
>>> to use different applications.
>>>
>>> The mapper depends of course to the objects it creates: the only clean
>>> option I'm seeing is to split the jar in two jars, making sure that
>>> the keyMapper and keys are independent from Lucene, but I'm not a big
>>> fan of this split.
>>>
>>> Thoughts?
>>>
>>> http://community.jboss.org/message/613078#613078
>>>
>>> Sanne
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] splitting infinispan-lucene-directory.jar

Sanne Grinovero-3
The LuceneKey2StringMapper is not mandatory as it is an optional
optimization which applies only in case a StringBased/CacheStore is
enabled.
I'm confused about what you mean with a lifecycle callback, I'm
assuming that the cache manager is started with the application
server, while the application might be deployed later - and so not
even have the classes available to whatever hack the cachemanager
might want to attempt?

2011/7/5 Galder Zamarreño <[hidden email]>:

> Yeah, something like that but configuring before starting the cache manager.
>
> Bearing in mind my limited knowledge, shouldn't a lucene directory implementation be mandatorily configured with LuceneKey2StringMapper?
>
> IOW, couldn't the lifecycle callback implementation be clever enough to discover whether a JdbcStringBasedCacheStoreConfig is in use and if so, configure this mapper?
>
> If it's not mandatory, why isn't it?
>
> On Jul 4, 2011, at 10:08 AM, Sanne Grinovero wrote:
>
>> Hi Galder,
>> I'm not sure I understood your suggestion. Are you thinking of having
>> users explicitly avoid defining it in their configuration file, and
>> then have the application - when it's eventually started - override
>> the configuration of an already started cache?
>>
>> 2011/7/4 Galder Zamarreño <[hidden email]>:
>>> Hmmmm, question:
>>>
>>> Did you look into the possibility of using the LifecycleCallbacks to hook the LuceneKey2StringMapper at runtime?
>>>
>>> In theory, that should allow the cache manager to hook the mapper on lucene mapper on startup assuming that the cache manager jar can successfully locate the module properties file belonging to the lucene directory deployed in the EAR.
>>>
>>> On Jul 2, 2011, at 12:35 AM, Sanne Grinovero wrote:
>>>
>>>> Hello all,
>>>> it seems that people defining an Infinispan configuration in the
>>>> application server for the Lucene directory, and using the ad-hoc
>>>> TwoWayKey2StringMapper, need to move the
>>>> infinispan-lucene-directory.jar in the commons-lib directory of the
>>>> application server.
>>>>
>>>> Since this module depends on Lucene too, people would need to move the
>>>> Lucene jar too, and this is not desirable as applications might want
>>>> to use different applications.
>>>>
>>>> The mapper depends of course to the objects it creates: the only clean
>>>> option I'm seeing is to split the jar in two jars, making sure that
>>>> the keyMapper and keys are independent from Lucene, but I'm not a big
>>>> fan of this split.
>>>>
>>>> Thoughts?
>>>>
>>>> http://community.jboss.org/message/613078#613078
>>>>
>>>> Sanne
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] splitting infinispan-lucene-directory.jar

Galder Zamarreno

On Jul 5, 2011, at 11:35 AM, Sanne Grinovero wrote:

> The LuceneKey2StringMapper is not mandatory as it is an optional
> optimization which applies only in case a StringBased/CacheStore is
> enabled.
> I'm confused about what you mean with a lifecycle callback, I'm
> assuming that the cache manager is started with the application
> server, while the application might be deployed later - and so not
> even have the classes available to whatever hack the cachemanager
> might want to attempt?

I'm a bit confused as well but this is my process of thinking right now:

If the user deploys the lucene dir jar in their EAR with the std mapper, does it all work fine?

If so, I'm assuming that the core infinispan jar is able to hook finely with the lucene dir jar in this users EAR.

Assuming that works fine, lucene dir's LifecycleCallbacks implementation could implement:

cacheStarting(ComponentRegistry cr, Configuration configuration, String cacheName)

And within it, check if the cache is configured with a StringBased/CacheStore and the inject the LuceneKey2StringMapper.

Clearly, that's assuming that LifecycleCallbacks in lucene dirs can detect which caches are for the lucene directory and which ones to apply this change in.

That way, the commons lib does not require to have access to the LuceneKey2StringMapper

If this doesn't still make sense, ping me and let's have a chat to clarify.

>
> 2011/7/5 Galder Zamarreño <[hidden email]>:
>> Yeah, something like that but configuring before starting the cache manager.
>>
>> Bearing in mind my limited knowledge, shouldn't a lucene directory implementation be mandatorily configured with LuceneKey2StringMapper?
>>
>> IOW, couldn't the lifecycle callback implementation be clever enough to discover whether a JdbcStringBasedCacheStoreConfig is in use and if so, configure this mapper?
>>
>> If it's not mandatory, why isn't it?
>>
>> On Jul 4, 2011, at 10:08 AM, Sanne Grinovero wrote:
>>
>>> Hi Galder,
>>> I'm not sure I understood your suggestion. Are you thinking of having
>>> users explicitly avoid defining it in their configuration file, and
>>> then have the application - when it's eventually started - override
>>> the configuration of an already started cache?
>>>
>>> 2011/7/4 Galder Zamarreño <[hidden email]>:
>>>> Hmmmm, question:
>>>>
>>>> Did you look into the possibility of using the LifecycleCallbacks to hook the LuceneKey2StringMapper at runtime?
>>>>
>>>> In theory, that should allow the cache manager to hook the mapper on lucene mapper on startup assuming that the cache manager jar can successfully locate the module properties file belonging to the lucene directory deployed in the EAR.
>>>>
>>>> On Jul 2, 2011, at 12:35 AM, Sanne Grinovero wrote:
>>>>
>>>>> Hello all,
>>>>> it seems that people defining an Infinispan configuration in the
>>>>> application server for the Lucene directory, and using the ad-hoc
>>>>> TwoWayKey2StringMapper, need to move the
>>>>> infinispan-lucene-directory.jar in the commons-lib directory of the
>>>>> application server.
>>>>>
>>>>> Since this module depends on Lucene too, people would need to move the
>>>>> Lucene jar too, and this is not desirable as applications might want
>>>>> to use different applications.
>>>>>
>>>>> The mapper depends of course to the objects it creates: the only clean
>>>>> option I'm seeing is to split the jar in two jars, making sure that
>>>>> the keyMapper and keys are independent from Lucene, but I'm not a big
>>>>> fan of this split.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> http://community.jboss.org/message/613078#613078
>>>>>
>>>>> Sanne
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software Engineer
>>>> Infinispan, JBoss Cache
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] splitting infinispan-lucene-directory.jar

Sanne Grinovero-3
2011/7/6 Galder Zamarreño <[hidden email]>:

>
> On Jul 5, 2011, at 11:35 AM, Sanne Grinovero wrote:
>
>> The LuceneKey2StringMapper is not mandatory as it is an optional
>> optimization which applies only in case a StringBased/CacheStore is
>> enabled.
>> I'm confused about what you mean with a lifecycle callback, I'm
>> assuming that the cache manager is started with the application
>> server, while the application might be deployed later - and so not
>> even have the classes available to whatever hack the cachemanager
>> might want to attempt?
>
> I'm a bit confused as well but this is my process of thinking right now:
>
> If the user deploys the lucene dir jar in their EAR with the std mapper, does it all work fine?

Sure because the Lucene directory does not affect the way Infinispan
core works, it's only using the Cache API to get/put data, so all it
needs is a reference to the CacheManager: it's in no way involved with
the boot phase of Infinispan, unless a custom component is specified
in the configuration file and this happens to be a component
defined in the infinispan-lucene-directory jar.

I had added this LuceneKey2StringMapper as it greatly helps
performance, but it's in no way mandatory. Still if you define this in
the configuration file of the Infinispan instance of the application
server, the class must be available to the AS.

>
> If so, I'm assuming that the core infinispan jar is able to hook finely with the lucene dir jar in this users EAR.

As mentioned above infinispan.jar doesn't hook at all, it works fine
because there's no hook that needs to be loaded.
I wouldn't expect any LifecycleCallbacks to work in this case, as the
EAR might not be deployed when the AS starts.

Sanne

>
> Assuming that works fine, lucene dir's LifecycleCallbacks implementation could implement:
>
> cacheStarting(ComponentRegistry cr, Configuration configuration, String cacheName)
>
> And within it, check if the cache is configured with a StringBased/CacheStore and the inject the LuceneKey2StringMapper.
>
> Clearly, that's assuming that LifecycleCallbacks in lucene dirs can detect which caches are for the lucene directory and which ones to apply this change in.
>
> That way, the commons lib does not require to have access to the LuceneKey2StringMapper
>
> If this doesn't still make sense, ping me and let's have a chat to clarify.
>
>>
>> 2011/7/5 Galder Zamarreño <[hidden email]>:
>>> Yeah, something like that but configuring before starting the cache manager.
>>>
>>> Bearing in mind my limited knowledge, shouldn't a lucene directory implementation be mandatorily configured with LuceneKey2StringMapper?
>>>
>>> IOW, couldn't the lifecycle callback implementation be clever enough to discover whether a JdbcStringBasedCacheStoreConfig is in use and if so, configure this mapper?
>>>
>>> If it's not mandatory, why isn't it?
>>>
>>> On Jul 4, 2011, at 10:08 AM, Sanne Grinovero wrote:
>>>
>>>> Hi Galder,
>>>> I'm not sure I understood your suggestion. Are you thinking of having
>>>> users explicitly avoid defining it in their configuration file, and
>>>> then have the application - when it's eventually started - override
>>>> the configuration of an already started cache?
>>>>
>>>> 2011/7/4 Galder Zamarreño <[hidden email]>:
>>>>> Hmmmm, question:
>>>>>
>>>>> Did you look into the possibility of using the LifecycleCallbacks to hook the LuceneKey2StringMapper at runtime?
>>>>>
>>>>> In theory, that should allow the cache manager to hook the mapper on lucene mapper on startup assuming that the cache manager jar can successfully locate the module properties file belonging to the lucene directory deployed in the EAR.
>>>>>
>>>>> On Jul 2, 2011, at 12:35 AM, Sanne Grinovero wrote:
>>>>>
>>>>>> Hello all,
>>>>>> it seems that people defining an Infinispan configuration in the
>>>>>> application server for the Lucene directory, and using the ad-hoc
>>>>>> TwoWayKey2StringMapper, need to move the
>>>>>> infinispan-lucene-directory.jar in the commons-lib directory of the
>>>>>> application server.
>>>>>>
>>>>>> Since this module depends on Lucene too, people would need to move the
>>>>>> Lucene jar too, and this is not desirable as applications might want
>>>>>> to use different applications.
>>>>>>
>>>>>> The mapper depends of course to the objects it creates: the only clean
>>>>>> option I'm seeing is to split the jar in two jars, making sure that
>>>>>> the keyMapper and keys are independent from Lucene, but I'm not a big
>>>>>> fan of this split.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> http://community.jboss.org/message/613078#613078
>>>>>>
>>>>>> Sanne
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> --
>>>>> Galder Zamarreño
>>>>> Sr. Software Engineer
>>>>> Infinispan, JBoss Cache
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] splitting infinispan-lucene-directory.jar

Sanne Grinovero-3
As a reference, Galder and I talked about this exploring options, and
posted our conclusions on the forum, where this need was reported
initially:
http://community.jboss.org/message/613731#613731

Sanne

2011/7/6 Sanne Grinovero <[hidden email]>:

> 2011/7/6 Galder Zamarreño <[hidden email]>:
>>
>> On Jul 5, 2011, at 11:35 AM, Sanne Grinovero wrote:
>>
>>> The LuceneKey2StringMapper is not mandatory as it is an optional
>>> optimization which applies only in case a StringBased/CacheStore is
>>> enabled.
>>> I'm confused about what you mean with a lifecycle callback, I'm
>>> assuming that the cache manager is started with the application
>>> server, while the application might be deployed later - and so not
>>> even have the classes available to whatever hack the cachemanager
>>> might want to attempt?
>>
>> I'm a bit confused as well but this is my process of thinking right now:
>>
>> If the user deploys the lucene dir jar in their EAR with the std mapper, does it all work fine?
>
> Sure because the Lucene directory does not affect the way Infinispan
> core works, it's only using the Cache API to get/put data, so all it
> needs is a reference to the CacheManager: it's in no way involved with
> the boot phase of Infinispan, unless a custom component is specified
> in the configuration file and this happens to be a component
> defined in the infinispan-lucene-directory jar.
>
> I had added this LuceneKey2StringMapper as it greatly helps
> performance, but it's in no way mandatory. Still if you define this in
> the configuration file of the Infinispan instance of the application
> server, the class must be available to the AS.
>
>>
>> If so, I'm assuming that the core infinispan jar is able to hook finely with the lucene dir jar in this users EAR.
>
> As mentioned above infinispan.jar doesn't hook at all, it works fine
> because there's no hook that needs to be loaded.
> I wouldn't expect any LifecycleCallbacks to work in this case, as the
> EAR might not be deployed when the AS starts.
>
> Sanne
>
>>
>> Assuming that works fine, lucene dir's LifecycleCallbacks implementation could implement:
>>
>> cacheStarting(ComponentRegistry cr, Configuration configuration, String cacheName)
>>
>> And within it, check if the cache is configured with a StringBased/CacheStore and the inject the LuceneKey2StringMapper.
>>
>> Clearly, that's assuming that LifecycleCallbacks in lucene dirs can detect which caches are for the lucene directory and which ones to apply this change in.
>>
>> That way, the commons lib does not require to have access to the LuceneKey2StringMapper
>>
>> If this doesn't still make sense, ping me and let's have a chat to clarify.
>>
>>>
>>> 2011/7/5 Galder Zamarreño <[hidden email]>:
>>>> Yeah, something like that but configuring before starting the cache manager.
>>>>
>>>> Bearing in mind my limited knowledge, shouldn't a lucene directory implementation be mandatorily configured with LuceneKey2StringMapper?
>>>>
>>>> IOW, couldn't the lifecycle callback implementation be clever enough to discover whether a JdbcStringBasedCacheStoreConfig is in use and if so, configure this mapper?
>>>>
>>>> If it's not mandatory, why isn't it?
>>>>
>>>> On Jul 4, 2011, at 10:08 AM, Sanne Grinovero wrote:
>>>>
>>>>> Hi Galder,
>>>>> I'm not sure I understood your suggestion. Are you thinking of having
>>>>> users explicitly avoid defining it in their configuration file, and
>>>>> then have the application - when it's eventually started - override
>>>>> the configuration of an already started cache?
>>>>>
>>>>> 2011/7/4 Galder Zamarreño <[hidden email]>:
>>>>>> Hmmmm, question:
>>>>>>
>>>>>> Did you look into the possibility of using the LifecycleCallbacks to hook the LuceneKey2StringMapper at runtime?
>>>>>>
>>>>>> In theory, that should allow the cache manager to hook the mapper on lucene mapper on startup assuming that the cache manager jar can successfully locate the module properties file belonging to the lucene directory deployed in the EAR.
>>>>>>
>>>>>> On Jul 2, 2011, at 12:35 AM, Sanne Grinovero wrote:
>>>>>>
>>>>>>> Hello all,
>>>>>>> it seems that people defining an Infinispan configuration in the
>>>>>>> application server for the Lucene directory, and using the ad-hoc
>>>>>>> TwoWayKey2StringMapper, need to move the
>>>>>>> infinispan-lucene-directory.jar in the commons-lib directory of the
>>>>>>> application server.
>>>>>>>
>>>>>>> Since this module depends on Lucene too, people would need to move the
>>>>>>> Lucene jar too, and this is not desirable as applications might want
>>>>>>> to use different applications.
>>>>>>>
>>>>>>> The mapper depends of course to the objects it creates: the only clean
>>>>>>> option I'm seeing is to split the jar in two jars, making sure that
>>>>>>> the keyMapper and keys are independent from Lucene, but I'm not a big
>>>>>>> fan of this split.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> http://community.jboss.org/message/613078#613078
>>>>>>>
>>>>>>> Sanne
>>>>>>> _______________________________________________
>>>>>>> infinispan-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>
>>>>>> --
>>>>>> Galder Zamarreño
>>>>>> Sr. Software Engineer
>>>>>> Infinispan, JBoss Cache
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software Engineer
>>>> Infinispan, JBoss Cache
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev