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 <gal...@redhat.com>: > 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 <gal...@redhat.com>: >>> 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 >>>> infinispan-dev@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@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
