Adam Lally wrote:
On Thu, Jun 12, 2008 at 2:45 AM, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Marshall Schor wrote:
One use case: With JCas it is possible to add fields to the cover class
(thus, you could add a hashmap object, for instance); this is described in
the documentation for JCas. Those field values are only preserved for
different iterations if the JCas instance is kept.
-Marshall
I have nothing to add to what I said earlier.
Hmmm.. then what was the remainder of your email for? ;)
The JCas cache is an
"optimization" (or not), and it shouldn't be relied upon for program
correctness - nor should our documentation suggest that it should.
Now that the JCas cache is configurable, annotators that rely on the
JCas cache for correctness will no longer work in UIMA instances
configured not to use the cache.
I agree with Thilo, but would go even further and state that
annotators that rely on sharing data in the JCas object are *already*
broken, since two annotators could only share data in this way if they
are co-located, not if they are deployed remotely. Annotators
shouldn't break if deployed remotely. I think our documentation
should actively discourage doing this, not encourage it.
I agree. I put in a Jira
(https://issues.apache.org/jira/browse/UIMA-1082) to remember to update
the documentation about this.
-Marshall
-Adam
