You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Jim Challenger (JIRA)" <de...@uima.apache.org> on 2015/04/09 20:09:12 UTC
[jira] [Created] (UIMA-4336) DUCC CLI: Different results with
different JRE
Jim Challenger created UIMA-4336:
------------------------------------
Summary: DUCC CLI: Different results with different JRE
Key: UIMA-4336
URL: https://issues.apache.org/jira/browse/UIMA-4336
Project: UIMA
Issue Type: Bug
Components: DUCC
Affects Versions: 1.1.0-Ducc
Reporter: Jim Challenger
Assignee: Jim Challenger
Fix For: 2.0.0-Ducc
So far this only affects the service API/CLI, perhaps because it is more complex than the others.
The net is the API produces ClassNotFound exceptions under Oracle 1.7 JREs and later, but work in all other (IBM and Apple-supplied JREs of all tested vintages).
Everything works under IBM JREs but the fields that are initialized by initializes in the declarations in the returned objects are initialized a bit differently; in particular, at least one string field is initialized to null despite being declared like this:
String foo = "N/A"; If the field is updated as part of executing the CLI in the SM it is returned correctly.
Only the query was working in the Oracle JREs. Other SM APIs returned ClassNotFound for the base class returned by the query that works!
An older JRE produced by Sun works the same as the IBM JRE.
I believe this is a discrepancy and possibly a bug in the Oracle JREs.
The "solution" was not to change the DUCC classloader but instead to declare the returned API objects to look fully like Java Beans with no-parameter constructors and getter/setter methods. It's unclear why this matters but any port in a storm ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)