An interesting idea. It would seem quite possible to set up JCas so
that the Java cover objects would be specific for each component, reused
within that component, but dropped when the component exited. This
would allow different definitions of the class in each component, at
some expense of creating additional Java cover objects.
-Marshall
Thilo Goetz wrote:
Mirko has posted a long comment about UIMA and OSGi on our Wiki:
http://cwiki.apache.org/confluence/display/UIMA/UIMA+OSGi+Enablement
Mirko, what particularly intrigued me were your comments about OSGi
and how it conflicts with JCas. I had actually hoped that OSGi would
help us solve some of our JCas problems.
In current UIMA, if you work with applications where you deploy
components from various groups who used JCas to develop their
components, you can run into problems. Because of the way we allow
the definition of types to be spread out over components in UIMA, a
pre-compilation step like JCas that happens at the component level
will necessarily run into trouble. This most often happens with the
DocumentAnnotation. Various annotators create their own extensions to
the DocumentAnnotation, and create JCas classes for their particular
versions. When you aggregate those components, you will actually load
only one of the DocumentAnnotation JCas classes, whichever one happens
to be first in the classpath. This is a serious issue that we have
encountered several times over the last couple of years. [We have no
added warnings to the documentation not to do this sort of thing, but
of course it would be much better if things still worked correctly
even if developers ignored our warning.]
Now the JCas objects are actually just very thin wrapper objects
around data that is held privately by some other internal UIMA
datastructure. So there is in principle no problem with creating a,
e.g., DocumentAnnotation JCas object for each annotator individually,
with its own JCas definition. Still all those objects would be backed
by the same actual data. You can even today configure the JCas so
that each object is created anew each time it is requested from the
JCas. However, this only helps if each annotator basically uses its
own class loader for its JCas classes.
You can see where this is going. I had hoped that with the OSGi
component model and class space support, we would find a way to keep
the JCas user friendly (by allowing JCas generation at the component
level), while still making it work in larger deployments. However, I
have not conducted any UIMA OSGi experiments myself, so this is just a
theoretical notion ;-)
Please let us know what you think. The JCas is one of my motivations
for being interested in OSGi. I hope you won't dash my hopes completely.
--Thilo
- Re: OSGi enablement and JCas Marshall Schor
-
