Thanks for creating the case to track the requirement.
I really don't agree with your comments about using relative paths though.
The only way to specify the AE's making up an aggregate AE is to use a
"<import location ...>",
leaving you to choose either a absolute, relative, or a URL. All of
these are not that great.
You are not allowed to use environment variables. The UIMA documentation
clearly states
that relative paths are relative with respect to the location of the
descriptor containing the import.
That is the way in which XMLInputSource works. Solr's
OverridingParamsAEProvider, in my opinion,
is clearly broken. If it wants to suck a descriptor out of a jar then it
MUST call XMLInputSource using
the signature in with both the descriptor name AND the path to the jar
containing are passed in so
that XMLInputSource knows how to process the descriptor.
Barry
On 5/6/2011 8:47 AM, Tommaso Teofili wrote:
Barry, I understand your need and I agree with you it'd be useful to be able
to load AEs also from filesystem, I created SOLR-2501 [1] to track that
requirement.
Consider that loading AEs from relative paths, as using relative paths in
general, is not a good practice since different environments could set the
relative path "start" at different points in the filesystem; I think a good
solution would be using the solr.home as the root of a relative path because
that is a Solr instance/core property.
Regards,
Tommaso
[1] : https://issues.apache.org/jira/browse/SOLR-2501
2011/5/5 Barry Hathaway<bhath...@nycap.rr.com>
Tommaso,
Thanks. Now Solr finds the descriptor; however, I think this is very bad
practice.
Descriptors really aren't meant to be jarred up. They often contain
relative paths.
For example, in my case I have a directory that looks like:
appassemble
|- desc
|- pear
where the AnalysisEngine descriptor contained in desc is an aggregate
analysis engine and
refers to other analysis engines packaged as installed PEAR files in the
pear subdirectory.
As such, the descriptor contains relative paths pointing into the pear
subdirectory.
Grabbing the descriptor from the jar breaks that since
OverridingParamsAEProvider
uses the XMLInputSource method without relative path signature.
Barry
On 5/4/2011 6:16 AM, Tommaso Teofili wrote:
Hello Barry,
the main AnalysisEngine descriptor defined inside the<analysisEngine>
element should be inside one of the jars imported with the<lib> elements.
At the moment it cannot be taken from expanded directories but it should
be
easy to do it (and indeed useful) modifying the
OverridingParamsAEProvider class
[1] at line 57.
Hope this helps,
Tommaso
[1] :
http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_3_1/solr/contrib/uima/src/main/java/org/apache/solr/uima/processor/ae/OverridingParamsAEProvider.java?view=markup
2011/5/3 Barry Hathaway<bhath...@nycap.rr.com>
I'm new to Solr and trying to get it call a UIMA aggregate analysis
engine
and not having much luck.
The null pointer exception indicates that it can't find the xml file
associated with the engine.
I have tried a number of combinations of a path in the<analysisEngine>
element, but nothing
seems to work. In addition, I've put the directory containing the
descriptor in both the classpath
when starting the server and in a<lib> element in solrconfig.xml. So:
What "classpath" does the<analysisEngine> tag effectively search for to
locate the descriptor?
Do the<lib> entries in solrconfig.xml affect this classpath?
Do the engine descriptors have to be in a jar or can they be in an
expanded
directory?
Thanks in advance.
Barry
