[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16166922#comment-16166922
]
Marshall Schor commented on UIMA-5554:
--
ok, will try to invent a new solution :-) that is as efficient as "final"
ints, but is more lazy.
> 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
> Fix For: 3.0.0SDK-beta
>
>
> 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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16166776#comment-16166776
]
Richard Eckart de Castilho commented on UIMA-5554:
--
Also, I find it a bit counter-intuitive that I cannot make use of the JCas
classes in the `initialize()` method. The below triggers the error:
{noformat}
@Override
public void initialize(UimaContext aContext)
throws ResourceInitializationException
{
super.initialize(aContext);
mappings.put("h1", Heading.type);
mappings.put("h2", Heading.type);
mappings.put("h3", Heading.type);
mappings.put("h4", Heading.type);
mappings.put("h5", Heading.type);
mappings.put("h6", Heading.type);
mappings.put("p", Paragraph.type);
}
{noformat}
> 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
> Fix For: 3.0.0SDK-beta
>
>
> 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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16166756#comment-16166756
]
Richard Eckart de Castilho commented on UIMA-5554:
--
I still do not feel that it is a good idea to prevent people from using
Class.forName() or from accessing static fields of classes because of an
exception that happens in a static constructor.
A JCas class has knowledge about the type system. Could it not itself
register/commit the necessary type information into the global type system
state? It would just be another source of type information, just as if one
would load different type descriptors (compatible with each) and create
different CASes using these type descriptors, thus incrementally adding to the
global type registry.
> 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
> Fix For: 3.0.0SDK-beta
>
>
> 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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16162932#comment-16162932
]
Marshall Schor commented on UIMA-5554:
--
Thanks for the response; I think this dialog is helping to clarify some details
(even in my mind) :-)
First, re: the mental picture, in both v2 and v3, type systems (including
committed ones) *can* be shared among CASes - there's a concept of CAS Pools
that supports this; it's useful when running multiple copies of the same
pipeline.
Ignoring that for the moment, and assuming 1 class loader, it is true that you
can have multiple pipelines, each with their own particular type system
definition, installed into different CASes.
If you're not using JCas, then there is a "sharing" of the *built-in JCas
classes*, like TOP and Annotation and FSArray, etc. These are arranged to be
constant and sharable among the various CAS's type systems.
Now, if you have some JCas classes, because of the above assumption of 1 class
loader, these are loaded *globally*. If you want/need isolation, then you run
with classLoaders (like servlets) providing the isolation.
Commit is an action done per type system, but it has a potentially global
effect in that it also loads the JCas classes it can find for those types.
These are loaded *globally* into the current classloader - there's no mechanism
in Java (other than using classloaders) to isolate these.. I note that this is
how v2 works, also.
re: "In the call you have above, I somehow miss a reference to the CAS instance
from which the type system is obtained":
You are correct - This is done using a hidden parameter, which is the type
system whose data is used when running the static initializers in JCas class
being loaded. This hidden parameter is passed via a ThreadLocal, which is set
during the type system commit, before calling the code to find and load JCas
classes associated with that type system.
Re: leaking information between CAS instances.
There's no leaking of slot info in the type system information. And, the JCas
class for a type, "Foo", only gets loaded once (globally) (again, per class
loader). This loading is done with the "first" type system commit that has a
type that corresponds to this particular JCas class. This is also how v2
worked.
In your scenario, if you do a type system commit in " a CAS with type X having
feature x and another CAS with type X having feature y":
- if no JCas classes match type X, no JCas classes are loaded for it
- if there's a JCas class definition in the classpath for type X, then the
*first* typesystem commit loads the JCas class, and it get initialized for that
type system.
-- When the 2nd type system is committed, the Java will find that JCas
class already loaded, and not load it again.
This was also the case in version 2. Trying to use the same JCas class for
multiple different type systems having different definitions of the
corresponding type is in the realm of undefined behavior, depending a lot on
specifics, ordering, etc. It might partially work in some case, not in others.
One thing that would work, always, is the scenario where there are
- different type systems,
- different JCas classes,
- but no JCas name collisions (other than for classes which would be the same
among all the CASes, like Annotation, or MyTopLevelConcept, for instance).
When CAS 1's type system was committed, it would load its JCas classes, and
when CAS 2's type system was committed, those (differently named) JCas classes
would be loaded.
> 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.(AnnotationBase.java:71)
> ... 27 more
> {noformat}
> Is it considered harmful to
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161938#comment-16161938
]
Richard Eckart de Castilho commented on UIMA-5554:
--
I still don't get it entirely because in my mental picture, the committing of
the type systems is something that happens per CAS instance since every CAS
instance can have a different type system. From how you describe it, it appears
as if the "commit" is some kind of global action.
In the call you have above, I somehow miss a reference to the CAS instance from
which the type system is obtained... It looks a bit as if there is a leaking of
type information between CAS instances, i.e. as if I instantiate a CAS with
type X having feature x and another CAS with type X having feature y, then both
CASes end up with a type X with both features.
> 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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161898#comment-16161898
]
Marshall Schor commented on UIMA-5554:
--
The intent is to have JCas not be much more restricted in v3. The only thing
new is the requirement to commit the type system (which loads the JCas classes
for those types), before referencing the types in a manner which would cause
them to be loaded *and initialized* .
Here's a simple example.
Class Foo defines feature foo1 and foo2, both "integer". UIMA type Foo defines
feature foo1, foo2, and foo3. (after merging, say).
This is perfectly permissible (that the JCas class only defines a subset of the
merged type definition).
When the Class Foo is *initialized*, it has a statement for each field to set
up a bridge to the actual type system. These statements look like:{code}
public final static int _FI_foo1 =
TypeSystemImpl.getAdjustedFeatureOffset("foo1");{code}
At class-initialization-time, _FI_foo1 could get set to 0, 1, or 2, depending
on the ordering of these features in the committed type system.
You are right to say the compiling of the JCas classes *predate* the loading.
The JCas classes are compiled without any "bindings" of where the feature slots
go - they just have these "instructions" implemented as static initializers,
which, when run with the current loaded type system, do the right thing.
The way this normally works, is that this initialization happens when the type
system is committed (the type system "commit" method is called). When that
happens, the type system commit method commits the type system, and then sets
up a threadLocal value identifying which type system (of perhaps many) is being
committed, and then calls the code to find and load any JCas classes for the
types in this type system (there many be many, or few, or none - well, there's
always the built-in ones...).
Does that help?
> 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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[ https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161351#comment-16161351 ] Marshall Schor commented on UIMA-5554: -- Thanks for the great questions, Richard :-) I think most of these questions revolve around JCas and non-JCas usage in UIMA. UIMA originally had only non-JCas usage (JCas was added later). The non-JCas model of access to the CAS is useful today when you're writing "generic" annotators that need to work with multiple type systems, where you don't know the type(s) and feature(s) ahead of time. It's somewhat like Java's "reflection" approach - you do some calls in the typeSystemInit method to get some special values into local fields, which you then use when accessing UIMA types and features. The JCas, in contrast, adds classes having class names equivalent to the UIMA types, and method names corresponding to the features, and you use these in your code. But, of course, using these means your code is specific to those types and features. The bridge that exists between these is somewhat flexible. Even when JCas is being used, the non-JCas access capabilities continues to exist along side it. So, in a particular pipeline / CAS, there may be UIMA types for which no JCas classes exist, or UIMA types have additional "features", for which no JCas getters/setters exist; these can be accessed (if needed) using the non-JCas approach. A use case which motivates this scenario is the type "merging" that UIMA does when given type system descriptors coming from annotator descriptors - that merging might "add" additional features to a type (say, needed by a particular annotator you're including in the pipeline), or even add additional Types. That Annotator might be a non-JCas annotator, and doesn't define any JCas classes. So there might not be any getter/setter for these additional fields or types. That is the state of things in both V2 and V3. The implementation details in V3 differ, because the actual Feature Structure instances are represented as instances of some JCas class. In the case where the style is non-JCas, there still are the "built-in" JCas classes, like TOP and Annotation. When you define a UIMA type, say Foo, it always inherits from some supertype (TOP, if non other). If no JCas definition exists (in v3) for an instance, it's most specific supertype JCas class is used to instantiate it. With that background, let's address the questions, maybe in reverse order 1) Why are the types not simply "installed" when the JCas class is loaded and initialized? (Installed means the corresponding UIMA types are installed). JCas classes are normally loaded an initialized as part of type system commit, after the type system has been committed. The exception of course, is that any user code running before type system commit, might make a reference to a JCas type; the first such reference would cause Java to load and initialize the JCas class. Also, a user might write code like Class.forName(...) to force loading of a class. V3 reports errors if these other kinds of loading/initializing are done before type system commit. The reason that UIMA types are not "installed" when a JCas type is loaded in the two exception cases above, is because the details of the UIMA types are not available at that time (because the type system hasn't been gathered from all the annotators in the pipeline and merged, and committed). The UIMA types could be supersets of what this particular JCas implementation defines (see, for example the use case above where some non-JCas Annotator used additional fields). 2) Is there a new concept of installing/committing types in V3? In both v2 and v3, type systems need to be assembled from annotator descriptors in a pipeline, merged, and committed, before being used. UIMA uses this concept to allow efficiency in accessing. This is, admittedly, a trade-off, versus an approach which allows a more dynamic (looking up more information on each access), but this trade-off was made early in the design of UIMA. In V3, an additional "ordering" requirement is present, requiring that the UIMA type system be assembled, merged, and committed, before any JCas classes are *initialized*. This, again, is an efficiency tradeoff, and enables feature access to be compiled into very efficient code that is modern-cpu-design-cache-loading efficient. New error messages were added to detect when this constraint is being violated. 3) In v2 it was possible to have any number of type systems and different CASes initialized with different type systems - and if different classloaders were used, even with different JCas classes. This is also the case in V3, as long as the merged/committed type system is available before any JCas classes are installed. If you are using JCas with different class loaders, they can
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160344#comment-16160344
]
Richard Eckart de Castilho commented on UIMA-5554:
--
I don't understand what "installed/committed" means. As far as I know, there
was a concept of committing the type system of a CAS instance in v2. But afaik
this was per-CAS/classloader and not globally. Also, it was possible to
re-initialize a CAS with a new type system even after one had already been
committed. That concept seems still to be there in UIMAv3 and is being used in
CasIOUtils when CasLoadMode.REINIT is used. Afaik, in v2 it was possible to
have any number of type systems and different CASes initialized with different
type systems - and if different classloaders were used, even with different
JCas classes.
Is there a new concept of "installing/committing" types in v3?
Why are the types not simply "installed" when the JCas class is loaded and
initialized?
> 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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159936#comment-16159936
]
Marshall Schor commented on UIMA-5554:
--
The reference to *Heading.type* etc causes the JCas type "Heading" to be loaded
and initialized.
I think in this instance there's no current workaround other than to rearrange
the order of setup, so that the type sytem is loaded/committed before you
reference things like this.
If anyone has a good suggestion on fixes for this, please speak up. The main
trade off here is in better performance (due to these fields being static final
values).
> 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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159934#comment-16159934
]
Marshall Schor commented on UIMA-5554:
--
hmmm, threaded jira comments seem to not be working? anyway, this is a
response to
https://issues.apache.org/jira/browse/UIMA-5554?focusedCommentId=16159739=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16159739
The English of the message is misleading. It is easy to misread ""A JCas
*class* field "sofa" is being initialized..." as meaning a JCas *instance*
field...
I'll try and think of a better way to express this. Maybe "A JCas class static
field that is used to bridge to the UIMA for the
feature "sofa" is being initialized..."
Basically, the JCas class for this particular UIMA Type has a bunch of "static"
fields that provide a bridge between the Type's features and the JCas class;
these data are set up as static final fields when the class is initialized.
> 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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159861#comment-16159861
]
Richard Eckart de Castilho commented on UIMA-5554:
--
I hit this error again in a different piece of code - in an HtmlReader where I
create a map to assign HTML elements to UIMA types:
{noformat}
mappings.put("h1", Heading.type);
mappings.put("h2", Heading.type);
mappings.put("h3", Heading.type);
mappings.put("h4", Heading.type);
mappings.put("h5", Heading.type);
mappings.put("h6", Heading.type);
mappings.put("p", Paragraph.type);
{noformat}
> 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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159739#comment-16159739
]
Richard Eckart de Castilho commented on UIMA-5554:
--
I am currently using this option
{noformat}
Class.forName("myJCasClassName", false, this.getClass().getClassLoader())
{noformat}
It just seems a bit strange that a normal `Class.forName()` call fails with
such an error. I didn't even try to do anything with the sofa although the
error message says "A JCas class field "sofa" is being initialized...".
Shouldn't the sofa be only set when I actually create an instance of the class,
i.e. in the constructor?
> 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.(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)
[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection
[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159372#comment-16159372
]
Marshall Schor commented on UIMA-5554:
--
It's not harmful, but there's an "ordering" issue, due to JCas static
initializer code. This can be solved in 2 ways.
Class.forName has 2 flavors. The "plain" flavor loads the class *and
initializes* it. That is, it runs the static initializers among other things.
In UIMA V3, these initializers reference information about the type system that
defines the corresponding UIMA Type for this JCas classes. Therefore, these
types need to be "installed" - that is committed :-), before the class
initialization happens.
So, you can do a Class.forName("myJCasClassName", false,
this.getClass().getClassLoader()), which skips the initialization (the *false*
argument says to not do the initialization. The initialization will happen on
first use, at which time the type system must be committed.
The other way to get Class.forname("myJCasClassName") (the plain variation) to
work is to first commit a type system that defines the type this JCas class is
covering.
I hope that's clear; if not, please ask more questions.
> 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.(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)
