[
https://issues.apache.org/jira/browse/NIFI-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15304654#comment-15304654
]
ASF GitHub Bot commented on NIFI-1265:
--------------------------------------
GitHub user mcgilman opened a pull request:
https://github.com/apache/nifi/pull/472
NIFI-1265: Upgrading to Jetty 9.3
This PR should only be applied to master as Jetty 9.3 requires Java 8.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/mcgilman/nifi NIFI-1265-master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/472.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #472
----
commit da9f2897623e089d52831b77917ff4261e29e4f2
Author: Matt Gilman <[email protected]>
Date: 2016-05-27T18:53:12Z
NIFI-1265:
- Upgrading to Jetty 9.3.
commit 38a004ab71b8003f2e7f384968cb57a3adafad6a
Author: jpercivall <[email protected]>
Date: 2016-05-27T18:39:43Z
NIFI-1265 Fixing InvokeHttp tests.
Signed-off-by: Matt Gilman <[email protected]>
commit 037f3ad3f8aa5f2b587144b2c1d0523bd2bcf029
Author: Matt Gilman <[email protected]>
Date: 2016-05-27T19:38:23Z
NIFI-1265:
- Upgrading the jspc maven plugin.
----
> Precompiling message-page.jsp causes runtime error in CentOS 6.7 and Fedora 23
> ------------------------------------------------------------------------------
>
> Key: NIFI-1265
> URL: https://issues.apache.org/jira/browse/NIFI-1265
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core UI
> Reporter: Matt Gilman
> Assignee: Matt Gilman
> Priority: Minor
> Fix For: 1.0.0
>
> Attachments: jetty.447816.patch
>
>
> During start up it appears that when message-page.jsp is precompiled and run
> in CentOS 6.7 or Fedora 23 the following method in ServletHolder (Jetty)
> fails with:
> {noformat}
> 2015-12-07 10:01:26,557 WARN [main] org.apache.nifi.web.server.JettyServer
> Failed to start web server... shutting down.
> java.lang.IllegalArgumentException: Comparison method violates its general
> contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:866)
> ~[na:1.8.0_65]
> at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:483)
> ~[na:1.8.0_65]
> at
> java.util.ComparableTimSort.mergeForceCollapse(ComparableTimSort.java:422)
> ~[na:1.8.0_65]
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:222)
> ~[na:1.8.0_65]
> at java.util.Arrays.sort(Arrays.java:1246) ~[na:1.8.0_65]
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:865)
> ~[jetty-servlet-9.2.11.v20150529.jar:9.2.11.v20150529]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> ~[jetty-servlet-9.2.11.v20150529.jar:9.2.11.v20150529]
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> ~[jetty-webapp-9.2.11.v20150529.jar:9.2.11.v20150529]
> {noformat}
> {code}
> @Override
> public int compareTo(ServletHolder sh)
> {
> if (sh==this)
> return 0;
> if (sh._initOrder<_initOrder)
> return 1;
> if (sh._initOrder>_initOrder)
> return -1;
> int c=(_className!=null &&
> sh._className!=null)?_className.compareTo(sh._className):0;
> if (c==0)
> c=_name.compareTo(sh._name);
> return c;
> }
> {code}
> After a quick glance it may be that this method is not transitive when
> falling back to comparing by className and name. From the Java API
> {noformat}
> The implementor must also ensure that the relation is transitive:
> ((compare(x, y)>0) && (compare(y, z)>0)) implies compare(x, z)>0.
> {noformat}
> This could fail with the following scenario:
> {noformat}
> x._initOrder = -1
> x._className = null
> x._name = Login
> y._initOrder = -1
> y._className = org.apache.nifi.web.jsp.WEB_002dINF.pages.message_002dpage_jsp
> y._name = org.apache.nifi.web.jsp.WEB_002dINF.pages.message_002dpage_jsp
> z._initOrder = -1
> z._className = org.apache.nifi.web.servlet.DownloadSvg
> z._name = DownloadSvg
> {noformat}
> Unfortunately, I am unable to replicate the exception. However, my
> observation from debugging show that when JSPs are precompiled the _className
> and _name are the same (like y above). When a Servlet is referenced in the
> web.xml it's name is overridden (like z above). And when a JSP is referenced
> in the web.xml the _className is null and the _name is set to the name from
> the web.xml (like x above).
> In the scenario outlined: X < Y and Y < Z but Z < X. When running locally I
> did not see the exception mentioned above but the resulting sort order was
> not correct as it ultimately depended on which elements were compared to each
> other.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
