[
https://issues.apache.org/jira/browse/UIMA-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Challenger closed UIMA-4336.
--------------------------------
Resolution: Fixed
> 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)
