On May 6, 2009, at 15:17 , Noble Paul നോബിള്
नोब्ळ् wrote:
Why would you want to write it to the data dir? why can't it be in the
same place (conf) ?
Well, fact is that the QueryElevationComponent loads the
configuration file ( elevate.xml ) either from the data dir, either
from the conf dir.
Which means that existing setups using this component maybe using
either location.
That is the only reason why i judged necessary to keep supporting
this "flexibility".
But this could be simplified, forcing the elevate.xml file to be in
the conf dir, and having a system ( the one you proposed, or the
request handler attached to the issue ) to reload the configuration
from the conf dir ( which is currently not possible. While when
elevate.xml is stored in the dataDir, triggering a commit would
reload it ).
I was just unsure about all ins and outs of the Elevation system, and
then did not remove this flexibility.
Thanks for your expert eye on this !
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
--
Nicolas Pastorino
Consultant - Trainer - System Developer
Phone : +33 (0)4.78.37.01.34
eZ Systems ( Western Europe ) | http://ez.no
