[ https://issues.apache.org/jira/browse/NIFI-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Gilman updated NIFI-1265: ------------------------------ Fix Version/s: 0.7.0 > 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 > Priority: Minor > Fix For: 0.7.0 > > > 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)