ConceptMapper: tokenizer doesn't get PEAR classpath

[Jens Grivolla <j+...@grivolla.net>]

Hi,

when using the ConceptMapper from addons as a PEAR we are having 
classpath problems.  The ConceptMapper launches a tokenizer AE using its 
XML descriptor, but at that point the classpath set from the PEAR does 
not get used.

This means that it is impossible to point to a tokenizer packaged 
together with the CM based AE, or it is at least necessary to add the 
tokenizer classes (or jar) as well as all of its dependencies to the 
global classpath.

It all seems to come down to (AnnotatorAdapter.java:97):
ae = UIMAFramework.produceAnalysisEngine(aeSpecifier);

But I don't see why the classpath that is used by the ConceptMapper 
would not apply here. It must have to do with how the classpath is 
adjusted "locally" for PEARs instead of being global to the whole JVM, 
but I haven't been able to figure it out yet.

Any ideas?

Thanks,
Jens

Re: ConceptMapper: tokenizer doesn't get PEAR classpath

[Marshall Schor <ms...@schor.com>]

On 3/2/2012 11:03 AM, Jens Grivolla wrote:
> Hi,
>
> when using the ConceptMapper from addons as a PEAR we are having classpath 
> problems.  The ConceptMapper launches a tokenizer AE using its XML descriptor, 
> but at that point the classpath set from the PEAR does not get used.

That is correct.

>
> This means that it is impossible to point to a tokenizer packaged together 
> with the CM based AE, or it is at least necessary to add the tokenizer classes 
> (or jar) as well as all of its dependencies to the global classpath.

There are some other possibilities.  One is to package the tokenizer as a PEAR 
and install it also, and then update the parameter which specifies the UIMA 
pipeline to run for tokenization to be a pearSpecifier.  In this case, the 
tokenizer would run with its classpath.

>
> It all seems to come down to (AnnotatorAdapter.java:97):
> ae = UIMAFramework.produceAnalysisEngine(aeSpecifier);
>
Right.
> But I don't see why the classpath that is used by the ConceptMapper would not 
> apply here. It must have to do with how the classpath is adjusted "locally" 
> for PEARs instead of being global to the whole JVM, but I haven't been able to 
> figure it out yet.

I think this is because the framework sets up a special class loader for the 
classes loaded by the PEAR's implementation class.  However, in this case that 
implementation class calls the UIMA Framework to produce an analysis engine - so 
the loader used for that is the one the UIMA Framework has.

I'm pretty sure it is possible to change the design of how Concept Mapper works, 
to have the tokenizer inherit the classpath (actually, the Resource Manager) of 
the Concept Mapper.  If done, this would have potential other implications - for 
example, it would be possible to have an external resource specification that 
was shared between the tokenizer and the Concept Mapper (and, indeed, if the 
Concept Mapper was contained in some outer UIMA Aggregate, with any annotator in 
that Aggregate.

This fix would entail capturing the resource manager instance that the concept 
mapper is running with, and passing that in to the framework call to produce the 
tokenizer resource.

Do people think this would be a good change or does it make things too complicated?

-Marshall
>
> Any ideas?
>
> Thanks,
> Jens
>
>