[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161396#comment-16161396
]
Richard Eckart de Castilho commented on UIMA-5554:
--------------------------------------------------
A lot of information! It sounds like JCas has become quite a bit more
restricted in v3 - and/or I don't manage to wrap my head around the new
approach yet.
First, wrt. 4: I'm happily mixing JCas (with non-built-in classes) and CAS all
the time - even then reinitializing the type system.
JCas classes are global per classloader. Type-systems are local per CAS. I
could have a CAS initialized with typesystem X and types A+B and a second CAS
with typesystem Y and the types C+D, even under the regime of a single
classloader. The typesystems are committed individually per CAS. I understand
you say that the JCas classes are independently committed per classloader - and
this seems to be somehow tied to the committing of the typesystems in the
CASes. I still don't understand why these two processes have to be coupled
though because they have different scopes.
Typesystem merging is something that can happen at the level of CASes. However,
since JCas classes are static (we usually generate them via jcasgen at build
time), typesystem merging cannot have any effect on them.
So I still don't understand this "ordering" of things. As I see it, the "the
UIMA type system be assembled, merged, and committed" before a the CAS API can
be used and certainly before JCas classes can access any data in the CAS. But
this "assembling, merging and committing" happens at runtime. JCas classes
*predate* this -they are created at build-time.
> Strange exception when trying to get JCas FS class through reflection
> ---------------------------------------------------------------------
>
> Key: UIMA-5554
> URL: https://issues.apache.org/jira/browse/UIMA-5554
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 3.0.0SDK-beta
> Reporter: Richard Eckart de Castilho
>
> I am trying to get a class object for a JCas FS type using reflection:
> {noformat}
> Class.forName(typeName);
> {noformat}
> However, it produces this strange error.
> {noformat}
> java.lang.ExceptionInInitializerError
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> ...
> Caused by: org.apache.uima.cas.CASRuntimeException: A JCas class field "sofa"
> is being initialized by non-framework (user) code before Type System Commit
> for a type system with a corresponding type. Either change the user load code
> to not do initialize, or to defer it until after the type system commit.
> at
> org.apache.uima.cas.impl.TypeSystemImpl.getAdjustedFeatureOffset(TypeSystemImpl.java:2575)
> at
> org.apache.uima.jcas.cas.AnnotationBase.<clinit>(AnnotationBase.java:71)
> ... 27 more
> {noformat}
> Is it considered harmful to try getting a class object for a JCas FS class?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
