You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Baptiste Gaillard <b_...@hotmail.com> on 2009/10/27 15:52:35 UTC
Manual calls to components
Hi,
On our project we are implementing a replacement for the CPE based on OSGI and BPM Workflows.
We
have successfully created BPM workflows based on UIMA component using a
unique data model for each component in the workflow.
Now I
want to make work our UIMA components a little like the CPE, that's to
say having a Type System for each component in the workflow.
But,
I am a little lost, what I do not understand is how can we sequencially
call multiple AEs/CCs and share the same CAS between all the
components.
In the developer guide of UIMA I've seen that:
//create a JCas, given an Analysis Engine (ae)
JCas jcas = ae.newJCas();
//analyze a document
jcas.setDocumentText(doc1text);
ae.process(jcas);
doSomethingWithResults(jcas);
jcas.reset();
Ok to call one AE, but how can I do sothething like that without problem ?
JCas jcas = ae1.newJCas();
jcas.setDocumentText(doc1text);
ae1.process(jcas);
ae2.process(jcas); // Here is the problem..., AE2 does not have the same types in the type system...
cc1.process(jcas);
cc2.process(jcas);
How can I manage the Class Loading of my annotators Types ?
How to prevent conflits of types when I use the same Types in two different annotator ?
Do I need to merge the Types Systems of all my components in a workflow to build a "global" CAS before calling the process method of each component ?
I've looked in the source code but it's not easy to find how the CPM works, so I need some help...
Thanks,
Baptiste
_________________________________________________________________
Nouveau Windows 7 : Trouvez le PC qui vous convient. En savoir plus.
http://clk.atdmt.com/FRM/go/181574580/direct/01/
RE: Manual calls to components
Posted by Baptiste Gaillard <b_...@hotmail.com>.
Hum,
> If you are using
> PEARs, I think this is supported, since each PEAR has an isolated
> classpath and can have its own JCas class, and the framework is aware
> of the different class loaders and can manage them appropriately. If
> you're not using PEARs, I'm not sure whether this would work or not.
Ok, we are not using the UIMA Class Loading support but OSGI allow us to have the same functionnalities, that's to say having one Class Loader for each uima component (Class Loading isolation works).
You're advices have been very useful, thank you Adam, now I know perfectly how I can solve my problems.
Baptiste
> Date: Tue, 27 Oct 2009 15:25:36 -0400
> Subject: Re: Manual calls to components
> From: alally@alum.rpi.edu
> To: uima-dev@incubator.apache.org
>
> On Tue, Oct 27, 2009 at 2:24 PM, Baptiste Gaillard
> <b_...@hotmail.com> wrote:
> >
> > Thank you for the link, I do not know why but I missed this part of the documentation, this is exactly what I wanted :-)
> >
> >> Are all your JCas classes present in the application's classpath? If
> >> so, there won't be any problem.
> >
> > In fact because we are using OSGI each UIMA component is loaded/unloded dynamically in our application, the classpath is built using utility functions of our application (so it should work).
> >
> >> Hmmm, what kind of conflicts do you mean? Do you have the same type
> >> name with different definitions (and therefore different JCas class
> >> definitions for the same class name)?
> >
> > Yes, in rare cases we will have 2 components with the same type names but with different definitions. In this case I suppose that the following code:
> > list.add(aeDesc1);
> > list.add(aeDesc2);
> > list.add(ccDesc);
> > CAS cas = CasCreationUtils.createCas(list);
> > Will not work ??? ... ok, to prevent that I think we can create a utility function to check Type names duplications.
> >
>
> Well, it's complicated. :) CasCreationUtils.createCas will attempt to
> merge the type definitions. This may or may not be successful - for
> example it's okay if one definition includes a feature that the other
> definition doesn't, but it's not okay if they declare the same feature
> with different types.
>
> But then you may have trouble with the JCas classes, if you have
> duplication of class names on the same classpath. If you are using
> PEARs, I think this is supported, since each PEAR has an isolated
> classpath and can have its own JCas class, and the framework is aware
> of the different class loaders and can manage them appropriately. If
> you're not using PEARs, I'm not sure whether this would work or not.
>
> > So if I've understood how to create the CASes, the manipulation and access of data inside the CAS should allways be done using only one Class Loader.
> >
> That definitely makes things easier.
>
> -Adam
_________________________________________________________________
Nouveau Windows 7 : Simplifiez votre PC ! Trouvez le PC qui vous convient.
http://clk.atdmt.com/FRM/go/181574580/direct/01/
Re: Manual calls to components
Posted by Adam Lally <al...@alum.rpi.edu>.
On Tue, Oct 27, 2009 at 2:24 PM, Baptiste Gaillard
<b_...@hotmail.com> wrote:
>
> Thank you for the link, I do not know why but I missed this part of the documentation, this is exactly what I wanted :-)
>
>> Are all your JCas classes present in the application's classpath? If
>> so, there won't be any problem.
>
> In fact because we are using OSGI each UIMA component is loaded/unloded dynamically in our application, the classpath is built using utility functions of our application (so it should work).
>
>> Hmmm, what kind of conflicts do you mean? Do you have the same type
>> name with different definitions (and therefore different JCas class
>> definitions for the same class name)?
>
> Yes, in rare cases we will have 2 components with the same type names but with different definitions. In this case I suppose that the following code:
> list.add(aeDesc1);
> list.add(aeDesc2);
> list.add(ccDesc);
> CAS cas = CasCreationUtils.createCas(list);
> Will not work ??? ... ok, to prevent that I think we can create a utility function to check Type names duplications.
>
Well, it's complicated. :) CasCreationUtils.createCas will attempt to
merge the type definitions. This may or may not be successful - for
example it's okay if one definition includes a feature that the other
definition doesn't, but it's not okay if they declare the same feature
with different types.
But then you may have trouble with the JCas classes, if you have
duplication of class names on the same classpath. If you are using
PEARs, I think this is supported, since each PEAR has an isolated
classpath and can have its own JCas class, and the framework is aware
of the different class loaders and can manage them appropriately. If
you're not using PEARs, I'm not sure whether this would work or not.
> So if I've understood how to create the CASes, the manipulation and access of data inside the CAS should allways be done using only one Class Loader.
>
That definitely makes things easier.
-Adam
RE: Manual calls to components
Posted by Baptiste Gaillard <b_...@hotmail.com>.
Thank you for the link, I do not know why but I missed this part of the documentation, this is exactly what I wanted :-)
> Are all your JCas classes present in the application's classpath? If
> so, there won't be any problem.
In fact because we are using OSGI each UIMA component is loaded/unloded dynamically in our application, the classpath is built using utility functions of our application (so it should work).
> Hmmm, what kind of conflicts do you mean? Do you have the same type
> name with different definitions (and therefore different JCas class
> definitions for the same class name)?
Yes, in rare cases we will have 2 components with the same type names but with different definitions. In this case I suppose that the following code:
list.add(aeDesc1);
list.add(aeDesc2);
list.add(ccDesc);
CAS cas = CasCreationUtils.createCas(list);
Will not work ??? ... ok, to prevent that I think we can create a utility function to check Type names duplications.
So if I've understood how to create the CASes, the manipulation and access of data inside the CAS should allways be done using only one Class Loader.
Thanks,
Baptiste
> Date: Tue, 27 Oct 2009 12:45:50 -0400
> Subject: Re: Manual calls to components
> From: alally@alum.rpi.edu
> To: uima-dev@incubator.apache.org
>
> On Tue, Oct 27, 2009 at 10:52 AM, Baptiste Gaillard
> <b_...@hotmail.com> wrote:
> >
> > Hi,
> >
> > On our project we are implementing a replacement for the CPE based on OSGI and BPM Workflows.
> > We
> > have successfully created BPM workflows based on UIMA component using a
> > unique data model for each component in the workflow.
> >
> > Now I
> > want to make work our UIMA components a little like the CPE, that's to
> > say having a Type System for each component in the workflow.
> > But,
> > I am a little lost, what I do not understand is how can we sequencially
> > call multiple AEs/CCs and share the same CAS between all the
> > components.
> >
> > In the developer guide of UIMA I've seen that:
> > //create a JCas, given an Analysis Engine (ae)
> > JCas jcas = ae.newJCas();
> >
> > //analyze a document
> > jcas.setDocumentText(doc1text);
> > ae.process(jcas);
> > doSomethingWithResults(jcas);
> > jcas.reset();
> >
> > Ok to call one AE, but how can I do sothething like that without problem ?
> > JCas jcas = ae1.newJCas();
> > jcas.setDocumentText(doc1text);
> > ae1.process(jcas);
> > ae2.process(jcas); // Here is the problem..., AE2 does not have the same types in the type system...
> > cc1.process(jcas);
> > cc2.process(jcas);
> >
>
> Hi,
>
> Take a look at this section of the Application Developers Guide:
> http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html#ugr.tug.application.using_multiple_aes
>
> > How can I manage the Class Loading of my annotators Types ?
> Are all your JCas classes present in the application's classpath? If
> so, there won't be any problem.
>
> > How to prevent conflits of types when I use the same Types in two different annotator ?
> Hmmm, what kind of conflicts do you mean? Do you have the same type
> name with different definitions (and therefore different JCas class
> definitions for the same class name)? Hopefully not, but if that's
> the case you probably need to use PEARs to encapsulate the different
> JCas classes within the PEAR classpath of a particular AE.
>
> > Do I need to merge the Types Systems of all my components in a workflow to build a "global" CAS before calling the process method of each component ?
> Yes. All types need to be defined when the CAS is created. See the
> documentation link above for how to do this.
>
> -Adam
_________________________________________________________________
Nouveau Windows 7 : Trouvez le PC qui vous convient. En savoir plus.
http://clk.atdmt.com/FRM/go/181574580/direct/01/
Re: Manual calls to components
Posted by Adam Lally <al...@alum.rpi.edu>.
On Tue, Oct 27, 2009 at 10:52 AM, Baptiste Gaillard
<b_...@hotmail.com> wrote:
>
> Hi,
>
> On our project we are implementing a replacement for the CPE based on OSGI and BPM Workflows.
> We
> have successfully created BPM workflows based on UIMA component using a
> unique data model for each component in the workflow.
>
> Now I
> want to make work our UIMA components a little like the CPE, that's to
> say having a Type System for each component in the workflow.
> But,
> I am a little lost, what I do not understand is how can we sequencially
> call multiple AEs/CCs and share the same CAS between all the
> components.
>
> In the developer guide of UIMA I've seen that:
> //create a JCas, given an Analysis Engine (ae)
> JCas jcas = ae.newJCas();
>
> //analyze a document
> jcas.setDocumentText(doc1text);
> ae.process(jcas);
> doSomethingWithResults(jcas);
> jcas.reset();
>
> Ok to call one AE, but how can I do sothething like that without problem ?
> JCas jcas = ae1.newJCas();
> jcas.setDocumentText(doc1text);
> ae1.process(jcas);
> ae2.process(jcas); // Here is the problem..., AE2 does not have the same types in the type system...
> cc1.process(jcas);
> cc2.process(jcas);
>
Hi,
Take a look at this section of the Application Developers Guide:
http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html#ugr.tug.application.using_multiple_aes
> How can I manage the Class Loading of my annotators Types ?
Are all your JCas classes present in the application's classpath? If
so, there won't be any problem.
> How to prevent conflits of types when I use the same Types in two different annotator ?
Hmmm, what kind of conflicts do you mean? Do you have the same type
name with different definitions (and therefore different JCas class
definitions for the same class name)? Hopefully not, but if that's
the case you probably need to use PEARs to encapsulate the different
JCas classes within the PEAR classpath of a particular AE.
> Do I need to merge the Types Systems of all my components in a workflow to build a "global" CAS before calling the process method of each component ?
Yes. All types need to be defined when the CAS is created. See the
documentation link above for how to do this.
-Adam