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
