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
