[jira] [Created] (UIMA-5579) uv3 log4j bridge new style broken
Marshall Schor created UIMA-5579: Summary: uv3 log4j bridge new style broken Key: UIMA-5579 URL: https://issues.apache.org/jira/browse/UIMA-5579 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Marshall Schor Fix For: 3.0.0SDK-beta The fix to the log4j bridge is broken for "new" style logging - accidentally treating these in old style. This is causing the downstream build of uimaFIT to fail -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5576) Use setExtensionClassPath only when classpath is not empty
[ https://issues.apache.org/jira/browse/UIMA-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5576: - Component/s: (was: jcasgen-maven-plugin) Tools Core Java Framework > Use setExtensionClassPath only when classpath is not empty > -- > > Key: UIMA-5576 > URL: https://issues.apache.org/jira/browse/UIMA-5576 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Reporter: Richard Eckart de Castilho >Assignee: Richard Eckart de Castilho > Fix For: 3.0.0SDK-beta > > > Use setExtensionClassPath only when classpath is not empty - otherwise use > setExtensionClassLoader. This avoids the warning about adding an empty > classpath. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (UIMA-5576) Use setExtensionClassPath only when classpath is not empty
[ https://issues.apache.org/jira/browse/UIMA-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170731#comment-16170731 ] Marshall Schor edited comment on UIMA-5576 at 9/18/17 9:17 PM: --- -I see this Jira is for jcasgen-maven-plugin. I don't see any commits in the history for that? Did the changes go somewhere else, or am I looking in the wrong spot? Last change in SVN is Sept 8- This change was to the uimaj-tools project's jcasgen code. I'll fix the component was (Author: schor): I see this Jira is for jcasgen-maven-plugin. I don't see any commits in the history for that? Did the changes go somewhere else, or am I looking in the wrong spot? Last change in SVN is Sept 8 > Use setExtensionClassPath only when classpath is not empty > -- > > Key: UIMA-5576 > URL: https://issues.apache.org/jira/browse/UIMA-5576 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Reporter: Richard Eckart de Castilho >Assignee: Richard Eckart de Castilho > Fix For: 3.0.0SDK-beta > > > Use setExtensionClassPath only when classpath is not empty - otherwise use > setExtensionClassLoader. This avoids the warning about adding an empty > classpath. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5576) Use setExtensionClassPath only when classpath is not empty
[ https://issues.apache.org/jira/browse/UIMA-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170731#comment-16170731 ] Marshall Schor commented on UIMA-5576: -- I see this Jira is for jcasgen-maven-plugin. I don't see any commits in the history for that? Did the changes go somewhere else, or am I looking in the wrong spot? Last change in SVN is Sept 8 > Use setExtensionClassPath only when classpath is not empty > -- > > Key: UIMA-5576 > URL: https://issues.apache.org/jira/browse/UIMA-5576 > Project: UIMA > Issue Type: Bug > Components: jcasgen-maven-plugin >Reporter: Richard Eckart de Castilho >Assignee: Richard Eckart de Castilho > Fix For: 3.0.0SDK-beta > > > Use setExtensionClassPath only when classpath is not empty - otherwise use > setExtensionClassLoader. This avoids the warning about adding an empty > classpath. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5578) uv3 jcasgen plugin integration test errors
[ https://issues.apache.org/jira/browse/UIMA-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5578. -- Resolution: Fixed > uv3 jcasgen plugin integration test errors > -- > > Key: UIMA-5578 > URL: https://issues.apache.org/jira/browse/UIMA-5578 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The changes to do lazy initialization of JCas classes are causing compile > errors in the JCasGen integration test. Check for missing imports, java > version, etc. If missing imports, also check that the migration utility adds > the needed ones. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5578) uv3 jcasgen plugin integration test errors
Marshall Schor created UIMA-5578: Summary: uv3 jcasgen plugin integration test errors Key: UIMA-5578 URL: https://issues.apache.org/jira/browse/UIMA-5578 Project: UIMA Issue Type: Bug Components: Core Java Framework, Tools Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.0SDK-beta The changes to do lazy initialization of JCas classes are causing compile errors in the JCasGen integration test. Check for missing imports, java version, etc. If missing imports, also check that the migration utility adds the needed ones. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5577) uv3: Adjust new-style logging statements not to use parameter positions
[ https://issues.apache.org/jira/browse/UIMA-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170555#comment-16170555 ] Marshall Schor commented on UIMA-5577: -- I think those are the only new apis. Can we close this Jira (assuming you fixed whatever you found)? (then I can do rc3 and people can try out more stuff). > uv3: Adjust new-style logging statements not to use parameter positions > --- > > Key: UIMA-5577 > URL: https://issues.apache.org/jira/browse/UIMA-5577 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Richard Eckart de Castilho >Assignee: Richard Eckart de Castilho > Fix For: 3.0.0SDK-beta > > > Per UIMA-5556 new-style logging statements can not make use of parameter > positions anymore. However, there are several new-style logging statements in > the code that still make use of the parameter positions. Fix these. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5553) uv3: Ability to set just a parent classloader, but not classpath
[
https://issues.apache.org/jira/browse/UIMA-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170545#comment-16170545
]
Marshall Schor commented on UIMA-5553:
--
sounds like that's the safe thing to do - I'll change it to a synchronized
method like the others.
> uv3: Ability to set just a parent classloader, but not classpath
>
>
> Key: UIMA-5553
> URL: https://issues.apache.org/jira/browse/UIMA-5553
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> uimaFIT tries to set a custom classloader on a resource manager - but it does
> so without adding any additional classpath entries:
> {noformat}
> ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
> resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(),
> "", true);
> return resMgr;
> {noformat}
> With UV3, this call now produces a warning:
> {noformat}
> org.apache.uima.internal.util.Misc addUrlsFromPath(257) WARNING: Skipping
> adding "" to URLs
> {noformat}
> It would be nice to have a `resMgr.setExtensionClassPath` method that just
> sets the parent loader but without trying to add URLs.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (UIMA-5575) uv3 migration tool missing insert of _featName_xxx and _typeName
[ https://issues.apache.org/jira/browse/UIMA-5575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5575. -- Resolution: Fixed > uv3 migration tool missing insert of _featName_xxx and _typeName > > > Key: UIMA-5575 > URL: https://issues.apache.org/jira/browse/UIMA-5575 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > JCas class in v3 have additional static final string fields, intended for use > in @annotations. The migration tool is missing the generation of these; add > them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5573) uv3 change JCas feature slot initialization to be more lazy
[ https://issues.apache.org/jira/browse/UIMA-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5573. -- Resolution: Fixed > uv3 change JCas feature slot initialization to be more lazy > --- > > Key: UIMA-5573 > URL: https://issues.apache.org/jira/browse/UIMA-5573 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The current implementation of JCas classes requires that a type system > associated with a JCas class be committed before the JCas class is loaded. > This causes some existing code to fail, because they're causing a JCas class > to be loaded before the type system is committed (see UIMA-5554). > The reason for this design in v3 was to enable the computation of the offsets > for accessing features in feature structures to be done once and saved in > static final int values, for efficiency. > Find a new approach, which is as efficient, but is more lazy - allowing JCas > classes to be loaded, and later a corresponding type system commit to be run. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5577) uv3: Adjust new-style logging statements not to use parameter positions
[ https://issues.apache.org/jira/browse/UIMA-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170485#comment-16170485 ] Marshall Schor commented on UIMA-5577: -- Richard - are there any left that still need fixing? > uv3: Adjust new-style logging statements not to use parameter positions > --- > > Key: UIMA-5577 > URL: https://issues.apache.org/jira/browse/UIMA-5577 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Richard Eckart de Castilho >Assignee: Richard Eckart de Castilho > Fix For: 3.0.0SDK-beta > > > Per UIMA-5556 new-style logging statements can not make use of parameter > positions anymore. However, there are several new-style logging statements in > the code that still make use of the parameter positions. Fix these. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5574) uv3 UIMA Exceptions constructors calling wrong super
[ https://issues.apache.org/jira/browse/UIMA-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5574. -- Resolution: Fixed > uv3 UIMA Exceptions constructors calling wrong super > - > > Key: UIMA-5574 > URL: https://issues.apache.org/jira/browse/UIMA-5574 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > Finish incomplete refactoring of UIMA exception classes. Problems include > the class UIMA_IllegalStateException having a constructor with a > resource-bundle, but the superclass not supporting this. Other issues: > throwables are getting lost due to wrong argument ordering for the superclass -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5575) uv3 migration tool missing insert of _featName_xxx and _typeName
Marshall Schor created UIMA-5575: Summary: uv3 migration tool missing insert of _featName_xxx and _typeName Key: UIMA-5575 URL: https://issues.apache.org/jira/browse/UIMA-5575 Project: UIMA Issue Type: Bug Components: Core Java Framework, Tools Affects Versions: 3.0.0SDK-alpha02 Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta JCas class in v3 have additional static final string fields, intended for use in @annotations. The migration tool is missing the generation of these; add them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5573) uv3 change JCas feature slot initialization to be more lazy
[ https://issues.apache.org/jira/browse/UIMA-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16168289#comment-16168289 ] Marshall Schor commented on UIMA-5573: -- I found an approach that looks very promising. I tried it out, manually changing Annotation JCas class, and ran the big growing the CAS test, multiple times - it seems to be equally fast as the current approach for getting / setting features in a Feature Structure. It introduces a small indirection, that allows the JCas class to load and initialize ahead of the type system commit. (Of course, you must eventually commit a type system before trying to use the JCas class for a type to make new instances, get/set features). This indirection is a new one available in Java 7 and 8, and makes use of a new object called a MutableCallSite. The good news is that the JIT compiler is able to compile-out this indirection, which is why this performs so well. Unfortunately, the change to do this is somewhat extensive: JCasGen needs to change, as does the v3-migration tool, to generate the new format. All the hand-done built-in JCas classes need updating as well. So it may take a bit of time... > uv3 change JCas feature slot initialization to be more lazy > --- > > Key: UIMA-5573 > URL: https://issues.apache.org/jira/browse/UIMA-5573 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The current implementation of JCas classes requires that a type system > associated with a JCas class be committed before the JCas class is loaded. > This causes some existing code to fail, because they're causing a JCas class > to be loaded before the type system is committed (see UIMA-5554). > The reason for this design in v3 was to enable the computation of the offsets > for accessing features in feature structures to be done once and saved in > static final int values, for efficiency. > Find a new approach, which is as efficient, but is more lazy - allowing JCas > classes to be loaded, and later a corresponding type system commit to be run. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5574) uv3 UIMA Exceptions constructors calling wrong super
Marshall Schor created UIMA-5574: Summary: uv3 UIMA Exceptions constructors calling wrong super Key: UIMA-5574 URL: https://issues.apache.org/jira/browse/UIMA-5574 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 3.0.0SDK-alpha02 Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.0SDK-beta Finish incomplete refactoring of UIMA exception classes. Problems include the class UIMA_IllegalStateException having a constructor with a resource-bundle, but the superclass not supporting this. Other issues: throwables are getting lost due to wrong argument ordering for the superclass -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5573) uv3 change JCas feature slot initialization to be more lazy
Marshall Schor created UIMA-5573: Summary: uv3 change JCas feature slot initialization to be more lazy Key: UIMA-5573 URL: https://issues.apache.org/jira/browse/UIMA-5573 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 3.0.0SDK-alpha02 Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta The current implementation of JCas classes requires that a type system associated with a JCas class be committed before the JCas class is loaded. This causes some existing code to fail, because they're causing a JCas class to be loaded before the type system is committed (see UIMA-5554). The reason for this design in v3 was to enable the computation of the offsets for accessing features in feature structures to be done once and saved in static final int values, for efficiency. Find a new approach, which is as efficient, but is more lazy - allowing JCas classes to be loaded, and later a corresponding type system commit to be run. -- 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=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] [Resolved] (UIMA-5572) uv3 make default method for getComparator() in FSIteratorImplBase
[ https://issues.apache.org/jira/browse/UIMA-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5572. -- Resolution: Fixed > uv3 make default method for getComparator() in FSIteratorImplBase > - > > Key: UIMA-5572 > URL: https://issues.apache.org/jira/browse/UIMA-5572 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > Peter mentioned a backwards compatibility issue - caused by the need for > classes extending FSIteratorImplBase to implement a new method getComparator. > Implement this as a default method to eliminate this backwards compatibility > issue -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5566) uv3 change way 0-length arrays are created, remove new (in v3) APIs for them
[ https://issues.apache.org/jira/browse/UIMA-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5566. -- Resolution: Won't Fix > uv3 change way 0-length arrays are created, remove new (in v3) APIs for them > > > Key: UIMA-5566 > URL: https://issues.apache.org/jira/browse/UIMA-5566 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > I rediscovered that some of the deserialization code (e.g. xmi > deserialization) has been deserializing empty lists by reusing a shared > instance (for a particular CAS) of an empty list. > This seems like Java's sharing of other immutable objects, such as Integer > (when you say new Integer(4), it returns you a shared object; likewise, > strings like "123" are merged and shared where possible). > The 3.0.0-beta had previously introduced a bunch of methods on CAS and JCas > to get shared 0-length arrays and lists. > I'm think it would be good to remove all of these, and instead, just change > the creation of these to automatically reuse shared (per CAS) instances of > these. > This has a small (tiny?) potential to "break" existing code, if code was > written that depended on two different instances of, for example, an FSArray > of length 0, were required to be !=. > A recovery mechanism (workaround) for these probably very rare cases would be > to enable the creation of non-equal instances, perhaps via the clone() > method. Even this is probably not really needed, and deserialization would > still be reusing shared values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5564) have deserializers reuse 0-length arrays and lists
[ https://issues.apache.org/jira/browse/UIMA-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5564. -- Resolution: Won't Fix > have deserializers reuse 0-length arrays and lists > -- > > Key: UIMA-5564 > URL: https://issues.apache.org/jira/browse/UIMA-5564 > Project: UIMA > Issue Type: Improvement >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > Observed use cases show CASes containing lots of 0-length arrays or empty > lists. When these are deserialized from an xmi CAS where multi-ref features > are not specified (the default), these would be deserialized as individual > copies. Change this to reuse shared values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (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:all-tabpanel
]
Marshall Schor resolved UIMA-5554.
--
Resolution: Fixed
improved the error message
> 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] [Created] (UIMA-5572) uv3 make default method for getComparator() in FSIteratorImplBase
Marshall Schor created UIMA-5572: Summary: uv3 make default method for getComparator() in FSIteratorImplBase Key: UIMA-5572 URL: https://issues.apache.org/jira/browse/UIMA-5572 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 3.0.0SDK-alpha02 Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta Peter mentioned a backwards compatibility issue - caused by the need for classes extending FSIteratorImplBase to implement a new method getComparator. Implement this as a default method to eliminate this backwards compatibility issue -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (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:all-tabpanel
]
Marshall Schor updated UIMA-5554:
-
Fix Version/s: 3.0.0SDK-beta
> 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] [Resolved] (UIMA-5558) xmi serialization/deserialization of 0-length array being deserialized as null
[ https://issues.apache.org/jira/browse/UIMA-5558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5558. -- Resolution: Fixed This was very specific to the way StringArrays are serialized in xmi. > xmi serialization/deserialization of 0-length array being deserialized as null > -- > > Key: UIMA-5558 > URL: https://issues.apache.org/jira/browse/UIMA-5558 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta, 2.10.2SDK > > > A user reports a serialization of a 0-length string array feature value is > subsequently being deserialized as a null. The binary > serialization/deserialization is correct, though. > Also check JSON, and FSLists. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5558) xmi serialization/deserialization of 0-length array being deserialized as null
[ https://issues.apache.org/jira/browse/UIMA-5558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5558: - Summary: xmi serialization/deserialization of 0-length array being deserialized as null (was: xmi serialization/deserializtion of 0-length array being deserialized as null) > xmi serialization/deserialization of 0-length array being deserialized as null > -- > > Key: UIMA-5558 > URL: https://issues.apache.org/jira/browse/UIMA-5558 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta, 2.10.2SDK > > > A user reports a serialization of a 0-length string array feature value is > subsequently being deserialized as a null. The binary > serialization/deserialization is correct, though. > Also check JSON, and FSLists. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5570) uv3 loggers missing arg on 2-object form of substitutable parms
[ https://issues.apache.org/jira/browse/UIMA-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5570. -- Resolution: Fixed > uv3 loggers missing arg on 2-object form of substitutable parms > --- > > Key: UIMA-5570 > URL: https://issues.apache.org/jira/browse/UIMA-5570 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > v3 logging adds methods from slf4j + log4j for forms like logger.info(...), > logger.warn(...), etc. > One of these forms has 2 parameter objects; the 2nd of these was accidentally > omitted when passing the call on, in Logger_common_impl -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5571) uv3 log4j bridge not handling multi-substitutable args vs throwable correctly
[ https://issues.apache.org/jira/browse/UIMA-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5571. -- Resolution: Fixed > uv3 log4j bridge not handling multi-substitutable args vs throwable correctly > - > > Key: UIMA-5571 > URL: https://issues.apache.org/jira/browse/UIMA-5571 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The log4j (v2) API has calls which allow both a message (with substitutable > parts) and arguments to substitute. > It also has calls which allow passing a throwable. > The calls that support passing a throwable do not support substituable parts. > The bridge code assumed that it did. This resulted in an array of args > being treated as one substitutable value. > > Change the bridge code to call one of two different log4j methods, depending > on whether or not a throwable is being included. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5571) uv3 log4j bridge not handling multi-substitutable args vs throwable correctly
Marshall Schor created UIMA-5571: Summary: uv3 log4j bridge not handling multi-substitutable args vs throwable correctly Key: UIMA-5571 URL: https://issues.apache.org/jira/browse/UIMA-5571 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 3.0.0SDK-alpha02 Reporter: Marshall Schor Fix For: 3.0.0SDK-beta The log4j (v2) API has calls which allow both a message (with substitutable parts) and arguments to substitute. It also has calls which allow passing a throwable. The calls that support passing a throwable do not support substituable parts. The bridge code assumed that it did. This resulted in an array of args being treated as one substitutable value. Change the bridge code to call one of two different log4j methods, depending on whether or not a throwable is being included. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5570) uv3 loggers missing arg on 2-object form of substitutable parms
Marshall Schor created UIMA-5570: Summary: uv3 loggers missing arg on 2-object form of substitutable parms Key: UIMA-5570 URL: https://issues.apache.org/jira/browse/UIMA-5570 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 3.0.0SDK-alpha02 Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.0SDK-beta v3 logging adds methods from slf4j + log4j for forms like logger.info(...), logger.warn(...), etc. One of these forms has 2 parameter objects; the 2nd of these was accidentally omitted when passing the call on, in Logger_common_impl -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5557) uv3 custom JCas getters return value check should be skipped for arg lists which are not getters
[
https://issues.apache.org/jira/browse/UIMA-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor updated UIMA-5557:
-
Summary: uv3 custom JCas getters return value check should be skipped for
arg lists which are not getters (was: uv3: FSArray accessors seem not to be
correctly generated)
> uv3 custom JCas getters return value check should be skipped for arg lists
> which are not getters
>
>
> Key: UIMA-5557
> URL: https://issues.apache.org/jira/browse/UIMA-5557
> Project: UIMA
> Issue Type: Bug
> Components: jcasgen-maven-plugin
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> With the UIMAv3 jcasgen, at runtime, I am seeing messages such as
> {noformat}
> 2017-09-08 15:00:29 WARN [main] (FSClassRegistry) - CAS type system type
> "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Compound" defines field
> "splits" with range "class org.apache.uima.jcas.cas.FSArray", but JCas getter
> method is returning "interface java.util.List" which is not a subtype of the
> declared range.
> {noformat}
> A user on the users mailing list reported a similar message when trying out
> UIMAv3:
> {noformat}
> JCAS range type uima.cas.FSArray for feature ... does not match the CAS range
> type uima.cas.StringArray for the feature
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (UIMA-5565) uv3: Adding getLogger() method in flow controllers
[
https://issues.apache.org/jira/browse/UIMA-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164867#comment-16164867
]
Marshall Schor commented on UIMA-5565:
--
ok, thanks, will do. The key is the logger name - usually (by convention) the
same as some class name. When a context is created the creation code will call
the setLogger to set the logger. For flow controllers, for example, the code
is in FlowControllerContainer, and looks like
{code}Logger logger = UIMAFramework.getLogger(mFlowController.getClass());
logger.setResourceManager(this.getResourceManager());
uimaContext.setLogger(logger);
{code}
> uv3: Adding getLogger() method in flow controllers
> --
>
> Key: UIMA-5565
> URL: https://issues.apache.org/jira/browse/UIMA-5565
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
>Reporter: Richard Eckart de Castilho
>
> How about adding a getLogger() method also in CasFlowController_ImplBase /
> JCasFlowController_ImplBase?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (UIMA-5563) Improve Annotation Viewer File Section UI
[ https://issues.apache.org/jira/browse/UIMA-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5563. -- Resolution: Fixed > Improve Annotation Viewer File Section UI > - > > Key: UIMA-5563 > URL: https://issues.apache.org/jira/browse/UIMA-5563 > Project: UIMA > Issue Type: Improvement > Components: Tools >Reporter: Ethan Steinberg >Priority: Minor > Fix For: 3.0.0SDK-beta, 2.10.2SDK > > Attachments: patch.txt > > > One issue I often have with the annotation viewer is that it is hard to > select individual files from large directories. This patch is a simple UI > tweak to add a text field for filtering the file names. > !https://image.ibb.co/kZ1Frv/Screen_Shot_2017_09_12_at_12_50_47_PM.png! > The patch is > [here|https://gist.githubusercontent.com/anonymous/d1d896deebd31ac1a1145ac78d83d48e/raw/556174e08dbe1c245f0f656d64bcca43af9d7057/gistfile1.txt] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5563) Improve Annotation Viewer File Section UI
[ https://issues.apache.org/jira/browse/UIMA-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5563: - Fix Version/s: 2.10.2SDK 3.0.0SDK-beta > Improve Annotation Viewer File Section UI > - > > Key: UIMA-5563 > URL: https://issues.apache.org/jira/browse/UIMA-5563 > Project: UIMA > Issue Type: Improvement > Components: Tools >Reporter: Ethan Steinberg >Priority: Minor > Fix For: 3.0.0SDK-beta, 2.10.2SDK > > Attachments: patch.txt > > > One issue I often have with the annotation viewer is that it is hard to > select individual files from large directories. This patch is a simple UI > tweak to add a text field for filtering the file names. > !https://image.ibb.co/kZ1Frv/Screen_Shot_2017_09_12_at_12_50_47_PM.png! > The patch is > [here|https://gist.githubusercontent.com/anonymous/d1d896deebd31ac1a1145ac78d83d48e/raw/556174e08dbe1c245f0f656d64bcca43af9d7057/gistfile1.txt] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5563) Improve Annotation Viewer File Section UI
[ https://issues.apache.org/jira/browse/UIMA-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164654#comment-16164654 ] Marshall Schor commented on UIMA-5563: -- Hi, thanks for the patch - we'll take a look at this soon. A small "procedural" request: when posting new Jiras, please attach patch files directly to the Jira (rather than linking them from some web spot). And also please do the same for screen shots. You do this by clicking on the jira "More" button and using Attach Files or Attach Screenshot. > Improve Annotation Viewer File Section UI > - > > Key: UIMA-5563 > URL: https://issues.apache.org/jira/browse/UIMA-5563 > Project: UIMA > Issue Type: Improvement > Components: Tools >Reporter: Ethan Steinberg >Priority: Minor > Attachments: patch.txt > > > One issue I often have with the annotation viewer is that it is hard to > select individual files from large directories. This patch is a simple UI > tweak to add a text field for filtering the file names. > !https://image.ibb.co/kZ1Frv/Screen_Shot_2017_09_12_at_12_50_47_PM.png! > The patch is > [here|https://gist.githubusercontent.com/anonymous/d1d896deebd31ac1a1145ac78d83d48e/raw/556174e08dbe1c245f0f656d64bcca43af9d7057/gistfile1.txt] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (UIMA-5563) Improve Annotation Viewer File Section UI
[ https://issues.apache.org/jira/browse/UIMA-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164645#comment-16164645 ] Marshall Schor edited comment on UIMA-5563 at 9/13/17 1:26 PM: --- I attached the patch directly to this Jira, copied from the link in the Jira description, so we have it here permanently, in case the link goes away. I found I had to change the top 3 lines where it said uimaj-tools/src/main/... to just src/main/... in order to get Eclipse to apply the patch. was (Author: schor): This is the patch, copied from the link in the Jira, so we have it here permanently, in case the link goes away. I found I had to change the top 3 lines where it said uimaj-tools/src/main/... to just src/main/... in order to get Eclipse to apply the patch. > Improve Annotation Viewer File Section UI > - > > Key: UIMA-5563 > URL: https://issues.apache.org/jira/browse/UIMA-5563 > Project: UIMA > Issue Type: Improvement > Components: Tools >Reporter: Ethan Steinberg >Priority: Minor > Attachments: patch.txt > > > One issue I often have with the annotation viewer is that it is hard to > select individual files from large directories. This patch is a simple UI > tweak to add a text field for filtering the file names. > !https://image.ibb.co/kZ1Frv/Screen_Shot_2017_09_12_at_12_50_47_PM.png! > The patch is > [here|https://gist.githubusercontent.com/anonymous/d1d896deebd31ac1a1145ac78d83d48e/raw/556174e08dbe1c245f0f656d64bcca43af9d7057/gistfile1.txt] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5563) Improve Annotation Viewer File Section UI
[ https://issues.apache.org/jira/browse/UIMA-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5563: - Attachment: patch.txt This is the patch, copied from the link in the Jira, so we have it here permanently, in case the link goes away. I found I had to change the top 3 lines where it said uimaj-tools/src/main/... to just src/main/... in order to get Eclipse to apply the patch. > Improve Annotation Viewer File Section UI > - > > Key: UIMA-5563 > URL: https://issues.apache.org/jira/browse/UIMA-5563 > Project: UIMA > Issue Type: Improvement > Components: Tools >Reporter: Ethan Steinberg >Priority: Minor > Attachments: patch.txt > > > One issue I often have with the annotation viewer is that it is hard to > select individual files from large directories. This patch is a simple UI > tweak to add a text field for filtering the file names. > !https://image.ibb.co/kZ1Frv/Screen_Shot_2017_09_12_at_12_50_47_PM.png! > The patch is > [here|https://gist.githubusercontent.com/anonymous/d1d896deebd31ac1a1145ac78d83d48e/raw/556174e08dbe1c245f0f656d64bcca43af9d7057/gistfile1.txt] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5566) uv3 change way 0-length arrays are created, remove new (in v3) APIs for them
[ https://issues.apache.org/jira/browse/UIMA-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5566: - Attachment: (was: patch.txt) > uv3 change way 0-length arrays are created, remove new (in v3) APIs for them > > > Key: UIMA-5566 > URL: https://issues.apache.org/jira/browse/UIMA-5566 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > I rediscovered that some of the deserialization code (e.g. xmi > deserialization) has been deserializing empty lists by reusing a shared > instance (for a particular CAS) of an empty list. > This seems like Java's sharing of other immutable objects, such as Integer > (when you say new Integer(4), it returns you a shared object; likewise, > strings like "123" are merged and shared where possible). > The 3.0.0-beta had previously introduced a bunch of methods on CAS and JCas > to get shared 0-length arrays and lists. > I'm think it would be good to remove all of these, and instead, just change > the creation of these to automatically reuse shared (per CAS) instances of > these. > This has a small (tiny?) potential to "break" existing code, if code was > written that depended on two different instances of, for example, an FSArray > of length 0, were required to be !=. > A recovery mechanism (workaround) for these probably very rare cases would be > to enable the creation of non-equal instances, perhaps via the clone() > method. Even this is probably not really needed, and deserialization would > still be reusing shared values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (UIMA-5566) uv3 change way 0-length arrays are created, remove new (in v3) APIs for them
[ https://issues.apache.org/jira/browse/UIMA-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5566: - Comment: was deleted (was: This is the patch, copied from the original link, so it's permanently here. I found I had to change the first 3 lines where it said uimaj-tools/src/main/... to just src/main/..., in order to get Eclipse to apply the patch.) > uv3 change way 0-length arrays are created, remove new (in v3) APIs for them > > > Key: UIMA-5566 > URL: https://issues.apache.org/jira/browse/UIMA-5566 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > I rediscovered that some of the deserialization code (e.g. xmi > deserialization) has been deserializing empty lists by reusing a shared > instance (for a particular CAS) of an empty list. > This seems like Java's sharing of other immutable objects, such as Integer > (when you say new Integer(4), it returns you a shared object; likewise, > strings like "123" are merged and shared where possible). > The 3.0.0-beta had previously introduced a bunch of methods on CAS and JCas > to get shared 0-length arrays and lists. > I'm think it would be good to remove all of these, and instead, just change > the creation of these to automatically reuse shared (per CAS) instances of > these. > This has a small (tiny?) potential to "break" existing code, if code was > written that depended on two different instances of, for example, an FSArray > of length 0, were required to be !=. > A recovery mechanism (workaround) for these probably very rare cases would be > to enable the creation of non-equal instances, perhaps via the clone() > method. Even this is probably not really needed, and deserialization would > still be reusing shared values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5566) uv3 change way 0-length arrays are created, remove new (in v3) APIs for them
[ https://issues.apache.org/jira/browse/UIMA-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5566: - Attachment: patch.txt This is the patch, copied from the original link, so it's permanently here. I found I had to change the first 3 lines where it said uimaj-tools/src/main/... to just src/main/..., in order to get Eclipse to apply the patch. > uv3 change way 0-length arrays are created, remove new (in v3) APIs for them > > > Key: UIMA-5566 > URL: https://issues.apache.org/jira/browse/UIMA-5566 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > Attachments: patch.txt > > > I rediscovered that some of the deserialization code (e.g. xmi > deserialization) has been deserializing empty lists by reusing a shared > instance (for a particular CAS) of an empty list. > This seems like Java's sharing of other immutable objects, such as Integer > (when you say new Integer(4), it returns you a shared object; likewise, > strings like "123" are merged and shared where possible). > The 3.0.0-beta had previously introduced a bunch of methods on CAS and JCas > to get shared 0-length arrays and lists. > I'm think it would be good to remove all of these, and instead, just change > the creation of these to automatically reuse shared (per CAS) instances of > these. > This has a small (tiny?) potential to "break" existing code, if code was > written that depended on two different instances of, for example, an FSArray > of length 0, were required to be !=. > A recovery mechanism (workaround) for these probably very rare cases would be > to enable the creation of non-equal instances, perhaps via the clone() > method. Even this is probably not really needed, and deserialization would > still be reusing shared values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5565) uv3: Adding getLogger() method in flow controllers
[ https://issues.apache.org/jira/browse/UIMA-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164573#comment-16164573 ] Marshall Schor commented on UIMA-5565: -- Do you mean one like the ones in the impl-bases for regular annotators? These have the annotator's class as the "key", IIRC. > uv3: Adding getLogger() method in flow controllers > -- > > Key: UIMA-5565 > URL: https://issues.apache.org/jira/browse/UIMA-5565 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Richard Eckart de Castilho > > How about adding a getLogger() method also in CasFlowController_ImplBase / > JCasFlowController_ImplBase? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5566) uv3 change way 0-length arrays are created, remove new (in v3) APIs for them
Marshall Schor created UIMA-5566: Summary: uv3 change way 0-length arrays are created, remove new (in v3) APIs for them Key: UIMA-5566 URL: https://issues.apache.org/jira/browse/UIMA-5566 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 3.0.0SDK-alpha02 Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta I rediscovered that some of the deserialization code (e.g. xmi deserialization) has been deserializing empty lists by reusing a shared instance (for a particular CAS) of an empty list. This seems like Java's sharing of other immutable objects, such as Integer (when you say new Integer(4), it returns you a shared object; likewise, strings like "123" are merged and shared where possible). The 3.0.0-beta had previously introduced a bunch of methods on CAS and JCas to get shared 0-length arrays and lists. I'm think it would be good to remove all of these, and instead, just change the creation of these to automatically reuse shared (per CAS) instances of these. This has a small (tiny?) potential to "break" existing code, if code was written that depended on two different instances of, for example, an FSArray of length 0, were required to be !=. A recovery mechanism (workaround) for these probably very rare cases would be to enable the creation of non-equal instances, perhaps via the clone() method. Even this is probably not really needed, and deserialization would still be reusing shared values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5564) have deserializers reuse 0-length arrays and lists
[ https://issues.apache.org/jira/browse/UIMA-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5564: - Fix Version/s: (was: 2.10.2SDK) > have deserializers reuse 0-length arrays and lists > -- > > Key: UIMA-5564 > URL: https://issues.apache.org/jira/browse/UIMA-5564 > Project: UIMA > Issue Type: Improvement >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > Observed use cases show CASes containing lots of 0-length arrays or empty > lists. When these are deserialized from an xmi CAS where multi-ref features > are not specified (the default), these would be deserialized as individual > copies. Change this to reuse shared values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5564) have deserializers reuse 0-length arrays and lists
Marshall Schor created UIMA-5564: Summary: have deserializers reuse 0-length arrays and lists Key: UIMA-5564 URL: https://issues.apache.org/jira/browse/UIMA-5564 Project: UIMA Issue Type: Improvement Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta, 2.10.2SDK Observed use cases show CASes containing lots of 0-length arrays or empty lists. When these are deserialized from an xmi CAS where multi-ref features are not specified (the default), these would be deserialized as individual copies. Change this to reuse shared values. -- 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] [Updated] (UIMA-5558) xmi serialization/deserializtion of 0-length array being deserialized as null
[ https://issues.apache.org/jira/browse/UIMA-5558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5558: - Description: A user reports a serialization of a 0-length string array feature value is subsequently being deserialized as a null. The binary serialization/deserialization is correct, though. Also check JSON, and FSLists. was:A user reports a serialization of a 0-length string array feature value is subsequently being deserialized as a null. The binary serialization/deserialization is correct, though. > xmi serialization/deserializtion of 0-length array being deserialized as null > - > > Key: UIMA-5558 > URL: https://issues.apache.org/jira/browse/UIMA-5558 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta, 2.10.2SDK > > > A user reports a serialization of a 0-length string array feature value is > subsequently being deserialized as a null. The binary > serialization/deserialization is correct, though. > Also check JSON, and FSLists. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5556) uv3: Logging substitution does not work consistently
[
https://issues.apache.org/jira/browse/UIMA-5556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-5556.
--
Resolution: Fixed
This was a significant bug to catch; thanks for finding it!
> uv3: Logging substitution does not work consistently
>
>
> Key: UIMA-5556
> URL: https://issues.apache.org/jira/browse/UIMA-5556
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> The substitution of values in UIMA logging does not work consistently. E.g.
> for the following code
> {noformat}
> UIMAFramework.getLogger().warn("Skipping adding \"{0}\" to URLs", p);
> {noformat}
> Depending on the configured logging backend, I get different messages. E.g.
> with SLF4J, I get the broken:
> {noformat}
> 2017-09-08 14:45:42 WARN [main] (Misc) - Skipping adding "{0}" to URLs
> {noformat}
> while with what (I suppose) is the default UIMA logger used in the uimaFIT
> maven plugin, I get the correct
> {noformat}
> [WARNING] Skipping adding "" to URLs
> {noformat}
--
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] [Resolved] (UIMA-5553) uv3: Ability to set just a parent classloader, but not classpath
[
https://issues.apache.org/jira/browse/UIMA-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-5553.
--
Resolution: Fixed
> uv3: Ability to set just a parent classloader, but not classpath
>
>
> Key: UIMA-5553
> URL: https://issues.apache.org/jira/browse/UIMA-5553
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> uimaFIT tries to set a custom classloader on a resource manager - but it does
> so without adding any additional classpath entries:
> {noformat}
> ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
> resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(),
> "", true);
> return resMgr;
> {noformat}
> With UV3, this call now produces a warning:
> {noformat}
> org.apache.uima.internal.util.Misc addUrlsFromPath(257) WARNING: Skipping
> adding "" to URLs
> {noformat}
> It would be nice to have a `resMgr.setExtensionClassPath` method that just
> sets the parent loader but without trying to add URLs.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (UIMA-5553) uv3: Ability to set just a parent classloader, but not classpath
[
https://issues.apache.org/jira/browse/UIMA-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161863#comment-16161863
]
Marshall Schor commented on UIMA-5553:
--
I don't feel strongly... So I'm fine changing it, but would capitalize
ClassLoader like Java does, so we don't have yet another capitalization ("L" of
Loader capitalized).
> uv3: Ability to set just a parent classloader, but not classpath
>
>
> Key: UIMA-5553
> URL: https://issues.apache.org/jira/browse/UIMA-5553
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> uimaFIT tries to set a custom classloader on a resource manager - but it does
> so without adding any additional classpath entries:
> {noformat}
> ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
> resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(),
> "", true);
> return resMgr;
> {noformat}
> With UV3, this call now produces a warning:
> {noformat}
> org.apache.uima.internal.util.Misc addUrlsFromPath(257) WARNING: Skipping
> adding "" to URLs
> {noformat}
> It would be nice to have a `resMgr.setExtensionClassPath` method that just
> sets the parent loader but without trying to add URLs.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (UIMA-5556) uv3: Logging substitution does not work consistently
[
https://issues.apache.org/jira/browse/UIMA-5556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161861#comment-16161861
]
Marshall Schor commented on UIMA-5556:
--
I'm thinking of this approach:
1) For backwards compatibility, support UIMA logger calls as before, manually
doing the substitute calls before passing the message on.
2) for new logging APIs, support the {} syntax only, for faster logging, and
being consistent with current logging styles.
The new logging apis are things like logger.warn, logger.info, etc. rather than
logger.log(Level.INFO, ...).
Because these APIs are new, no backwards compatibility issue exists (for uima
loggers), and this is more consistent if the users are already using modern
loggers.
Does this seem OK?
> uv3: Logging substitution does not work consistently
>
>
> Key: UIMA-5556
> URL: https://issues.apache.org/jira/browse/UIMA-5556
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> The substitution of values in UIMA logging does not work consistently. E.g.
> for the following code
> {noformat}
> UIMAFramework.getLogger().warn("Skipping adding \"{0}\" to URLs", p);
> {noformat}
> Depending on the configured logging backend, I get different messages. E.g.
> with SLF4J, I get the broken:
> {noformat}
> 2017-09-08 14:45:42 WARN [main] (Misc) - Skipping adding "{0}" to URLs
> {noformat}
> while with what (I suppose) is the default UIMA logger used in the uimaFIT
> maven plugin, I get the correct
> {noformat}
> [WARNING] Skipping adding "" to URLs
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (UIMA-5556) uv3: Logging substitution does not work consistently
[
https://issues.apache.org/jira/browse/UIMA-5556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161711#comment-16161711
]
Marshall Schor commented on UIMA-5556:
--
It seems that slf4j and its various back-ends use a different format for
logging substitution: instead of {0} {1} etc., they use {} {} (that is,
without any inner parameter number).
Does anyone know a good way to bridge this difference?
> uv3: Logging substitution does not work consistently
>
>
> Key: UIMA-5556
> URL: https://issues.apache.org/jira/browse/UIMA-5556
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> The substitution of values in UIMA logging does not work consistently. E.g.
> for the following code
> {noformat}
> UIMAFramework.getLogger().warn("Skipping adding \"{0}\" to URLs", p);
> {noformat}
> Depending on the configured logging backend, I get different messages. E.g.
> with SLF4J, I get the broken:
> {noformat}
> 2017-09-08 14:45:42 WARN [main] (Misc) - Skipping adding "{0}" to URLs
> {noformat}
> while with what (I suppose) is the default UIMA logger used in the uimaFIT
> maven plugin, I get the correct
> {noformat}
> [WARNING] Skipping adding "" to URLs
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (UIMA-5558) xmi serialization/deserializtion of 0-length array being deserialized as null
Marshall Schor created UIMA-5558: Summary: xmi serialization/deserializtion of 0-length array being deserialized as null Key: UIMA-5558 URL: https://issues.apache.org/jira/browse/UIMA-5558 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta, 2.10.2SDK A user reports a serialization of a 0-length string array feature value is subsequently being deserialized as a null. The binary serialization/deserialization is correct, though. -- 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-5553) uv3: Ability to set just a parent classloader, but not classpath
[
https://issues.apache.org/jira/browse/UIMA-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159956#comment-16159956
]
Marshall Schor commented on UIMA-5553:
--
Is it OK if the new method has a slightly more accurate name, something like:
createAndInstallExtensionClassLoader (since it obviously doesn't set a class
path, and it's creating and installing an extension class loader)?
> uv3: Ability to set just a parent classloader, but not classpath
>
>
> Key: UIMA-5553
> URL: https://issues.apache.org/jira/browse/UIMA-5553
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> uimaFIT tries to set a custom classloader on a resource manager - but it does
> so without adding any additional classpath entries:
> {noformat}
> ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
> resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(),
> "", true);
> return resMgr;
> {noformat}
> With UV3, this call now produces a warning:
> {noformat}
> org.apache.uima.internal.util.Misc addUrlsFromPath(257) WARNING: Skipping
> adding "" to URLs
> {noformat}
> It would be nice to have a `resMgr.setExtensionClassPath` method that just
> sets the parent loader but without trying to add URLs.
--
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-5557) uv3: FSArray accessors seem not to be correctly generated
[
https://issues.apache.org/jira/browse/UIMA-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159413#comment-16159413
]
Marshall Schor commented on UIMA-5557:
--
V3 has a "checker" that looks at the JCas class definition (using reflection)
and tries to validate things. In this case, it sees a method that starts with
get and is followed by a capitalized feature name, and makes an (in this case,
incorrect) assumption that this is a getter for a UIMA feature.
This "error" doesn't cause a "throw" - it is merely noted, and things continue
on...
I probably should improve this a bit, by (for gets) seeing if the argument list
is either empty or a single item. (if the feature is an array), and for sets,
the same, but with the an extra argument being the value to set.
> uv3: FSArray accessors seem not to be correctly generated
> -
>
> Key: UIMA-5557
> URL: https://issues.apache.org/jira/browse/UIMA-5557
> Project: UIMA
> Issue Type: Bug
> Components: jcasgen-maven-plugin
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> With the UIMAv3 jcasgen, at runtime, I am seeing messages such as
> {noformat}
> 2017-09-08 15:00:29 WARN [main] (FSClassRegistry) - CAS type system type
> "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Compound" defines field
> "splits" with range "class org.apache.uima.jcas.cas.FSArray", but JCas getter
> method is returning "interface java.util.List" which is not a subtype of the
> declared range.
> {noformat}
> A user on the users mailing list reported a similar message when trying out
> UIMAv3:
> {noformat}
> JCAS range type uima.cas.FSArray for feature ... does not match the CAS range
> type uima.cas.StringArray for the feature
> {noformat}
--
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)
[jira] [Comment Edited] (UIMA-5553) uv3: Ability to set just a parent classloader, but not classpath
[
https://issues.apache.org/jira/browse/UIMA-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159346#comment-16159346
]
Marshall Schor edited comment on UIMA-5553 at 9/8/17 9:11 PM:
--
Are you asking for a method like resMgr.setExtensionClassPath(ClassLoader
parent, boolean resolveResource) that acts just like the one with the 3 args,
but doesn't give the warning message?
These calls create a new instance of a subtype of the URLClassLoader (typically
initialized with the classpath supplied).
was (Author: schor):
Are you asking for a method like resMgr.setExtensionClassPath(ClassLoader
parent, boolean resolveResource) that acts just like the one with the 3 args,
but doesn't give the warning message?
> uv3: Ability to set just a parent classloader, but not classpath
>
>
> Key: UIMA-5553
> URL: https://issues.apache.org/jira/browse/UIMA-5553
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> uimaFIT tries to set a custom classloader on a resource manager - but it does
> so without adding any additional classpath entries:
> {noformat}
> ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
> resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(),
> "", true);
> return resMgr;
> {noformat}
> With UV3, this call now produces a warning:
> {noformat}
> org.apache.uima.internal.util.Misc addUrlsFromPath(257) WARNING: Skipping
> adding "" to URLs
> {noformat}
> It would be nice to have a `resMgr.setExtensionClassPath` method that just
> sets the parent loader but without trying to add URLs.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (UIMA-5553) uv3: Ability to set just a parent classloader, but not classpath
[
https://issues.apache.org/jira/browse/UIMA-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159346#comment-16159346
]
Marshall Schor commented on UIMA-5553:
--
Are you asking for a method like resMgr.setExtensionClassPath(ClassLoader
parent, boolean resolveResource) that acts just like the one with the 3 args,
but doesn't give the warning message?
> uv3: Ability to set just a parent classloader, but not classpath
>
>
> Key: UIMA-5553
> URL: https://issues.apache.org/jira/browse/UIMA-5553
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> uimaFIT tries to set a custom classloader on a resource manager - but it does
> so without adding any additional classpath entries:
> {noformat}
> ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
> resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(),
> "", true);
> return resMgr;
> {noformat}
> With UV3, this call now produces a warning:
> {noformat}
> org.apache.uima.internal.util.Misc addUrlsFromPath(257) WARNING: Skipping
> adding "" to URLs
> {noformat}
> It would be nice to have a `resMgr.setExtensionClassPath` method that just
> sets the parent loader but without trying to add URLs.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (UIMA-5552) uv3: Get JCas instance in JCas class
[ https://issues.apache.org/jira/browse/UIMA-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5552. -- Resolution: Fixed excellent suggestion! I added a getJCas() method with a default impl to the FeatureStructure interface; is efficient, no exception thrown, etc. > uv3: Get JCas instance in JCas class > > > Key: UIMA-5552 > URL: https://issues.apache.org/jira/browse/UIMA-5552 > 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 > > > In the new JCas FS classes, it is no longer possible to access the JCas > instance conveniently. With UIMA v2, is was possible to get the JCas > containing a feature structure via `jcasType.jcas`. Now, one has to do a > `getCAS().getJCas()` but that requires catching a CASException. It would be > nice to have a convenience method `getJCas()` in JCas FS classes that does > not throw an exception. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5552) uv3: Get JCas instance in JCas class
[ https://issues.apache.org/jira/browse/UIMA-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5552: - Fix Version/s: 3.0.0SDK-beta > uv3: Get JCas instance in JCas class > > > Key: UIMA-5552 > URL: https://issues.apache.org/jira/browse/UIMA-5552 > 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 > > > In the new JCas FS classes, it is no longer possible to access the JCas > instance conveniently. With UIMA v2, is was possible to get the JCas > containing a feature structure via `jcasType.jcas`. Now, one has to do a > `getCAS().getJCas()` but that requires catching a CASException. It would be > nice to have a convenience method `getJCas()` in JCas FS classes that does > not throw an exception. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5550) Eclipse Update Site improvement for 3.0.0SDK
Marshall Schor created UIMA-5550: Summary: Eclipse Update Site improvement for 3.0.0SDK Key: UIMA-5550 URL: https://issues.apache.org/jira/browse/UIMA-5550 Project: UIMA Issue Type: Task Components: Eclipse plugins Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.0SDK Figure out how to drop the older versions (alpha and beta) from the eclipse update site for 3.0.0. Decide on a naming convention for the 3.0.0 "branch" if keeping separate. Figure out how to move older versions for v2 Uima to "archive" spot, not in the Apache "mirrors". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5543) uv3: cas binary deserialization may miss resetting CAS first
[ https://issues.apache.org/jira/browse/UIMA-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5543. -- Resolution: Fixed > uv3: cas binary deserialization may miss resetting CAS first > > > Key: UIMA-5543 > URL: https://issues.apache.org/jira/browse/UIMA-5543 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The reinit() method in BinaryCasSerDes fails to reset the cas, and in > particular, the getDocumentAnnotation method gets an old version which has a > wrong type system instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5547) some CAS deserializations skipping CAS Reset
[ https://issues.apache.org/jira/browse/UIMA-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5547. -- Resolution: Fixed > some CAS deserializations skipping CAS Reset > > > Key: UIMA-5547 > URL: https://issues.apache.org/jira/browse/UIMA-5547 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The cas complete deserialization done by a test case in UIMA V3 had a strange > failure caused by some caching that wasn't cleared (and was holding on to > previously created 0-length primitive arrays shared by the JCas). > Check all the CAS deserialization paths to insure that non-delta ones do a > cas reset - to clear out possibly cached things. And check if extra reset is > needed when (re)installing type system, indexes, etc. - some is done in v3, > not sure about v2.. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (UIMA-2147) Generate static fields for type names and feature names in JCas wrappers
[ https://issues.apache.org/jira/browse/UIMA-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-2147: Assignee: Marshall Schor > Generate static fields for type names and feature names in JCas wrappers > > > Key: UIMA-2147 > URL: https://issues.apache.org/jira/browse/UIMA-2147 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.3.1SDK >Reporter: Richard Eckart de Castilho >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > It would be convient if the JCas wrapper generator would create static final > String fields for feature names and for the type name, e.g. > public static final String TYPE_NAME = "my.jcastypes.Type"; > public static final String FEAT_BEGIN = "begin"; > This would allow cleaner programming with JCas wrappers in cases where the > names are required. In particular it would allow to detect certain errors at > compile-time and facilitate refactoring. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5548) uv3 API rationalization and cleanup
[ https://issues.apache.org/jira/browse/UIMA-5548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5548. -- Resolution: Fixed > uv3 API rationalization and cleanup > --- > > Key: UIMA-5548 > URL: https://issues.apache.org/jira/browse/UIMA-5548 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > API cleanups: including uniform naming for create instead of createFromArray, > getEmptyXX-list/array for cas and jcas, with default implementations, > cleanups and clarifications for some javadocs, including describing moveTo > operation with and without typeOrder -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-2147) Generate static fields for type names and feature names in JCas wrappers
[ https://issues.apache.org/jira/browse/UIMA-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-2147. -- Resolution: Fixed fixed in v3. If need to backport this fix into v2, let's open another Jira :-) > Generate static fields for type names and feature names in JCas wrappers > > > Key: UIMA-2147 > URL: https://issues.apache.org/jira/browse/UIMA-2147 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.3.1SDK >Reporter: Richard Eckart de Castilho > Fix For: 3.0.0SDK-beta > > > It would be convient if the JCas wrapper generator would create static final > String fields for feature names and for the type name, e.g. > public static final String TYPE_NAME = "my.jcastypes.Type"; > public static final String FEAT_BEGIN = "begin"; > This would allow cleaner programming with JCas wrappers in cases where the > names are required. In particular it would allow to detect certain errors at > compile-time and facilitate refactoring. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-2147) Generate static fields for type names and feature names in JCas wrappers
[ https://issues.apache.org/jira/browse/UIMA-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16153982#comment-16153982 ] Marshall Schor commented on UIMA-2147: -- fixed in v3 under UIMA-4674, 11/3/16, change set 1767952. Not (yet) fixed in v2 > Generate static fields for type names and feature names in JCas wrappers > > > Key: UIMA-2147 > URL: https://issues.apache.org/jira/browse/UIMA-2147 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.3.1SDK >Reporter: Richard Eckart de Castilho > Fix For: 3.0.0SDK-beta > > > It would be convient if the JCas wrapper generator would create static final > String fields for feature names and for the type name, e.g. > public static final String TYPE_NAME = "my.jcastypes.Type"; > public static final String FEAT_BEGIN = "begin"; > This would allow cleaner programming with JCas wrappers in cases where the > names are required. In particular it would allow to detect certain errors at > compile-time and facilitate refactoring. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-2147) Generate static fields for type names and feature names in JCas wrappers
[ https://issues.apache.org/jira/browse/UIMA-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-2147: - Fix Version/s: 3.0.0SDK-beta > Generate static fields for type names and feature names in JCas wrappers > > > Key: UIMA-2147 > URL: https://issues.apache.org/jira/browse/UIMA-2147 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.3.1SDK >Reporter: Richard Eckart de Castilho > Fix For: 3.0.0SDK-beta > > > It would be convient if the JCas wrapper generator would create static final > String fields for feature names and for the type name, e.g. > public static final String TYPE_NAME = "my.jcastypes.Type"; > public static final String FEAT_BEGIN = "begin"; > This would allow cleaner programming with JCas wrappers in cases where the > names are required. In particular it would allow to detect certain errors at > compile-time and facilitate refactoring. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5548) uv3 API rationalization and cleanup
Marshall Schor created UIMA-5548: Summary: uv3 API rationalization and cleanup Key: UIMA-5548 URL: https://issues.apache.org/jira/browse/UIMA-5548 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 3.0.0SDK-alpha02 Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta API cleanups: including uniform naming for create instead of createFromArray, getEmptyXX-list/array for cas and jcas, with default implementations, cleanups and clarifications for some javadocs, including describing moveTo operation with and without typeOrder -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5546) uv3 rework iterator use of typeOrder
[ https://issues.apache.org/jira/browse/UIMA-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5546. -- Resolution: Fixed > uv3 rework iterator use of typeOrder > > > Key: UIMA-5546 > URL: https://issues.apache.org/jira/browse/UIMA-5546 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > Simplify the implementation of the feature of the select API to create > iterators which can bypass type order. Make a universal > iterator(orderNotNeeded, ignoreType) API, pushing the implementation of these > into the iterator framework (instead of subiterator impl). Change subiterator > impl to focus on boundaries and iteration styles (strict, unambiguous, etc). > Change select API to use new iterator creation apis. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5504) uv3 cleanup iterator classes
[ https://issues.apache.org/jira/browse/UIMA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5504. -- Resolution: Fixed > uv3 cleanup iterator classes > > > Key: UIMA-5504 > URL: https://issues.apache.org/jira/browse/UIMA-5504 > Project: UIMA > Issue Type: Improvement >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > general iterator refactoring and cleanup, remove duplicate code by > refactoring to common spots, make uniform the copy-on-write support across > all iterators / indexes as appropriate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5470) ReDo AllFSs to support excluding the merely reachables
[ https://issues.apache.org/jira/browse/UIMA-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5470. -- Resolution: Fixed > ReDo AllFSs to support excluding the merely reachables > -- > > Key: UIMA-5470 > URL: https://issues.apache.org/jira/browse/UIMA-5470 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > some operations (Comparing 2 CASs) work better when starting from just the > set of indexed FSs. Rework the AllFSs class to support this. Update the > callers as needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5497) uv3 copy on write generation bugs
[ https://issues.apache.org/jira/browse/UIMA-5497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5497. -- Resolution: Fixed > uv3 copy on write generation bugs > - > > Key: UIMA-5497 > URL: https://issues.apache.org/jira/browse/UIMA-5497 > Project: UIMA > Issue Type: Bug >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > Race condition possible in copy on write generation. Also missing for bag. > unify parts with more sharing via refactoring, guarantee no gc of weak ref > before can hold on to it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5479) uv3 performance bug - FsIterator_subtypes_ordered not using custom comparator
[ https://issues.apache.org/jira/browse/UIMA-5479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5479. -- Resolution: Fixed > uv3 performance bug - FsIterator_subtypes_ordered not using custom comparator > - > > Key: UIMA-5479 > URL: https://issues.apache.org/jira/browse/UIMA-5479 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > Most uses of Sorted UIMA indexes for comparing FSs make use of custom > comparators for Annotation indexes (versus using the general purpose > comparator). But the implementation of FsIterator_subtypes_ordered fails to > use this one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5454) uv3 refactor feature structure compare for wider use cases + more accurate Cas Compare mode
[ https://issues.apache.org/jira/browse/UIMA-5454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5454. -- Resolution: Fixed > uv3 refactor feature structure compare for wider use cases + more accurate > Cas Compare mode > --- > > Key: UIMA-5454 > URL: https://issues.apache.org/jira/browse/UIMA-5454 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > BinaryCasSerDes6 has general CAS compare methods, currently set up for equal > / not-equal with error reporting for not-equal (used in testing). For other > uses, it is helpful to be able to "sort" feature structures; so change some > parts of this to return -1 0 1 instead of true/false, and allow use without > error reporting. Use this new capability to have a mode for CAS compare that > does a more thorough sorting of the FSs for a more accurate compare. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5544) XmiCasDeserializer test doing invalid cas building - causes error in uv3
[ https://issues.apache.org/jira/browse/UIMA-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151002#comment-16151002 ] Marshall Schor commented on UIMA-5544: -- only fixed the test case > XmiCasDeserializer test doing invalid cas building - causes error in uv3 > > > Key: UIMA-5544 > URL: https://issues.apache.org/jira/browse/UIMA-5544 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta, 2.10.2SDK > > > The XmiCasDeserializerTest does an invalid operation: It runs two tests > sequentially (in the same method), with a cas reset inbetween them. But the > first test creates two FSs which are held in Java local variables, and reused > after the CAS has been reset (they were never recreated after the CAS was > reset). > This causes some strange behavior in Uima V3 (in its current state), which > trips a runtime check. The easy fix is to recreate the two FSs after the cas > reset. > Besides fixing the test case, maybe add a (maybe optional) catcher for these > kinds of errors: something like detecting if a FS that was created in CAS nnn > (where nnn is different for different CASs and different "resets" of the same > CAS) is attempted to be set as a reference in another CASnnn. Or maybe this > is overdesign, since no one's complained... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5544) XmiCasDeserializer test doing invalid cas building - causes error in uv3
[ https://issues.apache.org/jira/browse/UIMA-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5544. -- Resolution: Fixed > XmiCasDeserializer test doing invalid cas building - causes error in uv3 > > > Key: UIMA-5544 > URL: https://issues.apache.org/jira/browse/UIMA-5544 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta, 2.10.2SDK > > > The XmiCasDeserializerTest does an invalid operation: It runs two tests > sequentially (in the same method), with a cas reset inbetween them. But the > first test creates two FSs which are held in Java local variables, and reused > after the CAS has been reset (they were never recreated after the CAS was > reset). > This causes some strange behavior in Uima V3 (in its current state), which > trips a runtime check. The easy fix is to recreate the two FSs after the cas > reset. > Besides fixing the test case, maybe add a (maybe optional) catcher for these > kinds of errors: something like detecting if a FS that was created in CAS nnn > (where nnn is different for different CASs and different "resets" of the same > CAS) is attempted to be set as a reference in another CASnnn. Or maybe this > is overdesign, since no one's complained... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5409) uv3 migrate tool not skipping built-in classes
[ https://issues.apache.org/jira/browse/UIMA-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5409. -- Resolution: Done lost track of where this got fixed > uv3 migrate tool not skipping built-in classes > -- > > Key: UIMA-5409 > URL: https://issues.apache.org/jira/browse/UIMA-5409 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > migrate tool not skipping built-in classes, categorizing them in reports > incorrectly as a result. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5496) uv3 replace FsIndex_set_sorted, apply many fixes to replaced one
[ https://issues.apache.org/jira/browse/UIMA-5496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5496. -- Resolution: Fixed > uv3 replace FsIndex_set_sorted, apply many fixes to replaced one > > > Key: UIMA-5496 > URL: https://issues.apache.org/jira/browse/UIMA-5496 > Project: UIMA > Issue Type: Improvement >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The first implementation of FsIndex_set_sorted assumed the underlying index > was implemented by OrderedFsSet_array2. This did a complex set of tradeoffs > that improved insert/remove performance at the expense of more complex > iteration. The OrderedFsSet_array2 impl was complex and was buggy (many bugs > were removed, though, in this most recent commit). > This implementation was based on "NavigableSet" apis, which required creation > of multiple iterators as direction of iteration was reversed, and was quite > complex. > This change reverts both of these to a simpler more straight forward > implementation, closer to how UIMA v2 did this, but with significant > improvements in both iteration and insert/remove. The underlying > OrderedFsSet_array keeps the indexed items for one type in a compacted array, > with free space possible at the begin and/or end, and rebalancing done as > needed. The iterator implementation removed several layers of indirection > and is now implemented directly on top of the OrderedFsSet_array itself. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5471) Better CasCompre code, move to own class
[ https://issues.apache.org/jira/browse/UIMA-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5471. -- Resolution: Fixed change sets 1806955 1806846 1803747 1800335 > Better CasCompre code, move to own class > > > Key: UIMA-5471 > URL: https://issues.apache.org/jira/browse/UIMA-5471 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > BinaryCasSerDes6 has a cas compare routine, used more generally. Break out > into its own class, change callers. Make the compare do a better job of > comparing, handling not just unequal type systems, but also better handling > of FsRefs and arrays. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5408) uv3 migrate missing report of duplicates
[ https://issues.apache.org/jira/browse/UIMA-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5408. -- Resolution: Fixed changed the logic to handle duplicates as duplicates (all instances are migrated). > uv3 migrate missing report of duplicates > > > Key: UIMA-5408 > URL: https://issues.apache.org/jira/browse/UIMA-5408 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > logic bug stops reports from printing after first one returns false. Reverse > order of && tests to insure subsequent reports run. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5536) uv3 remove positionUsesType from select api
[ https://issues.apache.org/jira/browse/UIMA-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150960#comment-16150960 ] Marshall Schor commented on UIMA-5536: -- went back to the original v2 implementation, for backwards compatibility. Removed this from select apis. > uv3 remove positionUsesType from select api > --- > > Key: UIMA-5536 > URL: https://issues.apache.org/jira/browse/UIMA-5536 > Project: UIMA > Issue Type: Bug >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The select API attempts to combine some of uimaFIT's capability for > iterating. The design included a configuration choice "positionUsesType". > This was implemented incorrectly for some cases, and it seems it would be > hard to fix. This Jira suggests removing it altogether. > What it does: It affects two bits of iterator operation: > # moveTo(fs) - move to the leftmost item that "matches" fs > # for bounded iterators: skip the item which is "equal" to the bound. > Details: The "matches" in 1) is based on the comparator for the index. For > Annotation indexes, this includes the typePriority. However, the select API > framework by default doesn't use type priorities (can be configured though). > This means, if the underlying iterator is using type priorities, then doing a > moveTo on it will move to a spot which might not be the "left-most" when type > priorities are not used. The correction for this has two flavors: depending > on the setting of positionUsesType. If not specified, the correction worked, > and moved to the left-most same-begin-end-ignoring-type. If specified, the > correction was ignoring this, and a fix would need to scan in both directions > to find the right type. Although this could be done, it's complex. And I > think this is designing beyond a real need. > Use 2 is for skipping the bounding annotation when iterating (if it is in the > index). The normal mode for skipping is to skip only the item if it is == > identical to the bounding annotation. But (for UIMA v2 bounded iterator > compatibility) a mode where the compare is done using the Annotation > Comparator is provided. The positionUsesType would narrow this equal test by > also requiring that the types match. I think this is unnecessarily complex, > since I think most uses will be using the == style. > So I propose to remove positionUsesType from the implementation / > documentation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5536) uv3 remove positionUsesType from select api
[ https://issues.apache.org/jira/browse/UIMA-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5536. -- Resolution: Fixed > uv3 remove positionUsesType from select api > --- > > Key: UIMA-5536 > URL: https://issues.apache.org/jira/browse/UIMA-5536 > Project: UIMA > Issue Type: Bug >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The select API attempts to combine some of uimaFIT's capability for > iterating. The design included a configuration choice "positionUsesType". > This was implemented incorrectly for some cases, and it seems it would be > hard to fix. This Jira suggests removing it altogether. > What it does: It affects two bits of iterator operation: > # moveTo(fs) - move to the leftmost item that "matches" fs > # for bounded iterators: skip the item which is "equal" to the bound. > Details: The "matches" in 1) is based on the comparator for the index. For > Annotation indexes, this includes the typePriority. However, the select API > framework by default doesn't use type priorities (can be configured though). > This means, if the underlying iterator is using type priorities, then doing a > moveTo on it will move to a spot which might not be the "left-most" when type > priorities are not used. The correction for this has two flavors: depending > on the setting of positionUsesType. If not specified, the correction worked, > and moved to the left-most same-begin-end-ignoring-type. If specified, the > correction was ignoring this, and a fix would need to scan in both directions > to find the right type. Although this could be done, it's complex. And I > think this is designing beyond a real need. > Use 2 is for skipping the bounding annotation when iterating (if it is in the > index). The normal mode for skipping is to skip only the item if it is == > identical to the bounding annotation. But (for UIMA v2 bounded iterator > compatibility) a mode where the compare is done using the Annotation > Comparator is provided. The positionUsesType would narrow this equal test by > also requiring that the types match. I think this is unnecessarily complex, > since I think most uses will be using the == style. > So I propose to remove positionUsesType from the implementation / > documentation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5534) uv3 subiterator fixups
[ https://issues.apache.org/jira/browse/UIMA-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5534. -- Resolution: Fixed > uv3 subiterator fixups > -- > > Key: UIMA-5534 > URL: https://issues.apache.org/jira/browse/UIMA-5534 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The subiterator impl has lots of small fixups needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5523) uv3 wrong test in one iterator impl for index becoming non-empty
[ https://issues.apache.org/jira/browse/UIMA-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5523. -- Resolution: Done lost the details but should be fixed > uv3 wrong test in one iterator impl for index becoming non-empty > > > Key: UIMA-5523 > URL: https://issues.apache.org/jira/browse/UIMA-5523 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > a test to see if an empty iterator is no longer empty is mistakenly testing > the copy-on-write version. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5519) uv3 clarify use of ll_indexsize - used incorrectly in one spot
[ https://issues.apache.org/jira/browse/UIMA-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5519. -- Resolution: Fixed fixed in change set 1803725 > uv3 clarify use of ll_indexsize - used incorrectly in one spot > -- > > Key: UIMA-5519 > URL: https://issues.apache.org/jira/browse/UIMA-5519 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > Given an iterator, there are two definitions of index size. One is the size > as seen by the iterator, which in v3, may not be the current index size > (because iterators iterate over a view of the index at a particular point in > time - either the time of iterator creation, or when a moveTo, moveToFirst, > or moveToLast operation happens (except for snapshot iterators)). The other > size is the current size of the index (and any sub-type indexes). > Change the name of the api to indicate this to reduce mistakes in the future. > Change uses which are incorrect (which need the current index size). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5505) uv3 APIs which take a UIMA Type instance, allow JCas class additionally, instead
[ https://issues.apache.org/jira/browse/UIMA-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5505. -- Resolution: Fixed fixed in change set 1803745 > uv3 APIs which take a UIMA Type instance, allow JCas class additionally, > instead > > > Key: UIMA-5505 > URL: https://issues.apache.org/jira/browse/UIMA-5505 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > Some methods which need a UIMA Type can take a Type instance, or the > corresponding JCas class. Extend this feature to more APIs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5453) uv3 select api index not set, causing NPE
[
https://issues.apache.org/jira/browse/UIMA-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-5453.
--
Resolution: Fixed
fixed in change set 1763809
> uv3 select api index not set, causing NPE
> -
>
> Key: UIMA-5453
> URL: https://issues.apache.org/jira/browse/UIMA-5453
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-alpha02
>Reporter: Marshall Schor
>Assignee: Marshall Schor
> Fix For: 3.0.0SDK-beta
>
>
> doing aCas.select("someTypeName").count() causes an NPE, because the index is
> null in the splititerator impl used to create the stream.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (UIMA-5410) uv3 migration tool sorting of reports sometimes throws exception
[ https://issues.apache.org/jira/browse/UIMA-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5410. -- Resolution: Fixed was fixed in commit 796919 under jira UIMA-5421 > uv3 migration tool sorting of reports sometimes throws exception > > > Key: UIMA-5410 > URL: https://issues.apache.org/jira/browse/UIMA-5410 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The reports does sorting; and the sort compare occasionally fails trying to > compare two File System objects. saying they are not compatible, when one of > them is a zip file system. Add work-around for this case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5407) uv3 migrate: throwing array index out of bounds
[ https://issues.apache.org/jira/browse/UIMA-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5407. -- Resolution: Done This must have been fixed along the way... didn't record enough info to identify further. > uv3 migrate: throwing array index out of bounds > --- > > Key: UIMA-5407 > URL: https://issues.apache.org/jira/browse/UIMA-5407 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > Running the migration tool in linux, Burn found a bug - throwing array index > out of bounds. Traced to using an "Optional" value instead of the actual > value. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5547) some CAS deserializations skipping CAS Reset
[ https://issues.apache.org/jira/browse/UIMA-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5547: - Description: The cas complete deserialization done by a test case in UIMA V3 had a strange failure caused by some caching that wasn't cleared (and was holding on to previously created 0-length primitive arrays shared by the JCas). Check all the CAS deserialization paths to insure that non-delta ones do a cas reset - to clear out possibly cached things. And check if extra reset is needed when (re)installing type system, indexes, etc. - some is done in v3, not sure about v2.. was: The cas complete deserialization done by a test case in UIMA V3 had a strange failure caused by some caching that wasn't cleared (and was holding on to previously created 0-length primitive arrays shared by the JCas). Check all the CAS deserialization paths to insure that non-delta ones do a cas reset - to clear out possibly cached things. And check if extra reset is needed when installing type system, indexes, etc. - some is done in v3, not sure about v2.. > some CAS deserializations skipping CAS Reset > > > Key: UIMA-5547 > URL: https://issues.apache.org/jira/browse/UIMA-5547 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The cas complete deserialization done by a test case in UIMA V3 had a strange > failure caused by some caching that wasn't cleared (and was holding on to > previously created 0-length primitive arrays shared by the JCas). > Check all the CAS deserialization paths to insure that non-delta ones do a > cas reset - to clear out possibly cached things. And check if extra reset is > needed when (re)installing type system, indexes, etc. - some is done in v3, > not sure about v2.. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5547) some CAS deserializations skipping CAS Reset
[ https://issues.apache.org/jira/browse/UIMA-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5547: - Description: The cas complete deserialization done by a test case in UIMA V3 had a strange failure caused by some caching that wasn't cleared (and was holding on to previously created 0-length primitive arrays shared by the JCas). Check all the CAS deserialization paths to insure that non-delta ones do a cas reset - to clear out possibly cached things. And check if extra reset is needed when installing type system, indexes, etc. - some is done in v3, not sure about v2.. was: The cas complete deserialization done by a test case in UIMA V3 had a strange failure caused by some caching that wasn't cleared (and was holding on to previously created DocumentAnnotation feature structure). Check all the CAS deserialization paths to insure that non-delta ones do a cas reset - to clear out possibly cached things (such as the 0-length primitive arrays accessible via the JCas). > some CAS deserializations skipping CAS Reset > > > Key: UIMA-5547 > URL: https://issues.apache.org/jira/browse/UIMA-5547 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The cas complete deserialization done by a test case in UIMA V3 had a strange > failure caused by some caching that wasn't cleared (and was holding on to > previously created 0-length primitive arrays shared by the JCas). > Check all the CAS deserialization paths to insure that non-delta ones do a > cas reset - to clear out possibly cached things. And check if extra reset is > needed when installing type system, indexes, etc. - some is done in v3, not > sure about v2.. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5547) some CAS deserializations skipping CAS Reset
Marshall Schor created UIMA-5547: Summary: some CAS deserializations skipping CAS Reset Key: UIMA-5547 URL: https://issues.apache.org/jira/browse/UIMA-5547 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta The cas complete deserialization done by a test case in UIMA V3 had a strange failure caused by some caching that wasn't cleared (and was holding on to previously created DocumentAnnotation feature structure). Check all the CAS deserialization paths to insure that non-delta ones do a cas reset - to clear out possibly cached things (such as the 0-length primitive arrays accessible via the JCas). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5546) uv3 rework iterator use of typeOrder
Marshall Schor created UIMA-5546: Summary: uv3 rework iterator use of typeOrder Key: UIMA-5546 URL: https://issues.apache.org/jira/browse/UIMA-5546 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta Simplify the implementation of the feature of the select API to create iterators which can bypass type order. Make a universal iterator(orderNotNeeded, ignoreType) API, pushing the implementation of these into the iterator framework (instead of subiterator impl). Change subiterator impl to focus on boundaries and iteration styles (strict, unambiguous, etc). Change select API to use new iterator creation apis. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (UIMA-5383) uv3 migration tool: allow Java-style classpath notation with wildcard
[ https://issues.apache.org/jira/browse/UIMA-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-5383: Assignee: Marshall Schor > uv3 migration tool: allow Java-style classpath notation with wildcard > - > > Key: UIMA-5383 > URL: https://issues.apache.org/jira/browse/UIMA-5383 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework, Tools >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > A user specified the classpath in the migration tool using the java style > wildcard; this didn't work. Add support for this, modeled after the approach > in uimaj-bootstrap. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (UIMA-4671) UV3 Internal - use default methods in interfaces to reduce code duplication
[ https://issues.apache.org/jira/browse/UIMA-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-4671: Assignee: Marshall Schor > UV3 Internal - use default methods in interfaces to reduce code duplication > --- > > Key: UIMA-4671 > URL: https://issues.apache.org/jira/browse/UIMA-4671 > Project: UIMA > Issue Type: Sub-task > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > Java 8 adds default methods for interfaces; use these where appropriate to > reduce code duplication. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5544) XmiCasDeserializer test doing invalid cas building - causes error in uv3
Marshall Schor created UIMA-5544: Summary: XmiCasDeserializer test doing invalid cas building - causes error in uv3 Key: UIMA-5544 URL: https://issues.apache.org/jira/browse/UIMA-5544 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.10.2SDK, 3.0.0SDK-beta The XmiCasDeserializerTest does an invalid operation: It runs two tests sequentially (in the same method), with a cas reset inbetween them. But the first test creates two FSs which are held in Java local variables, and reused after the CAS has been reset (they were never recreated after the CAS was reset). This causes some strange behavior in Uima V3 (in its current state), which trips a runtime check. The easy fix is to recreate the two FSs after the cas reset. Besides fixing the test case, maybe add a (maybe optional) catcher for these kinds of errors: something like detecting if a FS that was created in CAS nnn (where nnn is different for different CASs and different "resets" of the same CAS) is attempted to be set as a reference in another CASnnn. Or maybe this is overdesign, since no one's complained... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5543) uv3: cas binary deserialization may miss resetting CAS first
Marshall Schor created UIMA-5543: Summary: uv3: cas binary deserialization may miss resetting CAS first Key: UIMA-5543 URL: https://issues.apache.org/jira/browse/UIMA-5543 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta The reinit() method in BinaryCasSerDes fails to reset the cas, and in particular, the getDocumentAnnotation method gets an old version which has a wrong type system instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
