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
