Why would you want to write it to the data dir? why can't it be in the same place (conf) ?
On Wed, May 6, 2009 at 6:43 PM, Nicolas Pastorino <n...@ez.no> wrote: > Hello, > > On May 6, 2009, at 15:02 , Noble Paul നോബിള് नोब्ळ् wrote: > >> The elevate.xml is loaded from conf dir when the core is reloaded . if >> you post the new xml you will have to reload the core. >> >> A simple solution would be to write a RequestHandler which extends >> QueryElevationComponent which can be a listener for commit and call an >> super.inform() on that event > > You may want to have a look at this issue : > https://issues.apache.org/jira/browse/SOLR-1147 > The proposed solution ( new request handler, attached to the ticket ), > solves the issue in both cases : > * when elevate.xml is in the DataDir. > * when elevate.xml is in the conf dir. > > Basically this new request handler receives, as XML, the new configuration, > writes it to the right place ( some logic was copied from the > QueryElevationComponent.inform() code ), and then calls the inform() method > on the QueryElevationComponent for the current core, as you suggested above, > to reload the Elevate configuration. > -- > Nicolas > > >> On Fri, Apr 10, 2009 at 5:18 PM, Nicolas Pastorino <n...@ez.no> wrote: >>> >>> Hello ! >>> >>> >>> Browsing the mailing-list's archives did not help me find the answer, >>> hence >>> the question asked directly here. >>> >>> Some context first : >>> Integrating Solr with a CMS ( eZ Publish ), we chose to support >>> Elevation. >>> The idea is to be able to 'elevate' any object from the CMS. This can be >>> achieved through eZ Publish's back office, with a dedicated Elevate >>> administration GUI, the configuration is stored in the CMS temporarily, >>> and >>> then synchronized frequently and/or on demand onto Solr. This >>> synchronisation is currently done as follows : >>> 1. Generate the elevate.xml based on the stored configuration >>> 2. Replace elevate.xml in Solr's dataDir >>> 3. Commit. It appears that when having elevate.xml in Solr's dataDir, and >>> solely in this case, commiting triggers a reload of elevate.xml. This >>> does >>> not happen when elevate.xml is stored in Solr's conf dir. >>> >>> >>> This method has one main issue though : eZ Publish needs to have access >>> to >>> the same filesystem as the one on which Solr's dataDir is stored. This is >>> not always the case when the CMS is clustered for instance --> show >>> stopper >>> :( >>> >>> Hence the following idea / RFC : >>> How about extending the Query Elevation system with the possibility to >>> push >>> an updated elevate.xml file/XML through HTTP ? >>> This would update the file where it is actually located, and trigger a >>> reload of the configuration. >>> Not being very knowledgeable about Solr's API ( yet ! ), i cannot figure >>> out >>> whether this would be possible, how this would be achievable ( which type >>> of >>> plugin for instance ) or even be valid ? >>> >>> Thanks a lot in advance for your thoughts, >>> -- >>> Nicolas >>> >>> >>> >>> >> >> >> >> -- >> ----------------------------------------------------- >> Noble Paul | Principal Engineer| AOL | http://aol.com > > -- > Nicolas Pastorino > Consultant - Trainer - System Developer > Phone : +33 (0)4.78.37.01.34 > eZ Systems ( Western Europe ) | http://ez.no > > > > > -- ----------------------------------------------------- Noble Paul | Principal Engineer| AOL | http://aol.com
