You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fineract.apache.org by "Petri Tuomola (Jira)" <ji...@apache.org> on 2020/05/08 06:18:00 UTC

[jira] [Comment Edited] (FINERACT-938) Document (or drop) use of Xerces2

    [ https://issues.apache.org/jira/browse/FINERACT-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102291#comment-17102291 ] 

Petri Tuomola edited comment on FINERACT-938 at 5/8/20, 6:17 AM:
-----------------------------------------------------------------

JAXB was indeed part of JDK until Java 8, but now is no longer bundled - hence the need to include it as a separate dependency. Looks like at least RestAssured's xml-path needs it. 

And re Xerces / Dom4J - I had to define explicit versions for these because of two issues: 

{{'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar must specify an absolute path but is ${tools.jar} during build time}}

{{ClassDefNotFound at runtime for class DocumentLS }}

As far as I could work out, both of these issues are caused by Mockrunner's dependency on an old version of nekohtml, which in turn depends on an old version of Xerces. 

1. The old version of Xerces had some reliance on tools.jar which is no longer present in JDK11 - hence the first error

2. The default version of Xerces brought in by nekohtml included an earlier version of package org.w3c.dom.ls which has a class called DocumentLS. This class is not present in the version of the same package provided by JDK11, which resulted in a NoClassDefFound error when you ran the WAR.

Instead of including Xerces and Dom4J, a better solution might be to include a newer version of nekohtml. The newest version seems to point to a new version of Xerces by default. But I don't know the new nekohtml is then compatible with mockrunner - there is no mockrunner version that would pull in the new nekohtml by default...

 


was (Author: ptuomola):
JAXB was indeed part of JDK until Java 8, but now is no longer bundled - hence the need to include it as a separate dependency. Looks like at least RestAssured's xml-path needs it. 

And re Xerces / Dom4J - I had to define explicit versions for these because of two issues: 

{{'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar must specify an absolute path but is ${tools.jar} during build time}}

{{ClassDefNotFound at runtime for class DocumentLS }}

As far as I could work out, both of these are caused by issues are caused by Mockrunner's dependency on an old version of nekohtml, which in turn depends on an old version of Xerces. 

The old version of Xerces had some reliance on tools.jar which is no longer present in JDK11 - hence the first error

Also the default version of Xerces brought in by nekohtml included an earlier version of package org.w3c.dom.ls which has a class called DocumentLS. This class is not present in the version provided by JDK11, which resulted in a NoClassDefFound error when you ran the WAR.

Instead of including Xerces and Dom4J, a better solution might be to include a newer version of nekohtml. The newest version seems to point to a new version of Xerces by default. But I don't know the new nekohtml is then compatible with mockrunner - there is no mockrunner version that would pull in the new nekohtml by default...

 

> Document (or drop) use of Xerces2
> ---------------------------------
>
>                 Key: FINERACT-938
>                 URL: https://issues.apache.org/jira/browse/FINERACT-938
>             Project: Apache Fineract
>          Issue Type: Bug
>            Reporter: Michael Vorburger
>            Priority: Major
>             Fix For: 1.4.0
>
>
> FINERACT-846 added a new dependency to [Xerces2|https://xerces.apache.org/xerces2-j/] - but only for scope test.
> While reviewing https://github.com/apache/fineract/pull/820/, I thought that was curious (both the fact that it was required at all, and that it only for tests), but I didn't want to hold up the merge of that important PR just because of that.
> Let us use this issue to either clearly document why we need it (inline in build.gradle and dependencies.gradle) - or see if it could perhaps be removed again after all?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)