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: ala...@alum.rpi.edu
> To: uima-dev@incubator.apache.org
>
> On Tue, Oct 27, 2009 at 2:24 PM, Baptiste Gaillard
> <b_gaill...@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/
