On 3/15/07, Michael Baessler <[EMAIL PROTECTED]> wrote:
Currently it is not possible to run an installed pear file out of the box in UIMA. I mean by just specifying the pear installation path or something similar. To run installed pear files there is a lot of user configuration and implementation necessary. So it would be nice to have a UIMA pear runtime that can run an installed pear file out of the box.
+1.
With the suggestion of having custom resource specifiers <customResourceSpecifier> we can provide an easy way to integrate such a UIMA pear runtime. We just have to implement a new PearAnalysisEngineWrapper that extends the AnalysisEngineImplBase class that knows how to start an installed pear file. All the necessary information is available and can be parsed from the metadata of the installed pear. The utilities, e.g. to dynamically load the classes (UIMA extension class loader) is also in place and can be used. So an example of the <customResourceSpecifier> can look like: <customResourceSpecifier xmlns="http://uima.apache.org/resourceSpecifier";> <resourceClassName>org.apache.PearAnalyisEngineWrapper</resourceClassName> <parameters> <parameter name="installedPear" value="/path/to/the/root/directory/of/the/installed/pear/file"/> <!-- and additional parameters if necessary --> </parameters> </customResourceSpecifier> This solution will also work out of the box in our tooling. The tools does not have to implement a PEAR runtime engine itself. Do we have any limitations when implementing this approach?
I think there may be a problem with the JCas classes if your adapter uses a different ClassLoader for the AnalysisEngine in the PEAR than the ClassLoader that's being used by the calling aggregate/application. When a CAS is created it has to be told what ClassLoader it will use to locate JCas classes. If the PEAR ClassLoader is known only inside the PearAnalysisEngineWrapper, this will not be available to the CAS and the classes can't be loaded. This could be addressed using CAS serialization. So the PearAnalysisEngineWrapper would create its own CAS with the correct ClassLoader. When it's process method was called it would need to serialize the input CAS and deserialize it into its "private" CAS before calling the wrapped AE. It would have to serialize on the way back as well. So there's a performance penalty, but it's still better than nothing. I really like the fact that this would allow existing UIMA tools like DocumentAnalyzer to execute PEARs. -Adam
