Faceted search is becoming a de facto search feature for websites such as online stores and digital libraries. From interaction design perspective, faceted search is essentially an alternative to advanced search - “post-coordinate boolean operations via a navigational metaphor”. It has a propensity to enhance the affordance of advanced search, as less efforts are required from the users to perform the equivalent and traditionally more convoluted search tasks.
This post describes the faceted search infrastructure development of the JISC UX2 project. The infrastructure is based on Apache Solr, a Java-based faceted search platform. In Part 1 of this post, I described the general setup of Solr for multi-sourced data, metadata (MARC XML) mapping and the experience of importing the CERN book dataset using Solr's Data Import Hanlder (DIH). For the purpose of UI prototyping and testing, UX2 is incorporating the CERN dataset in combinant with existing digital library content held in a Fedora Commons repository. The rest of this post provides an account of the development of Solr, to enable metadata and rich binary documents (PDF, PowerPoints etc) from a Fedora repository, to be indexed for faceted search service.
This is also a technical report for JISC. If the content is too lengthy, you can skip to "Epilogue" to review the outputs directly.
Background, Requirement
Off-the-shelf, Fedora does not provide a production front-end, it is a Java-based service-oriented infrastructure upon which many resource discovery interfaces can be built - see a list of Web UI applications. We have developed a custom Fedora web front-end (in Java) and deployed Orbeon Forms to mediate user interactions in metadata and content management for a range of e-Science training resources.
UX2 adopted Blacklight as a main and enhanced resource discovery UI. Blacklight provides faceted search, and is based on Apache Solr, whereas Fedora facilitates a range resource discovery services but not faceted searching. As a result, it is necessary to import and index the existing Fedora content in Solr so that it is available through the Blacklight front-end. The following are required:
- Transforming Fedora objects to Solr documents conform to a pre-defined Solr Schema. This involves the transformation of Fedora XML and Dublin Core metadata, as well as text extraction of rich binary documents (pdf, doc, ppt etc.)
- Providing a mechanism to batch-index all Solr documents arising from the above transformation
- Synchronisation of the above requirement, i.e. automatically create an entry in Solr when a new object is added to the Fedora repository
These requirements have been addressed before, for example by the Muradora project through the Fedora-Solr integration plugin in 2008. The following class diagram depicts 3 Java classes from the plugin and how they associate with a previous version of Solr (version 1.3).
The implementation hinges on the extension of Solr's XmlUpdateRequestHandler class which handles search index updates via XML messages. XmlUpdateRequestHandler relies on the RequestHandlerBase class (implementing the SolrRequestHandler interface) to provide the underlying XML request/response marshalling and parameters parsing requirements.
FedoraUpdateRequestHandler in the Muradora plugin extends XmlUpdateRequestHandler and overrides a key method - handleRequestBody(). This method enables FedoraUpdateRequestHandler to intercept the default XML update messaging and addresses the Fedora-Solr integration requirement described above. For each Fedora object, the plugin facilitates basic update/create, delete commands - executable through REST/URL methods. The plugin can also batch-process a directory (local to the Solr server) containing Fedora XML objects recursively. FedoraHelper and TransformerToText both provide support mechanisms, e.g. retrieving data from a Fedora server and extracting text from rich binary documents.
New Development and System Architecture Change
Apache Solr is being developed actively. It has evolved significantly since 2008. The Muradora plugin no longer work with the current version of Solr (1.4) due to system architecture changes. There are also new built-in facilities such as the Data Import Handler described in Part 1 and SolrCell which handles requests for extracting text from rich binary document. The following diagram depicts the architecture changes.
The new version of Solr makes use of creational design patterns to decouple application logics in XML handling. In the new architecture, XmlUpdateRequestHandler no longer handle XML processing directly and implement the handleRequestBody() method, a mechanism upon which the Muradora plugin depends. Instead, the application logics have been remodelled using the Factory Method design pattern. This involves an abstract ContentStreamHandlerBase class which depends on a newLoader() (factory) method to spawn content handlers. The abstraction enables various forms of content handlers to be created, plugged-in and instantiated in a generic manner as the factory method defers instantiation to ContentStreamHandlerBase (concrete) subclasses. XmlUpdateRequestHandler is a subclass of ContentStreamHandlerBase as it implements newLoader(); the method calls a concrete XML handler - XMLLoader to process index updates according to the Solr XML update messages.
For the JISC UX2 project, I am testing the new features of Solr (SolrCell and DIH) and customsing the Blacklight UI in HTML5 using Haml/Sass. Blacklight provides an option to install a current version of Solr during its installation. UX2 also uncovered usability issues related to existing technological limitation of Solr, e.g. reversing the sort order of facet count. As a result, we need to keep abreast of the evolution of Solr and undertook new development for Fedora-Solr integration. The development is informed by the Muradora approach.
A straightforward approach to accomplish the new Fedora-Solr integration is by subclassing the XmlUpdateRequestHandler and XMLLoader, as shown below:
3 classes are involved in the new integration:
- FedoraXmlUpdateRequestHandler a concrete handler that implement the newLoader() factory method, pointing to an XML processor for Fedora content
- FedoraXMLLoader, the dedicated XML processor for Fedora content
- FedoraHelper.java, helper class for Fedora server interaction from the Muradora plugin. The modified class (cf. Muradora) does not contain the getDatastreamText() method (and hence the associated TransformerToText class) as the new integration now employs Solr's built-in rich binary document indexing facility as described below. Source Code
The simplest way to integrate the above classes in Solr is to make them part of the org.apache.solr.handler package, placing the files in the 'src/java/org/apache/solr/handler' directory of the Solr source base (see Part 1). Or you can package the classes in another package hierarchy and edit the Solr build file to include them in the classpath for compilation and other build targets.
Java Library Dependency: FedoraHelper depends on several Java libraries to communicate with a Fedora repository server. Prior to building (compiling) the source code, these Java libraries (.jar files) should be added to the 'lib' folder of the Solr home directory. An alternative is to place these jar files in another directory and edit the build file to include them in the compilation classpath.
The rest of the post will describe FedoraXmlUpdateRequestHandler and FedoraXMLLoader classes in detail, along with any related configuration setting in Solr.
FedoraXmlUpdateRequestHandler.java
Two key tasks of FedoraXmlUpdateRequestHandler:
- Initialisation: marshalling parameters related to Fedora server setting, e.g. service URL, username and password. These parameters are stored in the Solr config file as described below
- Implements the newLoader() factory method, to instantiate a FedoraXMLLoader object with the Fedora server parameters
Both are accomplished as below:
public class FedoraXmlUpdateRequestHandler extends XmlUpdateRequestHandler {
...
public void init(NamedList args) {
super.init(args);
fedoraServiceUrl = (String) args.get("serviceUrl");
fedoraUsername = (String) args.get("username");
fedoraPassword = (String) args.get("password");
trustStorePath = (String) args.get("trustStorePath");
trustStorePassword = (String) args.get("trustStorePass");
fedoraXslt = (String) args.get("fedoraXslt");
}
protected ContentStreamLoader newLoader(SolrQueryRequest req, UpdateRequestProcessor processor) {
return new FedoraXMLLoader(req, processor, inputFactory, fedoraServiceUrl, .. fedoraXslt);
}
}
- Full source code of FedoraXMLUpdateRequestHandler.java
The handler needs to be registered with the Solr server, along with the Fedora server parameters: add an entry in the Solr config file (solrconfig.xml):
<config>
...
<requestHandler name="/update_fedora" class="solr.FedoraXmlUpdateRequestHandler">
<str name="serviceUrl">http://localhost:8080/fedora/services</str>
<str name="username">a_fedora_username</str>
<str name="password">a_fedora_password</str>
<str name="fedoraXslt">foxmlToSolr.xsl</str>
</requestHandler>
...
</config>
The fedoraXslt parameter specifies the XSLT stylesheet which is used to convert Fedora XML and Dublin Core metadata into Solr XML (see below).
UX2 employs a multicore data architecture such that indexes from heterogeneous sources can be developed and maintained independently, before being merged into a single main production staging index using the CoreAdmin tools bundled with Solr. Each core is a fully-functional Solr index with its own configuration and schema XML files, as described in Part 1. UX2's multi-cores setup currently includes: fedora, cern (CERN Book Dataset), main (merged from fedora and cern cores). The configuration detail described in this post corresponds to the fedora core.
- solrconfig.xml for the Fedora core
FedoraXMLLoader.java
FedoraXMLLoader is the core of the Fedora-Solr integration. It processes custom XML messages for adding Fedora objects to Solr index, either as a single object or in batch. It is is a subclass of XMLLoader in Solr which is already processing XML update requests for Solr, e.g. the following request for adding multiple records (further details):
<add>
<doc>
<field name="title_display">Introduction to Grid Computing</field>
<field name="title_t">Introduction to Grid Computing</field>
<field name="author_facet">Mike Mineter</field>
</doc>
<doc>..</doc>
<doc>..</doc>
</add>
The XML processing is done through StAX parsing in XMLLoader, via the processUpdate() method. This involves XML being streamed (pulled) by the search engine which analyses and processes the update request tag-by-tag. For example, on encountering the 'doc' tag in the XML update message, XMLLoader begins building a Solr input document and subsequently adds it to the index. The FedoraXMLLoader subclass overrides the processUpdate() method to provide additional hooks to process custom XML update messages that deal with Fedora objects. The account below only shows code snippets of FedoraXMLLoader, for full source code:
1. Indexing a Fedora Object - fedoraId
The most basic form of update in the Fedora-Solr integration is the addition of an existing Fedora object to the search index. This can be achieved through the following simple XML message similar to the Solr 'add' command:
<add>
<fedoraId>lib:1368</fedoraId>
</add>
The FedoraXMLLoader override of processUpdate() include mechanism to deal with the fedoraID XML tag. The method retrieves proprietary information of an existing Fedora object, i.e. Fedora Object XML - FOXML, through the unique ID (pid) from the fedoraId tag. A FOXML consists of multiple data streams, one of which provides metadata of the Fedora object in Dublin Core (DC) Metadata format (ISO Standard 15836). In Solr, the DC metadata is transformed into a Solr input document through XSLT, e.g. creator (DC) field -> author_facet Solr field, as exemplified in the figure below. See Part 1 for the definition of various type of Solr fields. The XSLT stylesheet is configured in the solrconfig.xml file along with other Fedora server parameters. It should be placed in the 'conf/xsl' directory of a Solr core. The following is the XSLT stylesheet for UX2:
- foxmlToSolr.xsl - XSLT stylesheet for transforming FOXML DC metadata into a Solr doc according to the UX2.0 schema
The following are snippets of FedoraXMLLoader related to indexing of an existing Fedora object:
..
void processUpdate(UpdateRequestProcessor processor, XMLStreamReader parser)
...
else if ("fedoraId".equals(currTag)) {
try {
processFedoraObject(parser);
} catch (Exception e) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e.getMessage(), e);
}
}
...
}
/**
* Given the XML stream with a fedora ID, retrieve and tranform foxml from a fedora server
* into Solr Input document, and process it (add to index)
*/
private void processFedoraObject(XMLStreamReader parser) throws XMLStreamException, Exception {
String fedora_id = null;
while (true) {
int event = parser.next();
switch (event) {
case XMLStreamConstants.CHARACTERS:
// Get Fedora PID
fedora_id = parser.getText();
transformProcessObject(fedora_id);
break;
case XMLStreamConstants.END_ELEMENT:
return;
}
}
}
/**
* Retrieve foxml from a fedora server via FedoraHelper,
* transform it into a Solr input doc and re-send the document
* back to processUpdate to be processed as a Solr document
*/
private void transformProcessObject(String fedora_id) throws Exception {
byte[] foxml = fedoraHelper.getFoxmlFromPid(fedora_id);
InputStream foxml_stream = new ByteArrayInputStream(foxml);
StringWriter transformResult = new StringWriter();
// transform foxml metadata (DC) datastream into Solr document
foxml_transformer.transform(new StreamSource(foxml_stream), new StreamResult(transformResult));
ContentStreamBase stream = new ContentStreamBase.StringStream(transformResult.toString());
Reader reader = stream.getReader();
foxml_stream.close();
this.processUpdate(this.processor, inputFactory.createXMLStreamReader(reader));
}
2. Deleting a Fedora Object
To delete a Fedora object from the index, the Solr delete command can be used, for example via the unique ID of Fedora object:
<delete>
<id>lib:1368</id>
</delete>
Note: the above update request only removes the object from a Solr index. It does not remove the object from the Fedora repository.
3. Batch Indexing Fedora Objects - fedoraDir
The Muradora plugin can recursively index a folder of Fedora objects (foxml) located on the Solr server, enabling all objects from a Fedora repository to be indexed in one batch. In UX2.0, this mechanism is replicated through the following update message:
<add>
<fedoraDir>/full/path/to/the/fedora/object/directory</fedoraDir>
</add>
To enable the recursive indexing, the following codes are added to the FedoraXMLLoader's override of processUpdate() method along with 3 new supporting methods:
void processUpdate(UpdateRequestProcessor processor, XMLStreamReader parser)
...
else if ("fedoraDir".equals(currTag)) {
try {
processFedoraObjectsDirectory(parser);
} catch (Exception e) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e.getMessage(), e);
}
}
...
}
/**
* Given a directory of Fedora Objects, recursively retrieve and tranform the Fedora Object XML,
* into Solr Input and process it (add to index)
*/
private void processFedoraObjectsDirectory(XMLStreamReader parser) throws XMLStreamException, Exception {
String fedora_object_directory = null;
while (true) {
int event = parser.next();
switch (event) {
case XMLStreamConstants.CHARACTERS:
// Get Fedora Objects Directory
fedora_object_directory = parser.getText();
if (fedora_object_directory == null) throw new IllegalArgumentException("foxml directory cannot be null");
File fedora_object_file_directory = new File(fedora_object_directory);
transformProcessObjects(fedora_object_file_directory);
break;
case XMLStreamConstants.END_ELEMENT:
return;
}
}
}
/**
* Process a directory of Fedora Objects recursively and send FOXML files
* to transformProcessObject(file) to be transformed into Solr input documents
* and subsequently indexed
*/
private void transformProcessObjects(File fedora_object_directory) throws Exception {
if (fedora_object_directory.isDirectory()) {
String[] files = fedora_object_directory.list();
for (int i = 0; i < files.length; i++) {
transformProcessObjects(new File(fedora_object_directory, files[i]));
}
} else if (fedora_object_directory.isFile()) {
transformProcessObject(fedora_object_directory);
}
}
/**
* Transform a foxml file into a Solr input doc and re-send the document
* back to processUpdate to be processed as a solr document
*/
private void transformProcessObject(File fedoraxml) throws Exception {
if (fedoraxml.isHidden()) return;
InputStream foxml_stream = new FileInputStream(fedoraxml);
StringWriter transformResult = new StringWriter();
foxml_transformer.transform(new StreamSource(foxml_stream), new StreamResult(transformResult));
ContentStreamBase stream = new ContentStreamBase.StringStream(transformResult.toString());
Reader reader = stream.getReader();
foxml_stream.close();
this.processUpdate(this.processor, inputFactory.createXMLStreamReader(reader));
}
The implementation basically parses the fedoraDir tag content from the update request to determine the FOXML objects directory location. It then invokes the processFedoraObjectsDirectory() method to loop through the directory content recursively, and process any FOXML files in the same manner described above (transform the metadata into Solr fields etc.)
4. Rich Binary Documents Indexing, SolrCell
Apart from DC metadata, a Fedora object can contain multiple rich binary datastreams such as PDF, PowerPoint documents. These datastreams can either be stored locally on the Fedora server or referenced (URL) objects, linked to via URLs. This post has so far focused on the indexing of metadata to underpin faceted search service. These metadata fields can also be searched in combinant via a catch-all field specified in a Solr schema - see the text field in UX2 schema. Another ubiquitous form of searching involves the textual content extracted from websites and rich binary documents, e.g. fulltext, 'search within', web search (Google) services. Off-the-shelf, the new version of Solr (1.4) provides a facility for extracting text content of rich binary documents - 'SolrCell'.
I have experimented with SolrCell by sending Fedora object datastreams to it, targeting the following multi-core architecture:
- metadata core, index created from Fedora object's Dublin Core metadata datastream
- fulltext core, index of rich binary documents created by SolrCell from the other Fedora objects datastreams
- fedora core, the main staging index merged from the above (metadata + fulltext)
The merged (main) index produced by the CoreAmin tool proved to be less than ideal. This is because the merge tool assumes the cores to be mutually exclusive of each others and derived from different data sources. It simply combines the indexes in a Boolean OR manner to produce an index containing a superset of both cores. Instead of aggregating the metadata and fulltext fields of a particular object into a single index item, two entries are produced for a single Fedora object in the merged index.
An alternative approach is to utilise SolrCell's capability directly within FedoraXMLLoader to index both metadata and rich binary datastreams at the same time, during the process of indexing Fedora objects (1 to 3 above). This involves enhancing the development discussed so far and the use of Java libraries and APIs which underpin SolrCell - Apache Tika for a range of rich binary documents.
This approach requires a fulltext Solr field to be added to the Solr schema, to delineate the following search options:
- metadata fields and faceted search, via various Solr fields specified in the schema (author, subject, title etc.)
- fulltext search of rich binary documents (only), via a fulltext field
- catch-all search field for all metadata fields plus fulltext, via the standard Solr text field
The fulltext and the catch-all text fields can be specified as below:
<schema>
...
<fields>
...
<field name="text" type="text" indexed="true" stored="false" multiValued="true"/>
<field name="fulltext" type="text" indexed="true" stored="false" multiValued="true"/>
<dynamicField name="*_t" type="text" indexed="true" stored="false" multiValued="true"/>
...
</fields>
...
<copyField source="*_t" dest="text"/>
<copyField source="fulltext" dest="text"/>
</schema>
The dynamicField declaration enables various metadata fields to be created, for example "author _ t", "title _ t" etc. The copyField declarations instruct Solr to duplicate and aggregate all data associated with the dynamic text fields ("_t") and the fulltext field in the text field to provide the catch-all effect.
To use Apache Tika libraries directly, it also is necessary to modify the Solr build file to include the libraries (jar files in ~/solr/contrib/extraction/lib) in the classpath for code compilation and Solr web application (WAR file) creation:
<project name="solr" default="usage" basedir="." xmlns:artifact="antlib:org.apache.maven.artifact.ant">
...
<!-- SolrCell/Tika libraries for binary documents indexing -->
<property name="extraction-libs" location="contrib/extraction/lib" />
...
<!-- The compilation classpath -->
<path id="compile.classpath">
...
<!-- include java libraries for binary documents indexing -->
<fileset dir="${extraction-libs}">
<include name="*.jar" />
</fileset>
...
</path>
...
<!-- Creates the Solr WAR file. -->
<target name="dist-war"..>
...
<war destfile="${dist}/${fullnamever}.war"..>
...
<!-- include java libraries for binary documents indexing -->
<lib dir="${extraction-libs}"/>
...
</war>
</target>
...
</project>
- Modified Solr build file: build.xml
Since the rich binary datastreams in Fedora are accessible via HTTP, they can be parsed and processed as URLs in FedoraXMLLoader. The datastreams are marked with a control group attribute of 'M' and 'R' in FOXML (details). The datastream URLs can therefore be inferred from the FOXML-DC metadata transformation process during Fedora objects indexing. An approach to creating these URLs is to employ the same metadata mapping stylesheet (foxmlToSolr.xsl), with the following additional XSLT:
<xsl:if test="foxml:datastream[@CONTROL_GROUP='M']">
<xsl:for-each select="foxml:datastream[@CONTROL_GROUP='M']">
<xsl:variable name="content_url"><xsl:value-of select="foxml:datastreamVersion[last()]/foxml:contentLocation[ @TYPE='INTERNAL_ID']/@REF"/></xsl:variable>
<xsl:choose>
<xsl:when test="starts-with($content_url, 'http')">
<datastream><xsl:value-of select="$content_url"/></datastream>
</xsl:when>
<xsl:otherwise>
<datastream><xsl:value-of select="$fedoraHost"/>/get/<xsl:value-of select="$PID"/>/<xsl:value-of select="@ID"/></datastream>
</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
</xsl:if>
<xsl:if test="foxml:datastream[@CONTROL_GROUP='R']">
<xsl:for-each select="foxml:datastream[@CONTROL_GROUP='R']">
<xsl:variable name="content_url"><xsl:value-of select="foxml:datastreamVersion[last()]/foxml:contentLocation[ @TYPE='INTERNAL_ID']/@REF"/></xsl:variable>
<xsl:if test="starts-with($content_url, 'http')">
<datastream><xsl:value-of select="$content_url"/></datastream>
</xsl:if>
</xsl:for-each>
</xsl:if>
While mapping DC metadata to Solr index fields, the above XSLT processes the rich binary datastreams and inserts interim 'datastream' tags encapsulating datastream URLs in the 'add' request:
These interim URLs enable FedoraXMLLoader to create a Solr fulltext field element through the text extraction APIs from Apache Tika. The fulltext field is subsequently added to the Solr index. Because datastream is not a standard field in Solr, it is necessary to override the readDoc() method of the parent XMLLoader class. readDoc() handles the 'doc' element of the Solr update request. It creates specific index fields according to the field elements and add the fields to the index through the addField() method. The override is as below:
/**
* Given the input stream, read a document
* Based on the XMLLoader.readDoc, adding methods to parse rich binary documents,
* create a fulltext 'text' field containing the extracted text, add the field to Solr doc.
* This method makes use of the Tika java libraries from the SolrCell
* fulltext indexing capability (in contrib/extraction)
*/
SolrInputDocument readDoc(XMLStreamReader parser) throws XMLStreamException {
SolrInputDocument doc = new SolrInputDocument();
...
// Additional parameters for parsing datastream for binary
// documents/fulltext indexing
String datastreamMimetype = null;
URL datastreamUrl = null;
URLConnection datastreamConnection = null;
InputStream datastream = null;
ContentHandler textHandler = null;
AutoDetectParser richDocParser = new AutoDetectParser();
// StAX XML parsing
while (true) {
int event = parser.next();
switch (event) {
...
case XMLStreamConstants.END_ELEMENT:
if ("doc".equals(parser.getLocalName())) {
return doc;
} else if ("field".equals(parser.getLocalName())) {
if (!isNull) {
doc.addField(name, text.toString(), boost);
boost = 1.0f;
}
} else if ("datastream".equals(parser.getLocalName())) {
try {
datastreamUrl = new URL(text.toString());
datastreamConnection = datastreamUrl.openConnection();
datastreamMimetype = datastreamConnection.getContentType();
if (datastreamMimetype.equals("image/jpeg") || datastreamMimetype.equals("audio/mpeg")) continue;
datastream = datastreamConnection.getInputStream();
textHandler = new BodyContentHandler(-1); // -1 to disable text limit
Metadata metadata = new Metadata();
richDocParser.parse(datastream, textHandler, metadata);
// Add a Solr fulltext field containing the extracted text
doc.addField("fulltext", textHandler.toString(), boost);
boost = 1.0f;
} catch (MalformedURLException e) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, ...);
} catch (IOException e) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
} catch (SAXException e) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
} catch (TikaException e) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, ...);
} finally {
IOUtils.closeQuietly(datastream);
}
}
break;
...
}
}
}
During the StAX XML processing, FedoraXMLLoader.readDoc() when encountering a datastream element, would parse the rich binary document via the URL with Apache Tika's AutoDetectParser() (richDocParser). The parser enables the textual content of the datastream to be extracted and added to a fulltext Solr field for processing later.
- FedoraXMLLoader.java full source code
Epilogue
Here is a list of the source code and config files described in this post along with their respective home in Solr source base:
- FedoraHelper.java, FedoraXMLUpdateRequestHandler.java, FedoraXMLLoader.java (~/apache-home/solr/src/java/org/apache/solr/handler)
- Various jar files required by FedoraHelper.java (~/apache-home/solr/lib)
- foxmlToSolr.xsl XSLT stylesheet (~/apache-home/solr/example/solr/conf/xslt)
- schema.xml, solrconfig.xml (~/apache-home/solr/example/solr/conf/)
- build.xml (~/apache-home/solr/)
To incorporate the Solr-Fedora integration, download the above files to their respective directories in a Solr base, modify them for a different Fedora setup (e.g. the XSLT stylesheet for a different metadata schema, server details) and recompile the source.
Assuming a local Solr instance running on its standard port, the following are some examples of how you can use curl at command line, to initiate indexing of a single object or a batch of objects held in a directory local to the Solr server.
You can also send the equivalent update requests via GET URL requests.
Thanks!
Comments