[jira] [Resolved] (UIMA-4793) Unable to localize exceptions when using alternative classloader
[
https://issues.apache.org/jira/browse/UIMA-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-4793.
--
Resolution: Fixed
added transient - this fixes the immediate issue of making this class
serializable.
> Unable to localize exceptions when using alternative classloader
>
>
> Key: UIMA-4793
> URL: https://issues.apache.org/jira/browse/UIMA-4793
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 2.8.1SDK
>Reporter: Richard Eckart de Castilho
>Assignee: Marshall Schor
> Fix For: 2.10.1SDK, 3.0.0SDK-alpha, 2.9.0SDK
>
>
> If a component is initialized through a resource manager with a custom
> classloader, then it may not have access to its localized exception message
> bundles.
> The reason is, that within the classloader chain, the CL which knows about
> the Core UIMA framework is at a higher level than the CL used by the resource
> manager that created the component. The component CL would have access to the
> message bundle, but InterationalizedException uses it's own classloader (the
> higher level one that knows about Core UIMA) to load message bundles:
> {noformat}
> // locate the resource bundle for this exception's messages
> // turn over the classloader of the current object explicitly, so
> that the
> // message resolving also works for derived exception classes
> ResourceBundle bundle = ResourceBundle.getBundle(
>getResourceBundleName(), aLocale, this.getClass()
> .getClassLoader());
> {noformat}
> {noformat}
> Thread [main] (Suspended (exception MissingResourceException))
> owns: PrintWriter (id=92)
> owns: ThrowableInformation (id=93)
> owns: ConsoleAppender (id=94)
> owns: RootLogger (id=95)
> ResourceBundle.throwMissingResourceException(String, Locale, Throwable)
> line: 1564
> ResourceBundle.getBundleImpl(String, Locale, ClassLoader,
> ResourceBundle$Control) line: 1387
> ResourceBundle.getBundle(String, Locale, ClassLoader) line: 1082
>
> AnalysisEngineProcessException(InternationalizedException).getLocalizedMessage(Locale)
> line: 240
>
> AnalysisEngineProcessException(InternationalizedException).getLocalizedMessage()
> line: 218
> AnalysisEngineProcessException(Throwable).toString() line: 480
> String.valueOf(Object) line: 2994
> PrintWriter.println(Object) line: 754
> Throwable$WrappedPrintWriter.println(Object) line: 764
>
> AnalysisEngineProcessException(Throwable).printStackTrace(Throwable$PrintStreamOrWriter)
> line: 655
> AnalysisEngineProcessException(Throwable).printStackTrace(PrintWriter)
> line: 721
> DefaultThrowableRenderer.render(Throwable) line: 60
> ThrowableInformation.getThrowableStrRep() line: 87
> LoggingEvent.getThrowableStrRep() line: 413
> ConsoleAppender(WriterAppender).subAppend(LoggingEvent) line: 313
> ConsoleAppender(WriterAppender).append(LoggingEvent) line: 162
> ConsoleAppender(AppenderSkeleton).doAppend(LoggingEvent) line: 251
> AppenderAttachableImpl.appendLoopOnAppenders(LoggingEvent) line: 66
> Logger(Category).callAppenders(LoggingEvent) line: 206
> Logger(Category).forcedLog(String, Priority, Object, Throwable) line:
> 391
> Logger(Category).log(String, Priority, Object, Throwable) line: 856
> Log4jLogger_impl.log(Level, String, Throwable) line: 272
> PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(CAS) line:
> 417
> PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(CAS) line: 308
> PrimitiveAnalysisEngine_impl(AnalysisEngineImplBase).process(CAS) line:
> 269
> PrimitiveAnalysisEngine_impl(AnalysisEngineImplBase).process(JCas)
> line: 284
> AnalysisEngine$process.call(Object, Object) line: not available
> ...
> {noformat}
> The IMHO best way would be if UIMA would at try here to use the thread's
> context classloader - and maybe that UIMA actually sets the thread context
> classloader to the resource manager CL while running components... in my
> case, I already do that outside UIMA atm, so searching the thread CL would be
> sufficient for me atm.
> See also: https://issues.apache.org/jira/browse/UIMA-3692
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (UIMA-4793) Unable to localize exceptions when using alternative classloader
[
https://issues.apache.org/jira/browse/UIMA-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor updated UIMA-4793:
-
Fix Version/s: 2.10.1SDK
> Unable to localize exceptions when using alternative classloader
>
>
> Key: UIMA-4793
> URL: https://issues.apache.org/jira/browse/UIMA-4793
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 2.8.1SDK
>Reporter: Richard Eckart de Castilho
>Assignee: Marshall Schor
> Fix For: 2.9.0SDK, 3.0.0SDK-alpha, 2.10.1SDK
>
>
> If a component is initialized through a resource manager with a custom
> classloader, then it may not have access to its localized exception message
> bundles.
> The reason is, that within the classloader chain, the CL which knows about
> the Core UIMA framework is at a higher level than the CL used by the resource
> manager that created the component. The component CL would have access to the
> message bundle, but InterationalizedException uses it's own classloader (the
> higher level one that knows about Core UIMA) to load message bundles:
> {noformat}
> // locate the resource bundle for this exception's messages
> // turn over the classloader of the current object explicitly, so
> that the
> // message resolving also works for derived exception classes
> ResourceBundle bundle = ResourceBundle.getBundle(
>getResourceBundleName(), aLocale, this.getClass()
> .getClassLoader());
> {noformat}
> {noformat}
> Thread [main] (Suspended (exception MissingResourceException))
> owns: PrintWriter (id=92)
> owns: ThrowableInformation (id=93)
> owns: ConsoleAppender (id=94)
> owns: RootLogger (id=95)
> ResourceBundle.throwMissingResourceException(String, Locale, Throwable)
> line: 1564
> ResourceBundle.getBundleImpl(String, Locale, ClassLoader,
> ResourceBundle$Control) line: 1387
> ResourceBundle.getBundle(String, Locale, ClassLoader) line: 1082
>
> AnalysisEngineProcessException(InternationalizedException).getLocalizedMessage(Locale)
> line: 240
>
> AnalysisEngineProcessException(InternationalizedException).getLocalizedMessage()
> line: 218
> AnalysisEngineProcessException(Throwable).toString() line: 480
> String.valueOf(Object) line: 2994
> PrintWriter.println(Object) line: 754
> Throwable$WrappedPrintWriter.println(Object) line: 764
>
> AnalysisEngineProcessException(Throwable).printStackTrace(Throwable$PrintStreamOrWriter)
> line: 655
> AnalysisEngineProcessException(Throwable).printStackTrace(PrintWriter)
> line: 721
> DefaultThrowableRenderer.render(Throwable) line: 60
> ThrowableInformation.getThrowableStrRep() line: 87
> LoggingEvent.getThrowableStrRep() line: 413
> ConsoleAppender(WriterAppender).subAppend(LoggingEvent) line: 313
> ConsoleAppender(WriterAppender).append(LoggingEvent) line: 162
> ConsoleAppender(AppenderSkeleton).doAppend(LoggingEvent) line: 251
> AppenderAttachableImpl.appendLoopOnAppenders(LoggingEvent) line: 66
> Logger(Category).callAppenders(LoggingEvent) line: 206
> Logger(Category).forcedLog(String, Priority, Object, Throwable) line:
> 391
> Logger(Category).log(String, Priority, Object, Throwable) line: 856
> Log4jLogger_impl.log(Level, String, Throwable) line: 272
> PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(CAS) line:
> 417
> PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(CAS) line: 308
> PrimitiveAnalysisEngine_impl(AnalysisEngineImplBase).process(CAS) line:
> 269
> PrimitiveAnalysisEngine_impl(AnalysisEngineImplBase).process(JCas)
> line: 284
> AnalysisEngine$process.call(Object, Object) line: not available
> ...
> {noformat}
> The IMHO best way would be if UIMA would at try here to use the thread's
> context classloader - and maybe that UIMA actually sets the thread context
> classloader to the resource manager CL while running components... in my
> case, I already do that outside UIMA atm, so searching the thread CL would be
> sufficient for me atm.
> See also: https://issues.apache.org/jira/browse/UIMA-3692
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (UIMA-5538) add -D flag to enable Feature Structure tracing
[ https://issues.apache.org/jira/browse/UIMA-5538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5538. Resolution: Fixed > add -D flag to enable Feature Structure tracing > --- > > Key: UIMA-5538 > URL: https://issues.apache.org/jira/browse/UIMA-5538 > Project: UIMA > Issue Type: Test > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > There is a trace facility that traces creation and updating of feature > structures. It produces huge output, typically, so is only useful for > debugging purposes. > Currently, a re-compile is needed to turn it on/off. Add a -D jvm argument > to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5538) add -D flag to enable Feature Structure tracing
Marshall Schor created UIMA-5538: Summary: add -D flag to enable Feature Structure tracing Key: UIMA-5538 URL: https://issues.apache.org/jira/browse/UIMA-5538 Project: UIMA Issue Type: Test Components: Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.10.1SDK, 3.0.0SDK-beta There is a trace facility that traces creation and updating of feature structures. It produces huge output, typically, so is only useful for debugging purposes. Currently, a re-compile is needed to turn it on/off. Add a -D jvm argument to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (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 resolved UIMA-4671. -- Resolution: Fixed > 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 > 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] [Updated] (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 updated UIMA-4671: - Fix Version/s: 3.0.0SDK-beta > 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 > 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] [Closed] (UIMA-4945) regenerate serialize form 4 for SerDesTest4 for V3
[ https://issues.apache.org/jira/browse/UIMA-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-4945. Resolution: Done > regenerate serialize form 4 for SerDesTest4 for V3 > -- > > Key: UIMA-4945 > URL: https://issues.apache.org/jira/browse/UIMA-4945 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha >Reporter: Marshall Schor >Priority: Minor > > SerDesTest4 testWithPrevGenerated has parts disabled, pending regeneration of > previous serialized forms to used. These changed in V3, so regenerate them, > and put the tests back in. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5472) java.lang.ArrayIndexOutOfBoundsException with big CAS serialized
[ https://issues.apache.org/jira/browse/UIMA-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135913#comment-16135913 ] Marshall Schor commented on UIMA-5472: -- Not sure how to make progress on this... It kind of looks like some corruption of the CAS happened, somewhere else, that's causing this exception. If there's any way to make a test case that illustrates the failure, please attach to this Jira, and then we'll reproduce and fix this... Thanks! > java.lang.ArrayIndexOutOfBoundsException with big CAS serialized > > > Key: UIMA-5472 > URL: https://issues.apache.org/jira/browse/UIMA-5472 > Project: UIMA > Issue Type: Access > Components: Core Java Framework >Affects Versions: 2.9.0SDK > Environment: Ubuntu xenial amd64, openjdk-8-jdk >Reporter: Nelson RIvera > > I have a main program that serializes and deserializes a CAS using > XCASSerializer and XCASDeserializer. > With a big CAS ( CAS composed of many views, cas's serialized size equals 20 > MB) after serialize the CAS, deserializing the CAS i get the exception that > show below. With smaller Cas everything is good. > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException > at org.apache.uima.internal.util.IntVector.get(IntVector.java:239) > at > org.apache.uima.cas.impl.XCASDeserializer$XCASDeserializerHandler.handleFeature(XCASDeserializer.java:580) > at > org.apache.uima.cas.impl.XCASDeserializer$XCASDeserializerHandler.readFS(XCASDeserializer.java:442) > at > org.apache.uima.cas.impl.XCASDeserializer$XCASDeserializerHandler.readFS(XCASDeserializer.java:300) > at > org.apache.uima.cas.impl.XCASDeserializer$XCASDeserializerHandler.startElement(XCASDeserializer.java:244) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509) > at > com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:351) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2784) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:841) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:770) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) > at > org.apache.uima.cas.impl.XCASDeserializer.deserialize(XCASDeserializer.java:1212) > at > org.apache.uima.cas.impl.XCASDeserializer.deserialize(XCASDeserializer.java:1181) > at > org.platform.xuima.modeling.tool.MainXCluster.main(MainXCluster.java:121) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5513) Fix docs for job descriptor override
[ https://issues.apache.org/jira/browse/UIMA-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5513. Resolution: Duplicate > Fix docs for job descriptor override > > > Key: UIMA-5513 > URL: https://issues.apache.org/jira/browse/UIMA-5513 > Project: UIMA > Issue Type: Bug >Reporter: Rong Li > > Overrides are blank not comma separated -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5532) xmi/json serialization multiple-refs-allowed sometimes fails to serialize item
[ https://issues.apache.org/jira/browse/UIMA-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5532. Resolution: Fixed > xmi/json serialization multiple-refs-allowed sometimes fails to serialize item > -- > > Key: UIMA-5532 > URL: https://issues.apache.org/jira/browse/UIMA-5532 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02, 2.10.0SDK >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > The xmi/json common serialization code made a wrong assumption in the design. > It assumed that if a FS referenced from a feature slot marked as > MultipleReferencesAllowed, that all other feature slots which might have that > FS as a feature slot value also declared those slots as > MutlipleReferencesAllowed. > One use case occured where this was not the case. The implementation in that > case fails to serialize the shared FS, and subsequent deserialization (of > course) fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (UIMA-5532) xmi/json serialization multiple-refs-allowed sometimes fails to serialize item
[ https://issues.apache.org/jira/browse/UIMA-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reopened UIMA-5532: -- json test failing > xmi/json serialization multiple-refs-allowed sometimes fails to serialize item > -- > > Key: UIMA-5532 > URL: https://issues.apache.org/jira/browse/UIMA-5532 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02, 2.10.0SDK >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > The xmi/json common serialization code made a wrong assumption in the design. > It assumed that if a FS referenced from a feature slot marked as > MultipleReferencesAllowed, that all other feature slots which might have that > FS as a feature slot value also declared those slots as > MutlipleReferencesAllowed. > One use case occured where this was not the case. The implementation in that > case fails to serialize the shared FS, and subsequent deserialization (of > course) fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5411) Make the class/data path search for external settings explicit by requiring a path: prefix
[ https://issues.apache.org/jira/browse/UIMA-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5411. > Make the class/data path search for external settings explicit by requiring a > path: prefix > -- > > Key: UIMA-5411 > URL: https://issues.apache.org/jira/browse/UIMA-5411 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Burn Lewis >Assignee: Burn Lewis >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > Require a "path:" prefix when loading settings from the class or data path. > Use the dotted name format, similar to import by name. Files may optionally > have a "file:" prefix. NOTE - this is an incompatible change from the syntax > used in 2.10.0 under UIMA-5208 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5532) xmi/json serialization multiple-refs-allowed sometimes fails to serialize item
[ https://issues.apache.org/jira/browse/UIMA-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5532. > xmi/json serialization multiple-refs-allowed sometimes fails to serialize item > -- > > Key: UIMA-5532 > URL: https://issues.apache.org/jira/browse/UIMA-5532 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02, 2.10.0SDK >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > The xmi/json common serialization code made a wrong assumption in the design. > It assumed that if a FS referenced from a feature slot marked as > MultipleReferencesAllowed, that all other feature slots which might have that > FS as a feature slot value also declared those slots as > MutlipleReferencesAllowed. > One use case occured where this was not the case. The implementation in that > case fails to serialize the shared FS, and subsequent deserialization (of > course) fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5460) NPE in PearAnalysisEngineWrapper.createRM
[ https://issues.apache.org/jira/browse/UIMA-5460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5460. > NPE in PearAnalysisEngineWrapper.createRM > - > > Key: UIMA-5460 > URL: https://issues.apache.org/jira/browse/UIMA-5460 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.0SDK >Reporter: Alessandro Di Bari >Assignee: Marshall Schor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > The method CreateRM in the class PearAnalysisEngineWrapper throws an NPE on > line 122: > rsrcMgr.setCasManager(parentResourceManager.getCasManager()); > because parentResourceManager is NULL. > In my case, I have seen this exception in 2 cases: > 1) When datapath was not set in the PEAR (or in the context) > 2) When my PEAR was referring another PEAR > I guess this is also the case documented in the code itself where it says > that parentResourceManager CAN be NULL (indeed the NULL on that parameter is > also previously checked in the code...). > // could be null for top level Pear not in an aggregate > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5435) UIMA Class Loader getResource doesn't look first in its own resources
[ https://issues.apache.org/jira/browse/UIMA-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5435. > UIMA Class Loader getResource doesn't look first in its own resources > - > > Key: UIMA-5435 > URL: https://issues.apache.org/jira/browse/UIMA-5435 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02, 2.10.0SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > The UIMAClassLoader stategy is to load from this class loader before > delegating to its parent. It does this for classes, but missed doing this > for "resources" obtained by getResource. > I think this should be fixed so that a Pear, trying to load its resource, > will get that resource, and not a same-named one from some parent > classloader. > This might break some existing use cases, as it changes where some resources > will come from. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5533) improve sorted index insert and faster findEq when lots of equal items
[ https://issues.apache.org/jira/browse/UIMA-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5533. > improve sorted index insert and faster findEq when lots of equal items > -- > > Key: UIMA-5533 > URL: https://issues.apache.org/jira/browse/UIMA-5533 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.10.0SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK > > > Use the same technique used in UIMA v3 for sorted indexes to sort by their > comparator, and then if equal, to sort by their FS hashcode (== id). This > fixes a performance problem when there's lots of comparator-equal (but not > identical) FSs added to a sorted index. It also makes the iteration order > consistent with UIMA V3, enabling verification/compares of the two versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5524) add test case for all varieties of rattling iterators
[ https://issues.apache.org/jira/browse/UIMA-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5524. Resolution: Fixed > add test case for all varieties of rattling iterators > - > > Key: UIMA-5524 > URL: https://issues.apache.org/jira/browse/UIMA-5524 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > do a thorough test of all edge cases of rattling iterators, using random > number to create variety. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5495) Set Index implicit use of type in comparator - document and add test case
[ https://issues.apache.org/jira/browse/UIMA-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5495. Resolution: Not A Problem was documented, and in test case > Set Index implicit use of type in comparator - document and add test case > - > > Key: UIMA-5495 > URL: https://issues.apache.org/jira/browse/UIMA-5495 > Project: UIMA > Issue Type: Improvement >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > UIMA Set indexes are implemented such that the type is an implicit part of > the key set used for determining equality. In other words, two Feature > Structures of different types, but with the same key values for a Set index > comparator, will not compare equal; both will be added to the set. Document > this, and add a test case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5369) java9 javadoc requires defs for annotations
[ https://issues.apache.org/jira/browse/UIMA-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5369: - Fix Version/s: (was: 2.10.1SDK) > java9 javadoc requires defs for annotations > --- > > Key: UIMA-5369 > URL: https://issues.apache.org/jira/browse/UIMA-5369 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.1SDK > > > Several things need fixups to allow Java 9 builds. > # add a which triggers on 9 > # the compiler target level needs to be set to 1.9 > # the compiler needs an additional argument to include the javax.xml.bind > module, which is otherwise no longer available. > # The javadoc needs to specify the javadocVersion, otherwise it fails to > discover it and uses 0, which causes the "tag" options to be ignored. > # The file FSRBTIndex is completely commented out in v3. Javadoc complains. > Move this to the unused-saved folder... > # Some javadoc errors involving trailing and tags. > # 1 error due to using a no-longer available "setAccessible" on a method > # 2 xml miscompares of generated formatted XML due to different formatting > styles -- 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=16129397#comment-16129397 ] Marshall Schor commented on UIMA-5536: -- Here's a slight change to the implementation, to reduce the "surprise" (mismatch between user's expectations and what the system does). For the case where no typePriorities (either because none were specified, or because the "select" API was used without turning on typePriority): * For the move-to-leftmost one: have the move-to-left-most-one include the types in the compare. This guarantees that if the index contains instances of that type, the iterator will find all of them that might be equal. And if one exists, it will be the first one returned. * For the skip when the bound is equal to the FS, have the equal include the type, if using v2 style bounded skipping. This matches the v2 implementation. > 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] [Updated] (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 updated UIMA-5536: - Description: 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. was: 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-ignorming-type. If specified, the correction was ignorning 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. > 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
[jira] [Created] (UIMA-5536) uv3 remove positionUsesType from select api
Marshall Schor created UIMA-5536: Summary: 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-ignorming-type. If specified, the correction was ignorning 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] [Created] (UIMA-5534) uv3 subiterator fixups
Marshall Schor created UIMA-5534: Summary: 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-5533) improve sorted index insert and faster findEq when lots of equal items
[ https://issues.apache.org/jira/browse/UIMA-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5533. -- Resolution: Fixed > improve sorted index insert and faster findEq when lots of equal items > -- > > Key: UIMA-5533 > URL: https://issues.apache.org/jira/browse/UIMA-5533 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.10.0SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK > > > Use the same technique used in UIMA v3 for sorted indexes to sort by their > comparator, and then if equal, to sort by their FS hashcode (== id). This > fixes a performance problem when there's lots of comparator-equal (but not > identical) FSs added to a sorted index. It also makes the iteration order > consistent with UIMA V3, enabling verification/compares of the two versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5533) improve sorted index insert and faster findEq when lots of equal items
[ https://issues.apache.org/jira/browse/UIMA-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5533: - Summary: improve sorted index insert and faster findEq when lots of equal items (was: improve sorted index insert when lots of equal items) > improve sorted index insert and faster findEq when lots of equal items > -- > > Key: UIMA-5533 > URL: https://issues.apache.org/jira/browse/UIMA-5533 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.10.0SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK > > > Use the same technique used in UIMA v3 for sorted indexes to sort by their > comparator, and then if equal, to sort by their FS hashcode (== id). This > fixes a performance problem when there's lots of comparator-equal (but not > identical) FSs added to a sorted index. It also makes the iteration order > consistent with UIMA V3, enabling verification/compares of the two versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5533) improve sorted index insert when lots of equal items
Marshall Schor created UIMA-5533: Summary: improve sorted index insert when lots of equal items Key: UIMA-5533 URL: https://issues.apache.org/jira/browse/UIMA-5533 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.10.0SDK Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.10.1SDK Use the same technique used in UIMA v3 for sorted indexes to sort by their comparator, and then if equal, to sort by their FS hashcode (== id). This fixes a performance problem when there's lots of comparator-equal (but not identical) FSs added to a sorted index. It also makes the iteration order consistent with UIMA V3, enabling verification/compares of the two versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5532) xmi/json serialization multiple-refs-allowed sometimes fails to serialize item
[ https://issues.apache.org/jira/browse/UIMA-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5532. -- Resolution: Fixed > xmi/json serialization multiple-refs-allowed sometimes fails to serialize item > -- > > Key: UIMA-5532 > URL: https://issues.apache.org/jira/browse/UIMA-5532 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02, 2.10.0SDK >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > The xmi/json common serialization code made a wrong assumption in the design. > It assumed that if a FS referenced from a feature slot marked as > MultipleReferencesAllowed, that all other feature slots which might have that > FS as a feature slot value also declared those slots as > MutlipleReferencesAllowed. > One use case occured where this was not the case. The implementation in that > case fails to serialize the shared FS, and subsequent deserialization (of > course) fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5532) xmi/json serialization multiple-refs-allowed sometimes fails to serialize item
Marshall Schor created UIMA-5532: Summary: xmi/json serialization multiple-refs-allowed sometimes fails to serialize item Key: UIMA-5532 URL: https://issues.apache.org/jira/browse/UIMA-5532 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.10.0SDK, 3.0.0SDK-alpha02 Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 2.10.1SDK, 3.0.0SDK-beta The xmi/json common serialization code made a wrong assumption in the design. It assumed that if a FS referenced from a feature slot marked as MultipleReferencesAllowed, that all other feature slots which might have that FS as a feature slot value also declared those slots as MutlipleReferencesAllowed. One use case occured where this was not the case. The implementation in that case fails to serialize the shared FS, and subsequent deserialization (of course) fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-4793) Unable to localize exceptions when using alternative classloader
[
https://issues.apache.org/jira/browse/UIMA-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120031#comment-16120031
]
Marshall Schor commented on UIMA-4793:
--
Good point. There are 2 factors involved in these messages:
* the message bundle - these are likely specific to each service, and it's
somewhat likely that the client won't have access to the message bundles
* the "locale": used to select among multiple language message bundles, and
also sets things like how numbers are formatted, etc.
The locale is often set from the machine environment the JVM is running in.
There could be an issue if, for example, someone in Germany was running UIMA
client connecting to a service running on a machine in Italy. The messages
might get translated to Italian, and sent back to the German client.
I don't think we need to provide support for this kind of scenario.
I do think we need to have remote services do their own message bundle lookups,
because I think it somewhat likely that a service would have messages defined
in its message bundle (specfic to that service, for example), that the client
would not have in its message bundle.
> Unable to localize exceptions when using alternative classloader
>
>
> Key: UIMA-4793
> URL: https://issues.apache.org/jira/browse/UIMA-4793
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 2.8.1SDK
>Reporter: Richard Eckart de Castilho
>Assignee: Marshall Schor
> Fix For: 2.9.0SDK, 3.0.0SDK-alpha
>
>
> If a component is initialized through a resource manager with a custom
> classloader, then it may not have access to its localized exception message
> bundles.
> The reason is, that within the classloader chain, the CL which knows about
> the Core UIMA framework is at a higher level than the CL used by the resource
> manager that created the component. The component CL would have access to the
> message bundle, but InterationalizedException uses it's own classloader (the
> higher level one that knows about Core UIMA) to load message bundles:
> {noformat}
> // locate the resource bundle for this exception's messages
> // turn over the classloader of the current object explicitly, so
> that the
> // message resolving also works for derived exception classes
> ResourceBundle bundle = ResourceBundle.getBundle(
>getResourceBundleName(), aLocale, this.getClass()
> .getClassLoader());
> {noformat}
> {noformat}
> Thread [main] (Suspended (exception MissingResourceException))
> owns: PrintWriter (id=92)
> owns: ThrowableInformation (id=93)
> owns: ConsoleAppender (id=94)
> owns: RootLogger (id=95)
> ResourceBundle.throwMissingResourceException(String, Locale, Throwable)
> line: 1564
> ResourceBundle.getBundleImpl(String, Locale, ClassLoader,
> ResourceBundle$Control) line: 1387
> ResourceBundle.getBundle(String, Locale, ClassLoader) line: 1082
>
> AnalysisEngineProcessException(InternationalizedException).getLocalizedMessage(Locale)
> line: 240
>
> AnalysisEngineProcessException(InternationalizedException).getLocalizedMessage()
> line: 218
> AnalysisEngineProcessException(Throwable).toString() line: 480
> String.valueOf(Object) line: 2994
> PrintWriter.println(Object) line: 754
> Throwable$WrappedPrintWriter.println(Object) line: 764
>
> AnalysisEngineProcessException(Throwable).printStackTrace(Throwable$PrintStreamOrWriter)
> line: 655
> AnalysisEngineProcessException(Throwable).printStackTrace(PrintWriter)
> line: 721
> DefaultThrowableRenderer.render(Throwable) line: 60
> ThrowableInformation.getThrowableStrRep() line: 87
> LoggingEvent.getThrowableStrRep() line: 413
> ConsoleAppender(WriterAppender).subAppend(LoggingEvent) line: 313
> ConsoleAppender(WriterAppender).append(LoggingEvent) line: 162
> ConsoleAppender(AppenderSkeleton).doAppend(LoggingEvent) line: 251
> AppenderAttachableImpl.appendLoopOnAppenders(LoggingEvent) line: 66
> Logger(Category).callAppenders(LoggingEvent) line: 206
> Logger(Category).forcedLog(String, Priority, Object, Throwable) line:
> 391
> Logger(Category).log(String, Priority, Object, Throwable) line: 856
> Log4jLogger_impl.log(Level, String, Throwable) line: 272
> PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(CAS) line:
> 417
> PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(CAS) line: 308
>
[jira] [Commented] (UIMA-4793) Unable to localize exceptions when using alternative classloader
[
https://issues.apache.org/jira/browse/UIMA-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119056#comment-16119056
]
Marshall Schor commented on UIMA-4793:
--
To fix this, we need to understand the desired behavior for serialization of
exceptions like this.
The first principle
* the exception is using message bundles,
** an indirection between the message-id and the actual message
Now, when you have one of these exceptions, and you want to serialize it, whose
message bundle should it be looked up in?
For DUCC, it would seem that the environment (service) creating the exception
probably needs to resolve the message bundle lookup in that same environment.
* Example: imagine you have a DUCC service, that creates an exception with a
message bundle key "my-special-service-key". Serializing that back to a client
as the raw (unresolved) exception, would require that the client have a message
bundle that defined "my-special-service-key".
A better design, it seems to me, is to convert messages that need to be
serialized to another environment to a form that doesn't use a message bundle
(the message bundle lookup already having been performed in the serializing
environment).
WDYT?
> Unable to localize exceptions when using alternative classloader
>
>
> Key: UIMA-4793
> URL: https://issues.apache.org/jira/browse/UIMA-4793
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 2.8.1SDK
>Reporter: Richard Eckart de Castilho
>Assignee: Marshall Schor
> Fix For: 2.9.0SDK, 3.0.0SDK-alpha
>
>
> If a component is initialized through a resource manager with a custom
> classloader, then it may not have access to its localized exception message
> bundles.
> The reason is, that within the classloader chain, the CL which knows about
> the Core UIMA framework is at a higher level than the CL used by the resource
> manager that created the component. The component CL would have access to the
> message bundle, but InterationalizedException uses it's own classloader (the
> higher level one that knows about Core UIMA) to load message bundles:
> {noformat}
> // locate the resource bundle for this exception's messages
> // turn over the classloader of the current object explicitly, so
> that the
> // message resolving also works for derived exception classes
> ResourceBundle bundle = ResourceBundle.getBundle(
>getResourceBundleName(), aLocale, this.getClass()
> .getClassLoader());
> {noformat}
> {noformat}
> Thread [main] (Suspended (exception MissingResourceException))
> owns: PrintWriter (id=92)
> owns: ThrowableInformation (id=93)
> owns: ConsoleAppender (id=94)
> owns: RootLogger (id=95)
> ResourceBundle.throwMissingResourceException(String, Locale, Throwable)
> line: 1564
> ResourceBundle.getBundleImpl(String, Locale, ClassLoader,
> ResourceBundle$Control) line: 1387
> ResourceBundle.getBundle(String, Locale, ClassLoader) line: 1082
>
> AnalysisEngineProcessException(InternationalizedException).getLocalizedMessage(Locale)
> line: 240
>
> AnalysisEngineProcessException(InternationalizedException).getLocalizedMessage()
> line: 218
> AnalysisEngineProcessException(Throwable).toString() line: 480
> String.valueOf(Object) line: 2994
> PrintWriter.println(Object) line: 754
> Throwable$WrappedPrintWriter.println(Object) line: 764
>
> AnalysisEngineProcessException(Throwable).printStackTrace(Throwable$PrintStreamOrWriter)
> line: 655
> AnalysisEngineProcessException(Throwable).printStackTrace(PrintWriter)
> line: 721
> DefaultThrowableRenderer.render(Throwable) line: 60
> ThrowableInformation.getThrowableStrRep() line: 87
> LoggingEvent.getThrowableStrRep() line: 413
> ConsoleAppender(WriterAppender).subAppend(LoggingEvent) line: 313
> ConsoleAppender(WriterAppender).append(LoggingEvent) line: 162
> ConsoleAppender(AppenderSkeleton).doAppend(LoggingEvent) line: 251
> AppenderAttachableImpl.appendLoopOnAppenders(LoggingEvent) line: 66
> Logger(Category).callAppenders(LoggingEvent) line: 206
> Logger(Category).forcedLog(String, Priority, Object, Throwable) line:
> 391
> Logger(Category).log(String, Priority, Object, Throwable) line: 856
> Log4jLogger_impl.log(Level, String, Throwable) line: 272
> PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(CAS) line:
> 417
> PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(CAS) line: 308
>
[jira] [Updated] (UIMA-5524) add test case for all varieties of rattling iterators
[ https://issues.apache.org/jira/browse/UIMA-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5524: - Fix Version/s: 2.10.1SDK > add test case for all varieties of rattling iterators > - > > Key: UIMA-5524 > URL: https://issues.apache.org/jira/browse/UIMA-5524 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > do a thorough test of all edge cases of rattling iterators, using random > number to create variety. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5524) add test case for all varieties of rattling iterators
Marshall Schor created UIMA-5524: Summary: add test case for all varieties of rattling iterators Key: UIMA-5524 URL: https://issues.apache.org/jira/browse/UIMA-5524 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta do a thorough test of all edge cases of rattling iterators, using random number to create variety. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5523) uv3 wrong test in one iterator impl for index becoming non-empty
Marshall Schor created UIMA-5523: Summary: 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] [Closed] (UIMA-5514) Fix docs for job descriptor override
[ https://issues.apache.org/jira/browse/UIMA-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5514. Resolution: Duplicate > Fix docs for job descriptor override > > > Key: UIMA-5514 > URL: https://issues.apache.org/jira/browse/UIMA-5514 > Project: UIMA > Issue Type: Bug >Reporter: Rong Li > > Overrides are blank not comma separated -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5518) Fix docs for job descriptor overrides
[ https://issues.apache.org/jira/browse/UIMA-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5518. Resolution: Duplicate > Fix docs for job descriptor overrides > - > > Key: UIMA-5518 > URL: https://issues.apache.org/jira/browse/UIMA-5518 > Project: UIMA > Issue Type: Bug >Reporter: Rong Li > > Overrides are blank not comma separated -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5516) Fix docs for job descriptor overrides
[ https://issues.apache.org/jira/browse/UIMA-5516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5516. Resolution: Duplicate > Fix docs for job descriptor overrides > - > > Key: UIMA-5516 > URL: https://issues.apache.org/jira/browse/UIMA-5516 > Project: UIMA > Issue Type: Bug >Reporter: Rong Li > > Overrides are blank not comma separated -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5515) Fix docs for job descriptor override
[ https://issues.apache.org/jira/browse/UIMA-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5515. Resolution: Duplicate > Fix docs for job descriptor override > > > Key: UIMA-5515 > URL: https://issues.apache.org/jira/browse/UIMA-5515 > Project: UIMA > Issue Type: Bug >Reporter: Rong Li > > Overrides are blank not comma separated -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (UIMA-5517) Fix docs for job descriptor overrides
[ https://issues.apache.org/jira/browse/UIMA-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5517. Resolution: Duplicate > Fix docs for job descriptor overrides > - > > Key: UIMA-5517 > URL: https://issues.apache.org/jira/browse/UIMA-5517 > Project: UIMA > Issue Type: Bug >Reporter: Rong Li > > Overrides are blank not comma separated -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5513) Fix docs for job descriptor override
[ https://issues.apache.org/jira/browse/UIMA-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107966#comment-16107966 ] Marshall Schor commented on UIMA-5513: -- There appear to be 6 other Jira issues identical to this one. If this is legitimate, please only file one Jira per issue. To address this more information would be needed, for example: what doc are you referring to? where is the part which is incorrect, etc. > Fix docs for job descriptor override > > > Key: UIMA-5513 > URL: https://issues.apache.org/jira/browse/UIMA-5513 > Project: UIMA > Issue Type: Bug >Reporter: Rong Li > > Overrides are blank not comma separated -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5519) uv3 clarify use of ll_indexsize - used incorrectly in one spot
Marshall Schor created UIMA-5519: Summary: 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] [Updated] (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 updated UIMA-5505: - Fix Version/s: 3.0.0SDK-beta Component/s: Core Java Framework > 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] [Created] (UIMA-5505) uv3 APIs which take a UIMA Type instance, allow JCas class additionally, instead
Marshall Schor created UIMA-5505: Summary: 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 Reporter: Marshall Schor Assignee: Marshall Schor 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] [Created] (UIMA-5504) uv3 cleanup iterator classes
Marshall Schor created UIMA-5504: Summary: 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] [Created] (UIMA-5497) uv3 copy on write generation bugs
Marshall Schor created UIMA-5497: Summary: 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] [Created] (UIMA-5496) uv3 replace FsIndex_set_sorted, apply many fixes to replaced one
Marshall Schor created UIMA-5496: Summary: 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] [Created] (UIMA-5495) Set Index implicit use of type in comparator - document and add test case
Marshall Schor created UIMA-5495: Summary: Set Index implicit use of type in comparator - document and add test case Key: UIMA-5495 URL: https://issues.apache.org/jira/browse/UIMA-5495 Project: UIMA Issue Type: Improvement Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.10.1SDK, 3.0.0SDK-beta UIMA Set indexes are implemented such that the type is an implicit part of the key set used for determining equality. In other words, two Feature Structures of different types, but with the same key values for a Set index comparator, will not compare equal; both will be added to the set. Document this, and add a test case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-4687) UV3 improve JCas feature id use for index corruption checking and journaling
[ https://issues.apache.org/jira/browse/UIMA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-4687. -- Resolution: Fixed > UV3 improve JCas feature id use for index corruption checking and journaling > > > Key: UIMA-4687 > URL: https://issues.apache.org/jira/browse/UIMA-4687 > Project: UIMA > Issue Type: Sub-task > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-alpha > > > When setting (changing) values for features, sometimes index corruption > checking needs to be done, and sometimes changes need to be journaled. Both > of these need to identify the feature involved. This operation should be > fast and memory-cache-friendly (e.g. not involve following a long chain of > dereferencings). > Add static final fields that represent features used by a particular JCas > class, which have names derived from the short-feature-name, and won't > collide with other names, and set these using the same JCasRegistry mechanism > to unique values within a class loader. This allows the same JCas cover > classes to be used with different type systems. > Change the corruption testing logic to use BitSets and have a version which > uses these indexes as well as one which uses the FeatureImpl featureCode. > Keep one extra table mapping these codes to FeatureImpls, per type system. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5483) uv3 exclude type order in index comparators if no type priorities are priorities are defined
[ https://issues.apache.org/jira/browse/UIMA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5483. -- Resolution: Fixed > uv3 exclude type order in index comparators if no type priorities are > priorities are defined > > > Key: UIMA-5483 > URL: https://issues.apache.org/jira/browse/UIMA-5483 > Project: UIMA > Issue Type: Improvement >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The Annotation Index (and any other user defined index which includes type > ordering) sorts using type ordering. However, if no type ordering is present > (there is typePriority specification in the pipeline xml). then this is a > no-op. UIMA V2 did some kind of default type ordering in this case. Update > V3 to exclude the type ordering test if there are no type priorities > specified (for performance improvement). Update the backward compatibility > spec to mention this difference. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (UIMA-4687) UV3 improve JCas feature id use for index corruption checking and journaling
[ https://issues.apache.org/jira/browse/UIMA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reopened UIMA-4687: -- Fix the type name used for some built-in JCas classes to match their official xml type names, where they differ from the JCas class name. > UV3 improve JCas feature id use for index corruption checking and journaling > > > Key: UIMA-4687 > URL: https://issues.apache.org/jira/browse/UIMA-4687 > Project: UIMA > Issue Type: Sub-task > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-alpha > > > When setting (changing) values for features, sometimes index corruption > checking needs to be done, and sometimes changes need to be journaled. Both > of these need to identify the feature involved. This operation should be > fast and memory-cache-friendly (e.g. not involve following a long chain of > dereferencings). > Add static final fields that represent features used by a particular JCas > class, which have names derived from the short-feature-name, and won't > collide with other names, and set these using the same JCasRegistry mechanism > to unique values within a class loader. This allows the same JCas cover > classes to be used with different type systems. > Change the corruption testing logic to use BitSets and have a version which > uses these indexes as well as one which uses the FeatureImpl featureCode. > Keep one extra table mapping these codes to FeatureImpls, per type system. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5483) uv3 exclude type order in index comparators if no type priorities are priorities are defined
[ https://issues.apache.org/jira/browse/UIMA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5483: - Summary: uv3 exclude type order in index comparators if no type priorities are priorities are defined (was: uv3 fix comparator for AnnotationIndex to exclude typePriority if no priorities are defined) > uv3 exclude type order in index comparators if no type priorities are > priorities are defined > > > Key: UIMA-5483 > URL: https://issues.apache.org/jira/browse/UIMA-5483 > Project: UIMA > Issue Type: Improvement >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The Annotation Index (and any other user defined index which includes type > ordering) sorts using type ordering. However, if no type ordering is present > (there is typePriority specification in the pipeline xml). then this is a > no-op. UIMA V2 did some kind of default type ordering in this case. Update > V3 to exclude the type ordering test if there are no type priorities > specified (for performance improvement). Update the backward compatibility > spec to mention this difference. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5483) uv3 fix comparator for AnnotationIndex to exclude typePriority if no priorities are defined
Marshall Schor created UIMA-5483: Summary: uv3 fix comparator for AnnotationIndex to exclude typePriority if no priorities are defined Key: UIMA-5483 URL: https://issues.apache.org/jira/browse/UIMA-5483 Project: UIMA Issue Type: Improvement Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta The Annotation Index (and any other user defined index which includes type ordering) sorts using type ordering. However, if no type ordering is present (there is typePriority specification in the pipeline xml). then this is a no-op. UIMA V2 did some kind of default type ordering in this case. Update V3 to exclude the type ordering test if there are no type priorities specified (for performance improvement). Update the backward compatibility spec to mention this difference. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5479) uv3 performance bug - FsIterator_subtypes_ordered not using custom comparator
Marshall Schor created UIMA-5479: Summary: 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-5478) OrderedFsSet_array has several infrequent problems
[ https://issues.apache.org/jira/browse/UIMA-5478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5478. -- Resolution: Fixed > OrderedFsSet_array has several infrequent problems > -- > > Key: UIMA-5478 > URL: https://issues.apache.org/jira/browse/UIMA-5478 > 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 > > > More extensive testing in a larger user application reveals some problems > with the main data structure used to implement sorted FS indexes in UV3. > Build a much more comprehensive test case that tests all kinds of adds and > removes, to uncover these, and fix them. Also,add IllegalArgumentException > for passing a null to add or remove. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5478) OrderedFsSet_array has several infrequent problems
Marshall Schor created UIMA-5478: Summary: OrderedFsSet_array has several infrequent problems Key: UIMA-5478 URL: https://issues.apache.org/jira/browse/UIMA-5478 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 More extensive testing in a larger user application reveals some problems with the main data structure used to implement sorted FS indexes in UV3. Build a much more comprehensive test case that tests all kinds of adds and removes, to uncover these, and fix them. Also,add IllegalArgumentException for passing a null to add or remove. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5471) Better CasCompre code, move to own class
Marshall Schor created UIMA-5471: Summary: 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] [Created] (UIMA-5470) ReDo AllFSs to support excluding the merely reachables
Marshall Schor created UIMA-5470: Summary: 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-5464) fixing typos in doc-uima-*.html pages
[ https://issues.apache.org/jira/browse/UIMA-5464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5464. -- Resolution: Fixed > fixing typos in doc-uima-*.html pages > - > > Key: UIMA-5464 > URL: https://issues.apache.org/jira/browse/UIMA-5464 > Project: UIMA > Issue Type: Documentation > Components: Website >Reporter: Paul M. Heider >Assignee: Marshall Schor > Attachments: UIMA-5464.patch > > > Two of the root documentation pages contain typos. > * https://uima.apache.org/doc-uima-examples.html > "...the complied sources" should read "...the compiled sources..." > "...the core Java SDK pacakge."Â should read "...the core Java SDK > package." > * https://uima.apache.org/doc-uima-annotator.html > "doesn't collide accidently with someone else use of that name." should > read "...accidentally with someone else's use..." > Patch attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (UIMA-5464) fixing typos in doc-uima-*.html pages
[ https://issues.apache.org/jira/browse/UIMA-5464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-5464: Assignee: Marshall Schor > fixing typos in doc-uima-*.html pages > - > > Key: UIMA-5464 > URL: https://issues.apache.org/jira/browse/UIMA-5464 > Project: UIMA > Issue Type: Documentation > Components: Website >Reporter: Paul M. Heider >Assignee: Marshall Schor > Attachments: UIMA-5464.patch > > > Two of the root documentation pages contain typos. > * https://uima.apache.org/doc-uima-examples.html > "...the complied sources" should read "...the compiled sources..." > "...the core Java SDK pacakge."Â should read "...the core Java SDK > package." > * https://uima.apache.org/doc-uima-annotator.html > "doesn't collide accidently with someone else use of that name." should > read "...accidentally with someone else's use..." > Patch attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (UIMA-5464) fixing typos in doc-uima-*.html pages
[ https://issues.apache.org/jira/browse/UIMA-5464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16061526#comment-16061526 ] Marshall Schor commented on UIMA-5464: -- Hi Paul, and thanks for the patches. I'll apply them. For future patches, it will help if you patch the /xdocs folder instead of the /docs folder, because the things in the /docs folder are generated from the files in /xdocs one. > fixing typos in doc-uima-*.html pages > - > > Key: UIMA-5464 > URL: https://issues.apache.org/jira/browse/UIMA-5464 > Project: UIMA > Issue Type: Documentation > Components: Website >Reporter: Paul M. Heider > Attachments: UIMA-5464.patch > > > Two of the root documentation pages contain typos. > * https://uima.apache.org/doc-uima-examples.html > "...the complied sources" should read "...the compiled sources..." > "...the core Java SDK pacakge."Â should read "...the core Java SDK > package." > * https://uima.apache.org/doc-uima-annotator.html > "doesn't collide accidently with someone else use of that name." should > read "...accidentally with someone else's use..." > Patch attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5463) uv3 add docs: bkwds compatibility: iterator order change
[ https://issues.apache.org/jira/browse/UIMA-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5463. -- Resolution: Fixed > uv3 add docs: bkwds compatibility: iterator order change > > > Key: UIMA-5463 > URL: https://issues.apache.org/jira/browse/UIMA-5463 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > UIMA defines iterators over an Index as "undefined" for FSs which compare > equal using the Index's comparator. For example, for Annotations, this is > based on the begin and end features, and the type via the type priority > ordering (if one exists). > UIMA v2 and v3 treat these undefined elements differently, and have different > iteration orders. For users who may have inadvertantly written code that > depends on iteration order for "equal" FSs, the results may differ. Document > this as part of the backward compatibility differences. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5463) uv3 add docs: bkwds compatibility: iterator order change
Marshall Schor created UIMA-5463: Summary: uv3 add docs: bkwds compatibility: iterator order change Key: UIMA-5463 URL: https://issues.apache.org/jira/browse/UIMA-5463 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta UIMA defines iterators over an Index as "undefined" for FSs which compare equal using the Index's comparator. For example, for Annotations, this is based on the begin and end features, and the type via the type priority ordering (if one exists). UIMA v2 and v3 treat these undefined elements differently, and have different iteration orders. For users who may have inadvertantly written code that depends on iteration order for "equal" FSs, the results may differ. Document this as part of the backward compatibility differences. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (UIMA-5460) NPE in PearAnalysisEngineWrapper.createRM
[ https://issues.apache.org/jira/browse/UIMA-5460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5460. -- Resolution: Fixed Assignee: Marshall Schor Fix Version/s: 3.0.0SDK-beta 2.10.1SDK > NPE in PearAnalysisEngineWrapper.createRM > - > > Key: UIMA-5460 > URL: https://issues.apache.org/jira/browse/UIMA-5460 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.0SDK >Reporter: Alessandro Di Bari >Assignee: Marshall Schor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > The method CreateRM in the class PearAnalysisEngineWrapper throws an NPE on > line 122: > rsrcMgr.setCasManager(parentResourceManager.getCasManager()); > because parentResourceManager is NULL. > In my case, I have seen this exception in 2 cases: > 1) When datapath was not set in the PEAR (or in the context) > 2) When my PEAR was referring another PEAR > I guess this is also the case documented in the code itself where it says > that parentResourceManager CAN be NULL (indeed the NULL on that parameter is > also previously checked in the code...). > // could be null for top level Pear not in an aggregate > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5454) uv3 refactor feature structure compare for wider use cases + more accurate Cas Compare mode
Marshall Schor created UIMA-5454: Summary: 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] [Created] (UIMA-5453) uv3 select api index not set, causing NPE
Marshall Schor created UIMA-5453:
Summary: 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-5442) uv3 backward compatibility: add casImpl v2 public methods for Type access
[ https://issues.apache.org/jira/browse/UIMA-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5442. -- Resolution: Fixed > uv3 backward compatibility: add casImpl v2 public methods for Type access > - > > Key: UIMA-5442 > URL: https://issues.apache.org/jira/browse/UIMA-5442 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The CASImpl implements is missing the isArrayType(Type) and > isAbstractArrayType(Type) methods in the v2 casImpl, add these for backwards > compatibility -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (UIMA-5446) uv3 xmi deserialization of arrays not handling null values properly
[ https://issues.apache.org/jira/browse/UIMA-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5446. -- Resolution: Fixed > uv3 xmi deserialization of arrays not handling null values properly > --- > > Key: UIMA-5446 > URL: https://issues.apache.org/jira/browse/UIMA-5446 > 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 > > > In serialized forms of FS arrays and lists, null values are represented by 0. > This is erroneously considered an error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5442) uv3 backward compatibility: add casImpl v2 public methods for Type access
[ https://issues.apache.org/jira/browse/UIMA-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5442: - Description: The CASImpl implements is missing the isArrayType(Type) and isAbstractArrayType(Type) methods in the v2 casImpl, add these for backwards compatibility (was: The CASImpl implements a set of methods to access the current type system, such as isStringType(Type), isArrayType(Type), etc. Some existing code is making use of these. Add these for backwards compatibility.) > uv3 backward compatibility: add casImpl v2 public methods for Type access > - > > Key: UIMA-5442 > URL: https://issues.apache.org/jira/browse/UIMA-5442 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > The CASImpl implements is missing the isArrayType(Type) and > isAbstractArrayType(Type) methods in the v2 casImpl, add these for backwards > compatibility -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5446) uv3 xmi deserialization of arrays not handling null values properly
[ https://issues.apache.org/jira/browse/UIMA-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5446: - Summary: uv3 xmi deserialization of arrays not handling null values properly (was: uv3 xmi/xcas deserialization of arrays not handling null values properly) > uv3 xmi deserialization of arrays not handling null values properly > --- > > Key: UIMA-5446 > URL: https://issues.apache.org/jira/browse/UIMA-5446 > 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 > > > In serialized forms of FS arrays and lists, null values are represented by 0. > This is erroneously considered an error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (UIMA-5446) uv3 xmi/xcas deserialization of arrays not handling null values properly
Marshall Schor created UIMA-5446: Summary: uv3 xmi/xcas deserialization of arrays not handling null values properly Key: UIMA-5446 URL: https://issues.apache.org/jira/browse/UIMA-5446 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 In serialized forms of FS arrays and lists, null values are represented by 0. This is erroneously considered an error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (UIMA-5442) uv3 backward compatibility: add casImpl v2 public methods for Type access
Marshall Schor created UIMA-5442: Summary: uv3 backward compatibility: add casImpl v2 public methods for Type access Key: UIMA-5442 URL: https://issues.apache.org/jira/browse/UIMA-5442 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta The CASImpl implements a set of methods to access the current type system, such as isStringType(Type), isArrayType(Type), etc. Some existing code is making use of these. Add these for backwards compatibility. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (UIMA-5421) uv3 migration tool design fixes
[ https://issues.apache.org/jira/browse/UIMA-5421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5421. -- Resolution: Fixed > uv3 migration tool design fixes > --- > > Key: UIMA-5421 > URL: https://issues.apache.org/jira/browse/UIMA-5421 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The design for the migration tool has some defects. The main one is it > should migrate all versions > # the migrate from sources vs from classes should operate differently: > ## sources > ##* migrate the source, no subsequent compilation; no reassembly (in Jars or > PEARs) > ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be > rebuilt and advising to delete the xxx_Type.java files. > ## classes > ##* decompile. Always use the original byte array for decompiling (current > impl switches to the version from the classpath). Arrange the migrate > classpath to put any Jar or Pear-classpath in front. > ##* do a compile using above modified migrate classpath (plus the uv3 core in > front) and reassembly step (if class was found in Jars or Pears, an no > compile errors) by copying the original assembly and updating the class part. > # change the output naming convention to support multiple compiled migrations > - for example, having the same class inside multiple updated Jars, with > obvious tracking between the output pathnames and the original. > # update the version of the parser and decompiler dependencies to the current > versions > # update the documentation. > # properly handle jars containing pears, pears containing jars. > # allow no migrate classpath when migrating from classes (useful for > migrating Pear files) > # break the compile step for a container into multiple sets of compilation > units, if different versions exist for the same classname (otherwise get > compiler error - duplicate definition) > # print out all compiler errors and messages -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5421) uv3 migration tool design fixes
[ https://issues.apache.org/jira/browse/UIMA-5421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5421: - Description: The design for the migration tool has some defects. The main one is it should migrate all versions # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Always use the original byte array for decompiling (current impl switches to the version from the classpath). Arrange the migrate classpath to put any Jar or Pear-classpath in front. ##* do a compile using above modified migrate classpath (plus the uv3 core in front) and reassembly step (if class was found in Jars or Pears, an no compile errors) by copying the original assembly and updating the class part. # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output pathnames and the original. # update the version of the parser and decompiler dependencies to the current versions # update the documentation. # properly handle jars containing pears, pears containing jars. # allow no migrate classpath when migrating from classes (useful for migrating Pear files) # break the compile step for a container into multiple sets of compilation units, if different versions exist for the same classname (otherwise get compiler error - duplicate definition) # print out all compiler errors and messages was: The design for the migration tool has some defects. The main one is it should migrate all versions # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Always use the original byte array for decompiling (current impl switches to the version from the classpath). Arrange the migrate classpath to put any Jar or Pear-classpath in front. ##* do a compile using above modified migrate classpath (plus uv3 in front) and reassembly step (if class was found in Jars or Pears, an no compile errors) by copying the original assembly and updating the class part, including deleting the xxx_Type.class files. # drop support for Jars inside Jars; only support the nesting case of Jars inside Pears because more general support makes the re-assembly step overly complex # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output pathnames and the original, based on a new concept of root-id, an incrementing int starting with 1, and suffixed with a J or P if for a Jar or a PEAR. # update the version of the parser and decompiler dependencies to the current versions # update the documentation. # switch to uniform way of internally identifying artifacts - rootId + fully qualified class name # properly handle jars containing pears, pears containing jars. > uv3 migration tool design fixes > --- > > Key: UIMA-5421 > URL: https://issues.apache.org/jira/browse/UIMA-5421 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The design for the migration tool has some defects. The main one is it > should migrate all versions > # the migrate from sources vs from classes should operate differently: > ## sources > ##* migrate the source, no subsequent compilation; no reassembly (in Jars or > PEARs) > ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be > rebuilt and advising to delete the xxx_Type.java files. > ## classes > ##* decompile. Always use the original byte array for decompiling (current > impl switches to the version from the classpath). Arrange the migrate > classpath to put any Jar or Pear-classpath in front. > ##* do a compile using above modified migrate classpath (plus the uv3 core in > front) and reassembly step (if class was found in Jars or Pears, an no > compile errors) by copying the original assembly and updating the class part. > # change the output naming convention to support multiple compiled migrations > - for example, having the same class inside multiple updated Jars, with > obvious tracking between the output pathnames and the original. > # update the
[jira] [Resolved] (UIMA-5435) UIMA Class Loader getResource doesn't look first in its own resources
[ https://issues.apache.org/jira/browse/UIMA-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5435. -- Resolution: Fixed > UIMA Class Loader getResource doesn't look first in its own resources > - > > Key: UIMA-5435 > URL: https://issues.apache.org/jira/browse/UIMA-5435 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-alpha02, 2.10.0SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > The UIMAClassLoader stategy is to load from this class loader before > delegating to its parent. It does this for classes, but missed doing this > for "resources" obtained by getResource. > I think this should be fixed so that a Pear, trying to load its resource, > will get that resource, and not a same-named one from some parent > classloader. > This might break some existing use cases, as it changes where some resources > will come from. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (UIMA-5435) UIMA Class Loader getResource doesn't look first in its own resources
Marshall Schor created UIMA-5435: Summary: UIMA Class Loader getResource doesn't look first in its own resources Key: UIMA-5435 URL: https://issues.apache.org/jira/browse/UIMA-5435 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.10.0SDK, 3.0.0SDK-alpha02 Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.10.1SDK, 3.0.0SDK-beta The UIMAClassLoader stategy is to load from this class loader before delegating to its parent. It does this for classes, but missed doing this for "resources" obtained by getResource. I think this should be fixed so that a Pear, trying to load its resource, will get that resource, and not a same-named one from some parent classloader. This might break some existing use cases, as it changes where some resources will come from. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (UIMA-5434) Misc utilities improvements in uimaj sdk core
[ https://issues.apache.org/jira/browse/UIMA-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5434. -- Resolution: Fixed > Misc utilities improvements in uimaj sdk core > - > > Key: UIMA-5434 > URL: https://issues.apache.org/jira/browse/UIMA-5434 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > # add classNameFromByteCode > # add setAsList (access a set of elements as a list, without making a list) > # support various pretty printing things with indentation control. Include a > list formatter that for short lists keeps things on one line, but for longer > lists, switches to an item per line format. > # add some javadoc comments > # add dumpByteArray - convert to nicely formatted string -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (UIMA-5434) Misc utilities improvements in uimaj sdk core
Marshall Schor created UIMA-5434: Summary: Misc utilities improvements in uimaj sdk core Key: UIMA-5434 URL: https://issues.apache.org/jira/browse/UIMA-5434 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 3.0.0SDK-beta # add classNameFromByteCode # add setAsList (access a set of elements as a list, without making a list) # support various pretty printing things with indentation control. Include a list formatter that for short lists keeps things on one line, but for longer lists, switches to an item per line format. # add some javadoc comments # add dumpByteArray - convert to nicely formatted string -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5421) uv3 migration tool design fixes
[ https://issues.apache.org/jira/browse/UIMA-5421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5421: - Description: The design for the migration tool has some defects. The main one is it should migrate all versions # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Always use the original byte array for decompiling (current impl switches to the version from the classpath). Arrange the migrate classpath to put any Jar or Pear-classpath in front. ##* do a compile using above modified migrate classpath (plus uv3 in front) and reassembly step (if class was found in Jars or Pears, an no compile errors) by copying the original assembly and updating the class part, including deleting the xxx_Type.class files. # drop support for Jars inside Jars; only support the nesting case of Jars inside Pears because more general support makes the re-assembly step overly complex # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output pathnames and the original, based on a new concept of root-id, an incrementing int starting with 1, and suffixed with a J or P if for a Jar or a PEAR. # update the version of the parser and decompiler dependencies to the current versions # update the documentation. # switch to uniform way of internally identifying artifacts - rootId + fully qualified class name # properly handle jars containing pears, pears containing jars. was: The design for the migration tool has some defects. The main one is it should migrate all versions # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Always use the original byte array for decompiling (current impl switches to the version from the classpath). Arrange the migrate classpath to put any Jar or Pear-classpath in front. ##* do a compile using above modified migrate classpath (plus uv3 in front) and reassembly step (if class was found in Jars or Pears, an no compile errors) by copying the original assembly and updating the class part, including deleting the xxx_Type.class files. # drop support for Jars inside Jars; only support the nesting case of Jars inside Pears because more general support makes the re-assembly step overly complex # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output pathnames and the original, based on a new concept of root-id, an incrementing int starting with 1, and suffixed with a J or P if for a Jar or a PEAR. # update the version of the parser and decompiler dependencies to the current versions # update the documentation. > uv3 migration tool design fixes > --- > > Key: UIMA-5421 > URL: https://issues.apache.org/jira/browse/UIMA-5421 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The design for the migration tool has some defects. The main one is it > should migrate all versions > # the migrate from sources vs from classes should operate differently: > ## sources > ##* migrate the source, no subsequent compilation; no reassembly (in Jars or > PEARs) > ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be > rebuilt and advising to delete the xxx_Type.java files. > ## classes > ##* decompile. Always use the original byte array for decompiling (current > impl switches to the version from the classpath). Arrange the migrate > classpath to put any Jar or Pear-classpath in front. > ##* do a compile using above modified migrate classpath (plus uv3 in front) > and reassembly step (if class was found in Jars or Pears, an no compile > errors) by copying the original assembly and updating the class part, > including deleting the xxx_Type.class files. > # drop support for Jars inside Jars; only support the nesting case of Jars > inside Pears because more general support makes the re-assembly step overly > complex > # change the output naming convention to support multiple compiled migrations > - for example, having
[jira] [Updated] (UIMA-5421) uv3 migration tool design fixes
[ https://issues.apache.org/jira/browse/UIMA-5421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5421: - Description: The design for the migration tool has some defects. The main one is it should migrate all versions # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Always use the original byte array for decompiling (current impl switches to the version from the classpath). Arrange the migrate classpath to put any Jar or Pear-classpath in front. ##* do a compile using above modified migrate classpath (plus uv3 in front) and reassembly step (if class was found in Jars or Pears, an no compile errors) by copying the original assembly and updating the class part, including deleting the xxx_Type.class files. # drop support for Jars inside Jars; only support the nesting case of Jars inside Pears because more general support makes the re-assembly step overly complex # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output pathnames and the original, based on a new concept of root-id, an incrementing int starting with 1, and suffixed with a J or P if for a Jar or a PEAR. # update the version of the parser and decompiler dependencies to the current versions # update the documentation. was: The design for the migration tool has some defects: # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Arrange the migrate classpath to put any Jar or Pear-classpath in front ##* do a compile using above modified migrate classpath (plus uv3 in front) and reassembly step (if class was found in Jars or Pears, an no compile errors) by copying the original assembly and updating the class part, including deleting the xxx_Type.class files. # drop support for Jars inside Jars; only support the nesting case of Jars inside Pears because more general support makes the re-assembly step overly complex # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output pathnames and the original, based on a new concept of root-id, an incrementing int starting with 1, and suffixed with a J or P if for a Jar or a PEAR. # update the version of the parser and decompiler dependencies to the current versions > uv3 migration tool design fixes > --- > > Key: UIMA-5421 > URL: https://issues.apache.org/jira/browse/UIMA-5421 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The design for the migration tool has some defects. The main one is it > should migrate all versions > # the migrate from sources vs from classes should operate differently: > ## sources > ##* migrate the source, no subsequent compilation; no reassembly (in Jars or > PEARs) > ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be > rebuilt and advising to delete the xxx_Type.java files. > ## classes > ##* decompile. Always use the original byte array for decompiling (current > impl switches to the version from the classpath). Arrange the migrate > classpath to put any Jar or Pear-classpath in front. > ##* do a compile using above modified migrate classpath (plus uv3 in front) > and reassembly step (if class was found in Jars or Pears, an no compile > errors) by copying the original assembly and updating the class part, > including deleting the xxx_Type.class files. > # drop support for Jars inside Jars; only support the nesting case of Jars > inside Pears because more general support makes the re-assembly step overly > complex > # change the output naming convention to support multiple compiled migrations > - for example, having the same class inside multiple updated Jars, with > obvious tracking between the output pathnames and the original, based on a > new concept of root-id, an incrementing int starting with 1, and suffixed > with a J or P if for a Jar or a PEAR. > # update the version of the parser and decompiler dependencies to the current > versions > # update
[jira] [Updated] (UIMA-5421) uv3 migration tool design fixes
[ https://issues.apache.org/jira/browse/UIMA-5421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5421: - Description: The design for the migration tool has some defects: # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Arrange the migrate classpath to put any Jar or Pear-classpath in front ##* do a compile using above modified migrate classpath (plus uv3 in front) and reassembly step (if class was found in Jars or Pears, an no compile errors) by copying the original assembly and updating the class part, including deleting the xxx_Type.class files. # drop support for Jars inside Jars; only support the nesting case of Jars inside Pears because more general support makes the re-assembly step overly complex # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output pathnames and the original, based on a new concept of root-id, an incrementing int starting with 1, and suffixed with a J or P if for a Jar or a PEAR. # update the version of the parser and decompiler dependencies to the current versions was: The design for the migration tool has some defects: # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Arrange the migrate classpath to put any Jar or Pear in front ##* do a compile using above modified migrate classpath (plus uv3 in front) and reassembly step (if class was found in Jars or Pears) by copying the original assembly and updating the class part, including deleting the xxx_Type.class files. # drop support for Jars inside Jars; only support the nesting case of Jars inside Pears because more general support makes the re-assembly step overly complex # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output Jar pathname and the original. # update the version of the parser and decompiler dependencies to the current versions > uv3 migration tool design fixes > --- > > Key: UIMA-5421 > URL: https://issues.apache.org/jira/browse/UIMA-5421 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The design for the migration tool has some defects: > # the migrate from sources vs from classes should operate differently: > ## sources > ##* migrate the source, no subsequent compilation; no reassembly (in Jars or > PEARs) > ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be > rebuilt and advising to delete the xxx_Type.java files. > ## classes > ##* decompile. Arrange the migrate classpath to put any Jar or > Pear-classpath in front > ##* do a compile using above modified migrate classpath (plus uv3 in front) > and reassembly step (if class was found in Jars or Pears, an no compile > errors) by copying the original assembly and updating the class part, > including deleting the xxx_Type.class files. > # drop support for Jars inside Jars; only support the nesting case of Jars > inside Pears because more general support makes the re-assembly step overly > complex > # change the output naming convention to support multiple compiled migrations > - for example, having the same class inside multiple updated Jars, with > obvious tracking between the output pathnames and the original, based on a > new concept of root-id, an incrementing int starting with 1, and suffixed > with a J or P if for a Jar or a PEAR. > # update the version of the parser and decompiler dependencies to the current > versions -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5421) uv3 migration tool design fixes
[ https://issues.apache.org/jira/browse/UIMA-5421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5421: - Description: The design for the migration tool has some defects: # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Arrange the migrate classpath to put any Jar or Pear in front ##* do a compile using above modified migrate classpath (plus uv3 in front) and reassembly step (if class was found in Jars or Pears) by copying the original assembly and updating the class part, including deleting the xxx_Type.class files. # drop support for Jars inside Jars; only support the nesting case of Jars inside Pears because more general support makes the re-assembly step overly complex # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output Jar pathname and the original. # update the version of the parser and decompiler dependencies to the current versions was: The design for the migration tool has some defects: # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Arrange the migrate classpath to put any Jar or Pear in front ##* do a compile and reassembly step (if class was found in Jars or Pears) by copying the original assembly and updating the class part, including deleting the xxx_Type.class files. # drop support for Jars inside Jars; only support the nesting case of Jars inside Pears because more general support makes the re-assembly step overly complex # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output Jar pathname and the original. # update the version of the parser and decompiler dependencies to the current versions > uv3 migration tool design fixes > --- > > Key: UIMA-5421 > URL: https://issues.apache.org/jira/browse/UIMA-5421 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > The design for the migration tool has some defects: > # the migrate from sources vs from classes should operate differently: > ## sources > ##* migrate the source, no subsequent compilation; no reassembly (in Jars or > PEARs) > ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be > rebuilt and advising to delete the xxx_Type.java files. > ## classes > ##* decompile. Arrange the migrate classpath to put any Jar or Pear in front > ##* do a compile using above modified migrate classpath (plus uv3 in front) > and reassembly step (if class was found in Jars or Pears) by copying the > original assembly and updating the class part, including deleting the > xxx_Type.class files. > # drop support for Jars inside Jars; only support the nesting case of Jars > inside Pears because more general support makes the re-assembly step overly > complex > # change the output naming convention to support multiple compiled migrations > - for example, having the same class inside multiple updated Jars, with > obvious tracking between the output Jar pathname and the original. > # update the version of the parser and decompiler dependencies to the current > versions -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (UIMA-5421) uv3 migration tool design fixes
Marshall Schor created UIMA-5421: Summary: uv3 migration tool design fixes Key: UIMA-5421 URL: https://issues.apache.org/jira/browse/UIMA-5421 Project: UIMA Issue Type: Bug Components: Core Java Framework, Tools Affects Versions: 3.0.0SDK-alpha02 Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.0SDK-beta The design for the migration tool has some defects: # the migrate from sources vs from classes should operate differently: ## sources ##* migrate the source, no subsequent compilation; no reassembly (in Jars or PEARs) ##* if in a Jar or PEAR, issue message saying Jar or PEAR will need to be rebuilt and advising to delete the xxx_Type.java files. ## classes ##* decompile. Arrange the migrate classpath to put any Jar or Pear in front ##* do a compile and reassembly step (if class was found in Jars or Pears) by copying the original assembly and updating the class part, including deleting the xxx_Type.class files. # drop support for Jars inside Jars; only support the nesting case of Jars inside Pears because more general support makes the re-assembly step overly complex # change the output naming convention to support multiple compiled migrations - for example, having the same class inside multiple updated Jars, with obvious tracking between the output Jar pathname and the original. # update the version of the parser and decompiler dependencies to the current versions -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5417) dd2spring should always ignore the scaleout value for sync UIMA-AS DDs
[ https://issues.apache.org/jira/browse/UIMA-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5417: - Description: This is about dd2spring treatment of the scaleout element, in one particular unusual use case. DD2Spring already has code to ignore the scaleout value, if the top-level-aggregate is marked "async=true". This is because that scaleout is only applicable for the case where async=false, and uima-as is scaling the top-level-aggregate by having multiple threads (= pipelines) replicating the top level aggregate. When async=true, the scaleout element is ignored, because uima-as will be (potentially) scaling out each async delegate separately. The use case here is all about "defaulting" the async=true/false. The current dd2spring code, if no specification is made for async=, defaults to async=false, unless the deployment descriptor has individual specs for the delgates, in which case it defaults to async=true. For this last case, dd2spring is missing the the code to ignore the scaleout parameter (if set > 1). This Jira is to add that check for that use case. It lets the scaleout value change the caspool size when the async attribute is defaulted to true (because the delegates element is specified, which implies async="true") . The current dd2spring code correctly ignores the scaleout element when the async attribute is explicitly set to "true" ... and it needs to do the same when the default is "true". was: It lets the scaleout value change the caspool size when the async attribute is defaulted while the delegates element is specified, which implies async="true". The scaleout element is ignored when the async attribute is explicitly set to "true" ... should do the same when the default is "true". > dd2spring should always ignore the scaleout value for sync UIMA-AS DDs > -- > > Key: UIMA-5417 > URL: https://issues.apache.org/jira/browse/UIMA-5417 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Burn Lewis >Priority: Minor > Fix For: 2.10.0AS > > > This is about dd2spring treatment of the scaleout element, in one particular > unusual use case. DD2Spring already has code to ignore the scaleout value, > if the top-level-aggregate is marked "async=true". This is because that > scaleout is only applicable for the case where async=false, and uima-as is > scaling the top-level-aggregate by having multiple threads (= pipelines) > replicating the top level aggregate. > When async=true, the scaleout element is ignored, because uima-as will be > (potentially) scaling out each async delegate separately. > The use case here is all about "defaulting" the async=true/false. The > current dd2spring code, if no specification is made for async=, defaults to > async=false, unless the deployment descriptor has individual specs for the > delgates, in which case it defaults to async=true. For this last case, > dd2spring is missing the the code to ignore the scaleout parameter (if set > > 1). This Jira is to add that check for that use case. > It lets the scaleout value change the caspool size when the async attribute > is defaulted to true (because the delegates element is specified, which > implies async="true") > . > The current dd2spring code correctly ignores the scaleout element when the > async attribute is explicitly set to "true" ... and it needs to do the same > when the default is "true". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (UIMA-5410) uv3 migration tool sorting of reports sometimes throws exception
Marshall Schor created UIMA-5410: Summary: 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.3.15#6346)
[jira] [Created] (UIMA-5409) uv3 migrate tool not skipping built-in classes
Marshall Schor created UIMA-5409: Summary: 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.3.15#6346)
[jira] [Created] (UIMA-5408) uv3 migrate missing report of duplicates
Marshall Schor created UIMA-5408: Summary: 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.3.15#6346)
[jira] [Created] (UIMA-5407) uv3 migrate: throwing array index out of bounds
Marshall Schor created UIMA-5407: Summary: 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.3.15#6346)
[jira] [Updated] (UIMA-5315) uv3 logging add some MDC/NDC info
[ https://issues.apache.org/jira/browse/UIMA-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5315: - Fix Version/s: (was: 3.0.0SDK-beta) 3.0.1SDK > uv3 logging add some MDC/NDC info > - > > Key: UIMA-5315 > URL: https://issues.apache.org/jira/browse/UIMA-5315 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.1SDK > > > Add the annotator name, and maybe the key, to the MDC for logging use. Figure > out about using NDC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (UIMA-5379) uv3 migration tool check for missing migrationClasspath
[ https://issues.apache.org/jira/browse/UIMA-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5379. -- Resolution: Fixed > uv3 migration tool check for missing migrationClasspath > --- > > Key: UIMA-5379 > URL: https://issues.apache.org/jira/browse/UIMA-5379 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework, Tools >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > A user tried migrating from compiled classes, without specifying the > classpath. There is a missing detection of this mis-configuration. There is > no proper handling if the decompile fails -the Java Parser is invoked on the > non-parsible !Error message. Fix both of these. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (UIMA-5388) Support javac style classpath specs in uima classpaths
[ https://issues.apache.org/jira/browse/UIMA-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5388. -- Resolution: Fixed > Support javac style classpath specs in uima classpaths > -- > > Key: UIMA-5388 > URL: https://issues.apache.org/jira/browse/UIMA-5388 > Project: UIMA > Issue Type: Improvement >Affects Versions: 3.0.0SDK-alpha02 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > Javac supported classpath specs with a trailing wildcard, which meant all the > jars or .class files rooted at the directory. Users may want to use this > style in specifying uima classpaths. (UIMA already supports classpaths which > are directories, which mean the same thing). Add this support, update the > docs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (UIMA-5359) uv3 set up svn spot for uv3 and dependent projects
[ https://issues.apache.org/jira/browse/UIMA-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5359. -- Resolution: Fixed > uv3 set up svn spot for uv3 and dependent projects > -- > > Key: UIMA-5359 > URL: https://issues.apache.org/jira/browse/UIMA-5359 > Project: UIMA > Issue Type: Task >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > UIMA v3 needs a more prominent spot in SVN. Sub-projects that depend on uv3 > need a spot too. These need to co-exist with v2 UIMA, since migration is > something that will occur over time, and early versions are needed for > testing. > The current svn layout: https://svn.apache.org/repos/asf/uima. > Under that we have > * addons (trunk, tags, branches) > * build (trunk, tags, branches) > * eclipse-packagings (archive, not currently used?) > * ruta (trunk, tags, branches) > * sandbox (trunk, tags, branches) > * site (trunk - this is the website) > * uima-as (trunk, tags, branches, depend-on-parent-pom-4 (to-be-deleted)) > * uimacpp (trunk, tags, branches) > * uima-ducc (trunk, tags, branches) > * uimafit (trunk, tags, branches) > * uimafit-v3 (trunk only) > * uimaj (trunk, tags, branches) > We could follow the convention started by uimafit, of adding a -v3 suffix. > We could put in a top level additional folder, say "uv3", and put exisiing > projects which have a v3 migration, there. > I'm not sure which is better. I suppose the additional high level folder > would keep the number of subfolders in the top level smaller, so might be a > good thing, so i'm leaning toward that. > Opinions? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (UIMA-5384) uv3 migration tool class path setup
[ https://issues.apache.org/jira/browse/UIMA-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5384. -- Resolution: Fixed > uv3 migration tool class path setup > --- > > Key: UIMA-5384 > URL: https://issues.apache.org/jira/browse/UIMA-5384 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > There are multiple issues with the migrateClasspath setup for v3 migration. > There are two uses of the classpath. > * One is for decompiling the v2 compiled classes, when migrating from classes > - roots. > * The other is for (optional) compiling of the resulting converted source. > These is done for the use case where the v2 classes were in JARs or PEARs, > and the result of the conversion is new versions of these JARs or PEARs with > converted JCas classes. > The classpath passed for migrateClasspath should be the v2 classpath needed > for decompiling the v2 JCas classes. When recompiling, the classpath for v3 > uimaj-core is prepended. > migrateClasspath is temporarily augmented when migrating PEAR files, by > prepending any PEAR classpath specs. > A separate Jira improved the migrateClasspath to permit the Java style of > classpath specs using a trailing wildcard (*). > Changes needed: > * if the migrateClasspath argument is not set: > ** if migrating from classes roots, treat this as an error; migrateClasspath > is required in order to properly decompile. > *** Add a note that this classpath must include the classes being migrated, > because they are read from that classpath. > ** If migrating from sources roots, if the migrateClasspath is not set, > substitute the application classpath, with a warning. > * for compiling: > *# do the PEAR prepending if the source came from a pear. > *# prepend at the very front, the uimaj-core-v3 (or the app classpath). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5369) java9 javadoc requires defs for annotations
[ https://issues.apache.org/jira/browse/UIMA-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5369: - Fix Version/s: (was: 3.0.0SDK-beta) 3.0.1SDK > java9 javadoc requires defs for annotations > --- > > Key: UIMA-5369 > URL: https://issues.apache.org/jira/browse/UIMA-5369 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.1SDK, 2.10.1SDK > > > Several things need fixups to allow Java 9 builds. > # add a which triggers on 9 > # the compiler target level needs to be set to 1.9 > # the compiler needs an additional argument to include the javax.xml.bind > module, which is otherwise no longer available. > # The javadoc needs to specify the javadocVersion, otherwise it fails to > discover it and uses 0, which causes the "tag" options to be ignored. > # The file FSRBTIndex is completely commented out in v3. Javadoc complains. > Move this to the unused-saved folder... > # Some javadoc errors involving trailing and tags. > # 1 error due to using a no-longer available "setAccessible" on a method > # 2 xml miscompares of generated formatted XML due to different formatting > styles -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5359) uv3 set up svn spot for uv3 and dependent projects
[ https://issues.apache.org/jira/browse/UIMA-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5359: - Fix Version/s: 3.0.0SDK-beta > uv3 set up svn spot for uv3 and dependent projects > -- > > Key: UIMA-5359 > URL: https://issues.apache.org/jira/browse/UIMA-5359 > Project: UIMA > Issue Type: Task >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > UIMA v3 needs a more prominent spot in SVN. Sub-projects that depend on uv3 > need a spot too. These need to co-exist with v2 UIMA, since migration is > something that will occur over time, and early versions are needed for > testing. > The current svn layout: https://svn.apache.org/repos/asf/uima. > Under that we have > * addons (trunk, tags, branches) > * build (trunk, tags, branches) > * eclipse-packagings (archive, not currently used?) > * ruta (trunk, tags, branches) > * sandbox (trunk, tags, branches) > * site (trunk - this is the website) > * uima-as (trunk, tags, branches, depend-on-parent-pom-4 (to-be-deleted)) > * uimacpp (trunk, tags, branches) > * uima-ducc (trunk, tags, branches) > * uimafit (trunk, tags, branches) > * uimafit-v3 (trunk only) > * uimaj (trunk, tags, branches) > We could follow the convention started by uimafit, of adding a -v3 suffix. > We could put in a top level additional folder, say "uv3", and put exisiing > projects which have a v3 migration, there. > I'm not sure which is better. I suppose the additional high level folder > would keep the number of subfolders in the top level smaller, so might be a > good thing, so i'm leaning toward that. > Opinions? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (UIMA-5369) java9 javadoc requires defs for annotations
[ https://issues.apache.org/jira/browse/UIMA-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15969129#comment-15969129 ] Marshall Schor commented on UIMA-5369: -- got Eclipse to load the subversion client by adding this to the eclipse.ini file at the bottom: --add-modules=java.se.ee --add-opens java.base/sun.security.ssl=ALL-UNNAMED The add-opens argument needed to be on a separate line to get it to work. > java9 javadoc requires defs for annotations > --- > > Key: UIMA-5369 > URL: https://issues.apache.org/jira/browse/UIMA-5369 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > Several things need fixups to allow Java 9 builds. > # add a which triggers on 9 > # the compiler target level needs to be set to 1.9 > # the compiler needs an additional argument to include the javax.xml.bind > module, which is otherwise no longer available. > # The javadoc needs to specify the javadocVersion, otherwise it fails to > discover it and uses 0, which causes the "tag" options to be ignored. > # The file FSRBTIndex is completely commented out in v3. Javadoc complains. > Move this to the unused-saved folder... > # Some javadoc errors involving trailing and tags. > # 1 error due to using a no-longer available "setAccessible" on a method > # 2 xml miscompares of generated formatted XML due to different formatting > styles -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (UIMA-5369) java9 javadoc requires defs for annotations
[ https://issues.apache.org/jira/browse/UIMA-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15969128#comment-15969128 ] Marshall Schor commented on UIMA-5369: -- I've managed to install a version of Eclipse that works with Java 9 (4.7 milestone 6 build + a Java9 addon enablement). It has bugs (e.g., I could not install the subversion plugin because the site it was picking this up from was https and there was some missing module for handling the https protocol). After adding an argument to both the compiler and the surefire running to include the javax.xml.bind "module" (which was part of standard Java 8 but no longer there in Java 9), most of the test cases ran. The failures were of 2 kinds: one where the test was using reflection to set "accessible" an otherwise unaccessable method, and the other having to do with XML formatting. The first has been locked down by Java 9, so not sure what to do other than drop that particular test. The second failure kind is an xml generation failure; the generated XML is having different notions of using whitespace to 'format' the output (putting in extra newlines and blanks), so the compare fails. I'm probably going to temporarily disable these tests with a conditional that will only be active for the "early-access" version of Java 9; this way we'll get a good reminder to attend to these issues (if they're still issues) when Java 9 is officially released. > java9 javadoc requires defs for annotations > --- > > Key: UIMA-5369 > URL: https://issues.apache.org/jira/browse/UIMA-5369 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > Several things need fixups to allow Java 9 builds. > # add a which triggers on 9 > # the compiler target level needs to be set to 1.9 > # the compiler needs an additional argument to include the javax.xml.bind > module, which is otherwise no longer available. > # The javadoc needs to specify the javadocVersion, otherwise it fails to > discover it and uses 0, which causes the "tag" options to be ignored. > # The file FSRBTIndex is completely commented out in v3. Javadoc complains. > Move this to the unused-saved folder... > # Some javadoc errors involving trailing and tags. > # 1 error due to using a no-longer available "setAccessible" on a method > # 2 xml miscompares of generated formatted XML due to different formatting > styles -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5369) java9 javadoc requires defs for annotations
[ https://issues.apache.org/jira/browse/UIMA-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5369: - Description: Several things need fixups to allow Java 9 builds. # add a which triggers on 9 # the compiler target level needs to be set to 1.9 # the compiler needs an additional argument to include the javax.xml.bind module, which is otherwise no longer available. # The javadoc needs to specify the javadocVersion, otherwise it fails to discover it and uses 0, which causes the "tag" options to be ignored. # The file FSRBTIndex is completely commented out in v3. Javadoc complains. Move this to the unused-saved folder... # Some javadoc errors involving trailing and tags. # 1 error due to using a no-longer available "setAccessible" on a method # 2 xml miscompares of generated formatted XML due to different formatting styles was: Several things need fixups to allow Java 9 builds. # add a which triggers on 1.9 # the compiler target level needs to be set to 1.9 # the compiler needs an additional argument to include the javax.xml.bind module, which is otherwise no longer available. # The javadoc needs to specify the javadocVersion, otherwise it fails to discover it and uses 0, which causes the "tag" options to be ignored. # The file FSRBTIndex is completely commented out in v3. Javadoc complains. Move this to the unused-saved folder... # Some errors involving trailing and tags. > java9 javadoc requires defs for annotations > --- > > Key: UIMA-5369 > URL: https://issues.apache.org/jira/browse/UIMA-5369 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > Several things need fixups to allow Java 9 builds. > # add a which triggers on 9 > # the compiler target level needs to be set to 1.9 > # the compiler needs an additional argument to include the javax.xml.bind > module, which is otherwise no longer available. > # The javadoc needs to specify the javadocVersion, otherwise it fails to > discover it and uses 0, which causes the "tag" options to be ignored. > # The file FSRBTIndex is completely commented out in v3. Javadoc complains. > Move this to the unused-saved folder... > # Some javadoc errors involving trailing and tags. > # 1 error due to using a no-longer available "setAccessible" on a method > # 2 xml miscompares of generated formatted XML due to different formatting > styles -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5369) java9 javadoc requires defs for annotations
[ https://issues.apache.org/jira/browse/UIMA-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5369: - Description: Several things need fixups to allow Java 9 builds. # add a which triggers on 1.9 # the compiler target level needs to be set to 1.9 # the compiler needs an additional argument to include the javax.xml.bind module, which is otherwise no longer available. # The javadoc needs to specify the javadocVersion, otherwise it fails to discover it and uses 0, which causes the "tag" options to be ignored. # The file FSRBTIndex is completely commented out in v3. Javadoc complains. Move this to the unused-saved folder... # Some errors involving trailing and tags. was: Several things need fixups to allow Java 9 builds. # the compiler target level needs to be set to 1.9 # the compiler needs an additional argument to include the javax.xml.bind module, which is otherwise no longer available. # The javadoc needs to specify the javadocVersion, otherwise it fails to discover it and uses 0, which causes the "tag" options to be ignored. # The file FSRBTIndex is completely commented out in v3. Javadoc complains. Move this to the unused-saved folder... # Some errors involving trailing and tags. > java9 javadoc requires defs for annotations > --- > > Key: UIMA-5369 > URL: https://issues.apache.org/jira/browse/UIMA-5369 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > Several things need fixups to allow Java 9 builds. > # add a which triggers on 1.9 > # the compiler target level needs to be set to 1.9 > # the compiler needs an additional argument to include the javax.xml.bind > module, which is otherwise no longer available. > # The javadoc needs to specify the javadocVersion, otherwise it fails to > discover it and uses 0, which causes the "tag" options to be ignored. > # The file FSRBTIndex is completely commented out in v3. Javadoc complains. > Move this to the unused-saved folder... > # Some errors involving trailing and tags. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5369) java9 javadoc requires defs for annotations
[ https://issues.apache.org/jira/browse/UIMA-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5369: - Description: Several things need fixups to allow Java 9 builds. # the compiler target level needs to be set to 1.9 # the compiler needs an additional argument to include the javax.xml.bind module, which is otherwise no longer available. # The javadoc needs to specify the javadocVersion, otherwise it fails to discover it and uses 0, which causes the "tag" options to be ignored. # The file FSRBTIndex is completely commented out in v3. Javadoc complains. Move this to the unused-saved folder... # Some errors involving trailing and tags. was: Several things need fixups to allow Java 9 builds. 1) The javadoc needs to specify the javadocVersion, otherwise it fails to discover it and uses 0, which causes the "tag" options to be ignored. 2) The file FSRBTIndex is completely commented out in v3. Javadoc complains. Move this to the unused-saved folder... 3) Some errors involving trailing and tags. > java9 javadoc requires defs for annotations > --- > > Key: UIMA-5369 > URL: https://issues.apache.org/jira/browse/UIMA-5369 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 2.10.1SDK, 3.0.0SDK-beta > > > Several things need fixups to allow Java 9 builds. > # the compiler target level needs to be set to 1.9 > # the compiler needs an additional argument to include the javax.xml.bind > module, which is otherwise no longer available. > # The javadoc needs to specify the javadocVersion, otherwise it fails to > discover it and uses 0, which causes the "tag" options to be ignored. > # The file FSRBTIndex is completely commented out in v3. Javadoc complains. > Move this to the unused-saved folder... > # Some errors involving trailing and tags. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (UIMA-5384) uv3 migration tool class path setup
[ https://issues.apache.org/jira/browse/UIMA-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5384: - Description: There are multiple issues with the migrateClasspath setup for v3 migration. There are two uses of the classpath. * One is for decompiling the v2 compiled classes, when migrating from classes - roots. * The other is for (optional) compiling of the resulting converted source. These is done for the use case where the v2 classes were in JARs or PEARs, and the result of the conversion is new versions of these JARs or PEARs with converted JCas classes. The classpath passed for migrateClasspath should be the v2 classpath needed for decompiling the v2 JCas classes. When recompiling, the classpath for v3 uimaj-core is prepended. migrateClasspath is temporarily augmented when migrating PEAR files, by prepending any PEAR classpath specs. A separate Jira improved the migrateClasspath to permit the Java style of classpath specs using a trailing wildcard (*). Changes needed: * if the migrateClasspath argument is not set: ** if migrating from classes roots, treat this as an error; migrateClasspath is required in order to properly decompile. *** Add a note that this classpath must include the classes being migrated, because they are read from that classpath. ** If migrating from sources roots, if the migrateClasspath is not set, substitute the application classpath, with a warning. * for compiling: *# do the PEAR prepending if the source came from a pear. *# prepend at the very front, the uimaj-core-v3 (or the app classpath). was: There are multiple issues with the migrateClasspath setup for v3 migration. There are two uses of the classpath. * One is for decompiling the v2 compiled classes, when migrating from classes - roots. * The other is for (optional) compiling of the resulting converted source. These is done for the use case where the v2 classes were in JARs or PEARs, and the result of the conversion is new versions of these JARs or PEARs with converted JCas classes. The classpath passed for migrateClasspath should be the v2 classpath needed for compiling the v2 JCas classes. migrateClasspath is temporarily augmented when migrating PEAR files, by prepending any PEAR classpath specs. A separate Jira improved the migrateClasspath to permit the Java style of classpath specs using a trailing wildcard (*). Changes needed: * if the migrateClasspath argument is not set: ** if migrating from classes roots, treat this as an error; migrateClasspath is required in order to properly decompile. This must include the v2 uimaj-core for proper decompiling. ** If migrating from sources roots, substitute the application classpath, with a warning. * refactor handling of migrateClasspath so that ** it is converted once to the URL[] (processing any wild card or directory expansions) ** augmentations are done using that converted form * for both decompiling and compiling: *# when within a JAR, prepend that JAR to migrateClasspath * for compiling: *# do the PEAR prepending if the source came from a pear. *# prepend at the very front, the uimaj-core-v3 (or the app classpath). *# set the sourcePath compiler arg to converted/v3 to pick up any converted source (see http://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html#BHCJJJAJ) > uv3 migration tool class path setup > --- > > Key: UIMA-5384 > URL: https://issues.apache.org/jira/browse/UIMA-5384 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Tools >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDK-beta > > > There are multiple issues with the migrateClasspath setup for v3 migration. > There are two uses of the classpath. > * One is for decompiling the v2 compiled classes, when migrating from classes > - roots. > * The other is for (optional) compiling of the resulting converted source. > These is done for the use case where the v2 classes were in JARs or PEARs, > and the result of the conversion is new versions of these JARs or PEARs with > converted JCas classes. > The classpath passed for migrateClasspath should be the v2 classpath needed > for decompiling the v2 JCas classes. When recompiling, the classpath for v3 > uimaj-core is prepended. > migrateClasspath is temporarily augmented when migrating PEAR files, by > prepending any PEAR classpath specs. > A separate Jira improved the migrateClasspath to permit the Java style of > classpath specs using a trailing wildcard (*). > Changes needed: > * if the migrateClasspath argument is not set: > ** if migrating from classes roots, treat this as an error; migrateClasspath > is required in order to properly decompile. > *** Add a note that this classpath must include the classes
[jira] [Closed] (UIMA-5260) uv3 move in svn to top level spot
[ https://issues.apache.org/jira/browse/UIMA-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5260. Resolution: Duplicate > uv3 move in svn to top level spot > - > > Key: UIMA-5260 > URL: https://issues.apache.org/jira/browse/UIMA-5260 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Reporter: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDK-beta > > > Right now, uima v3 is in svn in uima/uimaj/branches/experiment-v3-jcas. > Move to more permanent spot, probably uima/uimaj-v3/trunk would be most > conventional for Maven. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
