You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Michael Baessler <mb...@michael-baessler.de> on 2007/03/15 18:59:39 UTC
UIMA pear runtime
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.
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?
Thoughts?
-- Michael
Re: UIMA pear runtime
Posted by Michael Baessler <mb...@michael-baessler.de>.
Adam Lally wrote:
> Michael, I was looking over PearAnalysisEngineWrapper.java and I think
> there's something missing.
>
> When you create your CAS you aren't telling it the ClassLoader for the
> PEAR. So if JCAS were used and the JCas classes were in the PEAR, I
> think you would get class not found exceptions. Have you tried a JCAS
> annotator with this?
> The way to tell the CAS about the ClassLoader is to pass the
> ResourceManager (the same one you passed to produceAnalysisEngine) to
> the CasCreationUtils.createCas call. It's an optional argument you
> can add in addition to the arguments you're already passing.
You are right, without the fix the processing of JCas annotators fails.
I checked in the new version
that also supports JCas annotators.
Thanks!
-- Michael
Re: UIMA pear runtime
Posted by Adam Lally <al...@alum.rpi.edu>.
Michael, I was looking over PearAnalysisEngineWrapper.java and I think
there's something missing.
When you create your CAS you aren't telling it the ClassLoader for the
PEAR. So if JCAS were used and the JCas classes were in the PEAR, I
think you would get class not found exceptions. Have you tried a JCAS
annotator with this?
The way to tell the CAS about the ClassLoader is to pass the
ResourceManager (the same one you passed to produceAnalysisEngine) to
the CasCreationUtils.createCas call. It's an optional argument you
can add in addition to the arguments you're already passing.
-Adam
Re: UIMA pear runtime
Posted by Michael Baessler <mb...@michael-baessler.de>.
Adam Lally wrote:
> 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.
So, with the current implementation I tested some different ways to do
the CAS serialization/deserialization.
The fastest one seems to be the blob serialization using a byte array.
But it seems that this serialization/deserialization either has a bug
or I do something wrong.
Adam or Eddie, can you please look at the code in
PearAnalysisEngineWrapper.java if the serialization/deserialization is
correct?
If I use the fastest serialization and run an installed pear using CVD I
see after the processing of the pear file a view that is called:
"_InitialView" and another one that is called " _InitialVie". Also the
document language is not correct after the processing it is " n" instead
of "en".
If I use the other serialization all works fine!
-- Michael
Re: UIMA pear runtime
Posted by Marshall Schor <ms...@schor.com>.
Michael Baessler wrote:
> Adam Lally wrote:
>> On 3/21/07, Michael Baessler <mb...@michael-baessler.de> wrote:
>>> Let me understand the real issue here. When the CAS is created it
>>> gets a
>>> ClassLoader that is used to located the JCas classes.
>>> As far as I know, the CAS stores the references to the JCas classes,
>>> right?
>>
>> Yes.
>>
>>> So when the aggregate creates these references in the CAS the pear
>>> runtime wrapper with the UIMAClassLoader cannot use it's own JCas
>>> classes since they are
>>> not referenced in the CAS. Is that also right? So it would be nice if
>>> the JCas references in the CAS can be changed later, will that be
>>> possible?
>>>
>>> If true, will it be possible to provide a CAS.reinitialize(ClassLoader)
>>> method to reinitialize the JCas classes in the CAS when the ClassLoader
>>> changed?
>>> This method can either be called by an application or by the UIMA pear
>>> runtime wrapper.
>>>
>>> With that, will it be possible to provide a JCas reference map within
>>> the CAS for each ClassLoader that is passed to the CAS? In that case we
>>> can just switch the JCas references when the ClassLoader changed and
>>> must not reinitialize everything again except the first time.
>>>
>>> What do you think?
>>>
>>
>> In theory it seems possible, Marshall would have to comment on how
>> difficult it is.
>>
>> There's a further complication which is that JCas-generated class
>> _instances_ are also cached in the JCas object. So if an JCas-based
>> annotator creates an annotation Java object, and the application later
>> uses an iterator to retrieve that object, it would get the same Java
>> object back. Obviously this won't work if the application and
>> annotator don't share the same ClassLoader for accessing that class.
>>
>> We could work around that, too, by clearing out the cache if the
>> ClassLoader changes, or using a different cache for each ClassLoader.
>> This wouldn't allow sharing additional data in Java fields that were
>> manually added to the JCas-generated class, although that doesn't work
>> when serialization is involved anyway, so may not be a big loss.
>>
>> There's a lot of additional complexity involved in doing this. Is it
>> worth it? I'm not sure.
> Hi Marshall, can you please comment this. Will that be possible or
> does it have any impact?
Sorry for the late commenting on this.
Let me restate what seems to me to be the goal. In a UIMA application,
there is a top level descriptor - be it a CPE descriptor, or a top level
aggregate. The goal is to allow one or more of the delegates or CAS
processors (for a CPE) to be specified as a PEAR file, which in turn
could be an aggregate or primitive analysis engine.
There may (or may not) be an additional goal of allowing one version of
JCas cover classes for CAS types to be used by the PEAR
aggregate/primitive, and a different version of those JCas cover classes
to be used by the rest of the UIMA application.
It seems to me this, although do-able, is expensive (in terms of
performance/space), and I would guess this isn't a real need. (If it is
a real need, there is always a fall-back - deploying the PEAR as a
"service", implying all the serialization/deserialization of CASes being
sent and returned from it.)
If this is not a real need, then the "assembler" who is assembling the
pipeline using PEAR and non-PEAR things would need to check that the
JCas cover classes being used were the same implementation.
If that were the case, the UIMA framework support for running PEARs as
components in a pipeline could, when setting up the pipeline, ask the
PEAR for its classpath, and include that in the overall class path it is
setting up for the pipeline, and specify the combined classpath in the
resourcemanager, when it sets up the CAS initially.
Would this address the issues raised? (I've probably not quite followed
what it is you're trying to do, so please clarify :-)
-Marshall
>
> Thanks Michael
>
>
>
Re: UIMA pear runtime
Posted by Michael Baessler <mb...@michael-baessler.de>.
Adam Lally wrote:
> On 3/21/07, Michael Baessler <mb...@michael-baessler.de> wrote:
>> Let me understand the real issue here. When the CAS is created it gets a
>> ClassLoader that is used to located the JCas classes.
>> As far as I know, the CAS stores the references to the JCas classes,
>> right?
>
> Yes.
>
>> So when the aggregate creates these references in the CAS the pear
>> runtime wrapper with the UIMAClassLoader cannot use it's own JCas
>> classes since they are
>> not referenced in the CAS. Is that also right? So it would be nice if
>> the JCas references in the CAS can be changed later, will that be
>> possible?
>>
>> If true, will it be possible to provide a CAS.reinitialize(ClassLoader)
>> method to reinitialize the JCas classes in the CAS when the ClassLoader
>> changed?
>> This method can either be called by an application or by the UIMA pear
>> runtime wrapper.
>>
>> With that, will it be possible to provide a JCas reference map within
>> the CAS for each ClassLoader that is passed to the CAS? In that case we
>> can just switch the JCas references when the ClassLoader changed and
>> must not reinitialize everything again except the first time.
>>
>> What do you think?
>>
>
> In theory it seems possible, Marshall would have to comment on how
> difficult it is.
>
> There's a further complication which is that JCas-generated class
> _instances_ are also cached in the JCas object. So if an JCas-based
> annotator creates an annotation Java object, and the application later
> uses an iterator to retrieve that object, it would get the same Java
> object back. Obviously this won't work if the application and
> annotator don't share the same ClassLoader for accessing that class.
>
> We could work around that, too, by clearing out the cache if the
> ClassLoader changes, or using a different cache for each ClassLoader.
> This wouldn't allow sharing additional data in Java fields that were
> manually added to the JCas-generated class, although that doesn't work
> when serialization is involved anyway, so may not be a big loss.
>
> There's a lot of additional complexity involved in doing this. Is it
> worth it? I'm not sure.
Hi Marshall, can you please comment this. Will that be possible or does
it have any impact?
Thanks Michael
Re: UIMA pear runtime
Posted by Adam Lally <al...@alum.rpi.edu>.
On 3/21/07, Michael Baessler <mb...@michael-baessler.de> wrote:
> Let me understand the real issue here. When the CAS is created it gets a
> ClassLoader that is used to located the JCas classes.
> As far as I know, the CAS stores the references to the JCas classes, right?
Yes.
> So when the aggregate creates these references in the CAS the pear
> runtime wrapper with the UIMAClassLoader cannot use it's own JCas
> classes since they are
> not referenced in the CAS. Is that also right? So it would be nice if
> the JCas references in the CAS can be changed later, will that be possible?
>
> If true, will it be possible to provide a CAS.reinitialize(ClassLoader)
> method to reinitialize the JCas classes in the CAS when the ClassLoader
> changed?
> This method can either be called by an application or by the UIMA pear
> runtime wrapper.
>
> With that, will it be possible to provide a JCas reference map within
> the CAS for each ClassLoader that is passed to the CAS? In that case we
> can just switch the JCas references when the ClassLoader changed and
> must not reinitialize everything again except the first time.
>
> What do you think?
>
In theory it seems possible, Marshall would have to comment on how
difficult it is.
There's a further complication which is that JCas-generated class
_instances_ are also cached in the JCas object. So if an JCas-based
annotator creates an annotation Java object, and the application later
uses an iterator to retrieve that object, it would get the same Java
object back. Obviously this won't work if the application and
annotator don't share the same ClassLoader for accessing that class.
We could work around that, too, by clearing out the cache if the
ClassLoader changes, or using a different cache for each ClassLoader.
This wouldn't allow sharing additional data in Java fields that were
manually added to the JCas-generated class, although that doesn't work
when serialization is involved anyway, so may not be a big loss.
There's a lot of additional complexity involved in doing this. Is it
worth it? I'm not sure.
-Adam
Re: UIMA pear runtime
Posted by Michael Baessler <mb...@michael-baessler.de>.
Adam Lally wrote:
> 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.
Let me understand the real issue here. When the CAS is created it gets a
ClassLoader that is used to located the JCas classes.
As far as I know, the CAS stores the references to the JCas classes, right?
So when the aggregate creates these references in the CAS the pear
runtime wrapper with the UIMAClassLoader cannot use it's own JCas
classes since they are
not referenced in the CAS. Is that also right? So it would be nice if
the JCas references in the CAS can be changed later, will that be possible?
If true, will it be possible to provide a CAS.reinitialize(ClassLoader)
method to reinitialize the JCas classes in the CAS when the ClassLoader
changed?
This method can either be called by an application or by the UIMA pear
runtime wrapper.
With that, will it be possible to provide a JCas reference map within
the CAS for each ClassLoader that is passed to the CAS? In that case we
can just switch the JCas references when the ClassLoader changed and
must not reinitialize everything again except the first time.
What do you think?
-- Michael
Re: UIMA pear runtime
Posted by Adam Lally <al...@alum.rpi.edu>.
On 3/15/07, Michael Baessler <mb...@michael-baessler.de> 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
Re: problem with the hotfix CDE
Posted by Adam Lally <al...@alum.rpi.edu>.
On 5/8/07, Scott Songlin Piao <sc...@manchester.ac.uk> wrote:
> Hi,
>
> I came cross a problem with org.apache.uima.desceditor.2.1.0.incubating-hotfix-1 when porting my UIMA programs from the ibm 2.0.0 to apache uima.
>
> To make an aggregate AE, I added a remote Soap AE service using the "Add Remote" function of the CDE, then I got error message:
>
> "The Resource Factory foes not know how to create a resource of class org.apache.uima.resource.Resource from the given ResourceSpecifier. (Descriptor: file_path...)"
>
> The descriptor passed is a very simple Soap service descriptor. And when I tried it with UIMA Document Analyzer tool, it worked well. Just the CDE keeps throwing this error message. It didn't happen either with the old CDE.
>
> Does anyone know why this happens and how to solve this problem?
>
Hi Scott,
I can reproduce this problem and opened a JIRA issue for it:
https://issues.apache.org/jira/browse/UIMA-402
I don't know the cause yet but I'll take a look.
-Adam
Re: UIMA pear runtime
Posted by Michael Baessler <mb...@michael-baessler.de>.
Adam Lally wrote:
> On 5/4/07, Michael Baessler <mb...@michael-baessler.de> wrote:
>> OK I implemented the following pearSpecifier resource:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <pearSpecifier xmlns="http://uima.apache.org/resourceSpecifier">
>> <resourceType>InstalledPear</resourceType>
>> <pearPath>/home/test/WhitespaceTokenizer</pearPath>
>> </pearSpecifier>
>>
>> The resourceType is the type of the pear archive we use. So maybe in the
>> future we can also work on archived pear files that do not have to be
>> installed before.
>
> Just a minor comment here, <resourceType> is used in the URI Specifier
> to mean something different. It is set to either AnalysisEngine or
> CasConsumer to indicate what kind of component is expected at the
> other end of the service. You are using it differently here so maybe
> give it a different name? Maybe even <installed>true</installed>, or
> leave it out for now entirely until uninstalled pears are supported.
I commit the code without the <resourceType> tag I may add later an
<installed> tag when we need them.
Re: UIMA pear runtime
Posted by Adam Lally <al...@alum.rpi.edu>.
On 5/4/07, Michael Baessler <mb...@michael-baessler.de> wrote:
> OK I implemented the following pearSpecifier resource:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <pearSpecifier xmlns="http://uima.apache.org/resourceSpecifier">
> <resourceType>InstalledPear</resourceType>
> <pearPath>/home/test/WhitespaceTokenizer</pearPath>
> </pearSpecifier>
>
> The resourceType is the type of the pear archive we use. So maybe in the
> future we can also work on archived pear files that do not have to be
> installed before.
Just a minor comment here, <resourceType> is used in the URI Specifier
to mean something different. It is set to either AnalysisEngine or
CasConsumer to indicate what kind of component is expected at the
other end of the service. You are using it differently here so maybe
give it a different name? Maybe even <installed>true</installed>, or
leave it out for now entirely until uninstalled pears are supported.
> The pearPath is the path to the installed pear root directory. If we
> decide to work also on archived pear files, this path can also be a
> valid pear archive file path.
>
> Additionally the pearSpecifier can have parameters like
> <parameters>
> <parameter name="ParamName" value="ParamValue"/>
> </parameters>
> but currently I don't see the need for this.
>
> I also added the necessary methods for the ResourceSpecifierFactory and
> for the XMLParser.
>
> Additionally to the new pearSpecifier stuff I added an extra step in the
> pear installation api to automatically create a pearSpecifier when a
> pear file is installed.
> So after the installation of a pear file in the main root directory of
> the installed pear there is a descriptor called <componendID>_pear.xml
> that can be used
> to easily run the installed pear file unsing CVD or any other UIMA
> tooling. With this, no classpath changes or anything else is necessary
> to run the pear. The created descriptor can also be used to add it to an
> aggregate that should contain the pear.
>
> With these changes I think the pear stuff is more attractive to use than
> before.
>
Agreed. Nice work.
-Adam
problem with the hotfix CDE
Posted by Scott Songlin Piao <sc...@manchester.ac.uk>.
Hi,
I came cross a problem with org.apache.uima.desceditor.2.1.0.incubating-hotfix-1 when porting my UIMA programs from the ibm 2.0.0 to apache uima.
To make an aggregate AE, I added a remote Soap AE service using the "Add Remote" function of the CDE, then I got error message:
"The Resource Factory foes not know how to create a resource of class org.apache.uima.resource.Resource from the given ResourceSpecifier. (Descriptor: file_path...)"
The descriptor passed is a very simple Soap service descriptor. And when I tried it with UIMA Document Analyzer tool, it worked well. Just the CDE keeps throwing this error message. It didn't happen either with the old CDE.
Does anyone know why this happens and how to solve this problem?
Best regards
Scott
Re: UIMA pear runtime
Posted by Michael Baessler <mb...@michael-baessler.de>.
Adam Lally wrote:
> On 5/2/07, Michael Baessler <mb...@michael-baessler.de> wrote:
>> After doing most of the UIMA pear runtime work... I would like to
>> suggest something else that came to my mind when implementing the pear
>> runtime.
>>
>> Currently we work with a customResourceSpecifier. I would like to change
>> that to a real pearSpecifier.
>
> OK with me.
OK I implemented the following pearSpecifier resource:
<?xml version="1.0" encoding="UTF-8"?>
<pearSpecifier xmlns="http://uima.apache.org/resourceSpecifier">
<resourceType>InstalledPear</resourceType>
<pearPath>/home/test/WhitespaceTokenizer</pearPath>
</pearSpecifier>
The resourceType is the type of the pear archive we use. So maybe in the
future we can also work on archived pear files that do not have to be
installed before.
The pearPath is the path to the installed pear root directory. If we
decide to work also on archived pear files, this path can also be a
valid pear archive file path.
Additionally the pearSpecifier can have parameters like
<parameters>
<parameter name="ParamName" value="ParamValue"/>
</parameters>
but currently I don't see the need for this.
I also added the necessary methods for the ResourceSpecifierFactory and
for the XMLParser.
Additionally to the new pearSpecifier stuff I added an extra step in the
pear installation api to automatically create a pearSpecifier when a
pear file is installed.
So after the installation of a pear file in the main root directory of
the installed pear there is a descriptor called <componendID>_pear.xml
that can be used
to easily run the installed pear file unsing CVD or any other UIMA
tooling. With this, no classpath changes or anything else is necessary
to run the pear. The created descriptor can also be used to add it to an
aggregate that should contain the pear.
With these changes I think the pear stuff is more attractive to use than
before.
Any comments or issues on this? If not I will check in the code to SVN.
-- Michael
Re: UIMA pear runtime
Posted by Adam Lally <al...@alum.rpi.edu>.
On 5/2/07, Michael Baessler <mb...@michael-baessler.de> wrote:
> After doing most of the UIMA pear runtime work... I would like to
> suggest something else that came to my mind when implementing the pear
> runtime.
>
> Currently we work with a customResourceSpecifier. I would like to change
> that to a real pearSpecifier.
OK with me.
-Adam
AW: UIMA pear runtime
Posted by Torsten Zesch <ze...@tk.informatik.tu-darmstadt.de>.
> > My thinking is that "pear runtime" is more closer to the " tooling"
> > than the
> > "framework". It is hard to draw the boundary. Also, there are many
> > runtimes
> > that UIMA can/may support.
> > I don't think that we should do something too specific to the "pear
> > runtime".
> If I look from a UIMA users perspective I see that there is something
> that is called pear to package annotators and UIMA components but
> there is no way to easy run these packaged components in the UIMA
> runtime later. So that's why I think the core framework should have
> a pear runtime integration and API to run these pear packages
> out of the
> box without doing anything manually after the pear installation.
>
> -- Michael
This seems more to be about "What do users really want?", thus I am
going to comment on this, even if I am not a developer.
I fully agree with Michael. I would really like to see a pear runtime to
be build into UIMA.
I know that there are many people (especially in the academic world),
who just want to use components packaged by others as easily as
possible.
-Torsten
Re: UIMA pear runtime
Posted by Thilo Goetz <tw...@gmx.de>.
Michael Baessler wrote:
> Tong Fin wrote:
>> My thinking is that "pear runtime" is more closer to the " tooling"
>> than the
>> "framework". It is hard to draw the boundary. Also, there are many
>> runtimes
>> that UIMA can/may support.
>> I don't think that we should do something too specific to the "pear
>> runtime".
> If I look from a UIMA users perspective I see that there is something
> that is called pear to package annotators and UIMA components but
> there is no way to easy run these packaged components in the UIMA
> runtime later. So that's why I think the core framework should have
> a pear runtime integration and API to run these pear packages out of the
> box without doing anything manually after the pear installation.
>
> -- Michael
+1
We promote the pear format as the UIMA packaging format, but make it
hard on the user to run pears. Installing and running pears is just too
complicated, while creating them is easy. That's the mismatch we should
address.
--Thilo
Re: UIMA pear runtime
Posted by Michael Baessler <mb...@michael-baessler.de>.
Tong Fin wrote:
> My thinking is that "pear runtime" is more closer to the " tooling"
> than the
> "framework". It is hard to draw the boundary. Also, there are many
> runtimes
> that UIMA can/may support.
> I don't think that we should do something too specific to the "pear
> runtime".
If I look from a UIMA users perspective I see that there is something
that is called pear to package annotators and UIMA components but
there is no way to easy run these packaged components in the UIMA
runtime later. So that's why I think the core framework should have
a pear runtime integration and API to run these pear packages out of the
box without doing anything manually after the pear installation.
-- Michael
Re: UIMA pear runtime
Posted by Tong Fin <to...@gmail.com>.
My thinking is that "pear runtime" is more closer to the " tooling" than the
"framework". It is hard to draw the boundary. Also, there are many runtimes
that UIMA can/may support.
I don't think that we should do something too specific to the "pear
runtime".
-- Tong
On 5/2/07, Michael Baessler <mb...@michael-baessler.de> wrote:
>
> After doing most of the UIMA pear runtime work... I would like to
> suggest something else that came to my mind when implementing the pear
> runtime.
>
> Currently we work with a customResourceSpecifier. I would like to change
> that to a real pearSpecifier. There are two main reasons.
> - Since the pear runtime is fully integrated to the UIMA core, I
> don't like that the descriptor has the source class that is used to load
> the pears in the specifier.
> When using an own descriptor we can hide this unnecessary setting
> from the user.
> - When we are now able to run pears in an aggregate flow, we may
> should also take care of the input and output capabilities for the pear
> main component descriptor. So
> my suggestion is to create a pear descriptor that also can have
> input and output capabilities, so FlowController can handle pears as well.
>
> To make the whole pear stuff easier to use for the user, I would like to
> generate the pearSpecifier during the pear installation. We have all the
> necessary information when the pear is installed and can also set the
> input and output capabilities. So our users can use the generated pear
> descriptor to run the pear or to reference it in an aggregate descriptor.
>
> What do you think?
>
> -- Michael
>
>
>
> Michael Baessler 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.
> >
> > 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?
> >
> > Thoughts?
>
>
Re: UIMA pear runtime
Posted by Michael Baessler <mb...@michael-baessler.de>.
After doing most of the UIMA pear runtime work... I would like to
suggest something else that came to my mind when implementing the pear
runtime.
Currently we work with a customResourceSpecifier. I would like to change
that to a real pearSpecifier. There are two main reasons.
- Since the pear runtime is fully integrated to the UIMA core, I
don't like that the descriptor has the source class that is used to load
the pears in the specifier.
When using an own descriptor we can hide this unnecessary setting
from the user.
- When we are now able to run pears in an aggregate flow, we may
should also take care of the input and output capabilities for the pear
main component descriptor. So
my suggestion is to create a pear descriptor that also can have
input and output capabilities, so FlowController can handle pears as well.
To make the whole pear stuff easier to use for the user, I would like to
generate the pearSpecifier during the pear installation. We have all the
necessary information when the pear is installed and can also set the
input and output capabilities. So our users can use the generated pear
descriptor to run the pear or to reference it in an aggregate descriptor.
What do you think?
-- Michael
Michael Baessler 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.
>
> 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?
>
> Thoughts?