Community
Participate
Working Groups
Created attachment 241551 [details] Jetty 8.1.14 XML config I have 3 servlets, one instance of one class, two instances of a second class, with init order 0, 1 and 2. This order is not followed by Jetty. It looks like ServletHolder equals() and hashCode() are not in synch. hashCode does not account for the init order. Log output: Line 1519: 2014-04-02 17:40:13,012 [main] DEBUG: XML com.seagullsw.appinterface.server.comm.http.CoreHttpServlet-7cbada.setInitOrder(1) Line 1532: 2014-04-02 17:40:13,012 [main] DEBUG: XML com.seagullsw.appinterface.server.comm.http.CoreHttpServlet-e556ce.setInitOrder(0) Line 1545: 2014-04-02 17:40:13,028 [main] DEBUG: XML com.seagullsw.appinterface.server.comm.soap.SoapServletCxf-a5f4ff.setInitOrder(2) Line 1603: 2014-04-02 17:40:13,106 [main] DEBUG: starting com.seagullsw.appinterface.server.comm.http.CoreHttpServlet-7cbada Line 1622: 2014-04-02 17:40:13,121 [main] DEBUG: starting com.seagullsw.appinterface.server.comm.http.CoreHttpServlet-e556ce Line 1641: 2014-04-02 17:40:13,121 [main] DEBUG: starting com.seagullsw.appinterface.server.comm.soap.SoapServletCxf-a5f4ff Jetty.xml attached. The order appears to be the same as order in jetty.xml. The Jetty source code for 8.1.14 and 9.1.14 both ignore _initOrder for hashCode() if that matters.
Hi Gary, This was fixed in jetty-9.1.1 with this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=424398 Note that the equals() and hash() methods did not change in that fix. If you can show that the current implementations have a problem, I think its probably best if you open a new issue and attach a description of the problem and a small test rig to reproduce it. Note: although equals() and hash() do not use the same set of fields, equals() is well behaved according to the api contract expressed in the javadoc (and is "optimized" for sorting to satisfy the init-order), and hash() also satisfies the criteria of consistency set out in the javadoc. cheers Jan *** This bug has been marked as a duplicate of bug 424398 ***
Thank you for the reply Jan and for the pointer to a solution. Sadly for me, saying it is fixed in an incompatible version of the product does not help me deliver a quick fix. When I try to start my app with Jetty 9.1.13, Jetty complains about my jetty.xml file. We have tool suite that writes out jetty.xml so it is not just a matter for me of dropping in Jetty 9 instead of 8. Is there a plan to deliver this fix in the 8.1.x branch? Thank you, Gary
Hi Gary, No, there's no plan to backport that particular fix into jetty-8. Now that 9 is stable, all development effort is concentrated on the 9 series. Mostly just security fixes will go back into 7 and 8, with maybe some other fixes that someone has time to do. 7 and 8 will only be released infrequently - definitely for security fixes, and otherwise whenever there's enough backpressure of unreleased changes. Note that it is not always simple to backport changes to pre-9 code, as the codebase has moved on significantly. Your options would be to: + open a bug report and ask for that fix to be backported - but to be honest with limited resources we wouldn't be able to guarantee to give this a high priority. + open a bug report and attach a patch that you've tested - this is likely to get applied quickly, but again a release would not necessarily be able to be done in your timeframe. + contact info@webtide.com for some commercial support that would meet your timeframes cheers, Jan (In reply to Gary D. Gregory from comment #2) > Thank you for the reply Jan and for the pointer to a solution. > > Sadly for me, saying it is fixed in an incompatible version of the product > does not help me deliver a quick fix. When I try to start my app with Jetty > 9.1.13, Jetty complains about my jetty.xml file. We have tool suite that > writes out jetty.xml so it is not just a matter for me of dropping in Jetty > 9 instead of 8. > > Is there a plan to deliver this fix in the 8.1.x branch? > > Thank you, > Gary
