On 3/21/07, Michael Baessler <[EMAIL PROTECTED]> 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
