I think we like to pretend that Jetty and web.xml are implementation details, but I'm not sure how good of a job we do.
Whether we need to provide backwards compatibility or not is the wrong question I think, because when we break compatibility we are telling a subset of our users that it will not be easy for them to upgrade. I don't know who out there has customizations in web.xml (maybe security filters is the most common?). I don't know what the migration path for those users would look like if they want to add stuff to an embedded jetty that we're running - do we need to provide system properties they can set? Do we need to give them a separate xml file that they can use similar syntax for? I'm definitely against changing that for 8.6, and as much as I want this change for 9.0 I really want to see an alternative that makes sense proposed before we start tearing through all of this. I'll spend a bit more time thinking about this and see if I can come up with any ideas as well. Mike On Wed, Mar 25, 2020 at 11:29 AM Jan Høydahl <jan....@cominvent.com> wrote: > I agree. I changed the SIP page and now have four bullet points defined as > in scope for the SIP: > > The most important change in this SIP will be > > - Create a solr/bootstrap module with a solr.jar to replace start.jar as > the entrypoint (java -jar solr.jar ...) > - Hide jetty even more, i.e. rename jetty.port → port , and perhaps > clean up other Sysprops as well > - Get rid of web.xml and instead build our contexts and paths from > Java code, driven by Solr config > - Be able to lock Solr's memory to prevent swapping (SOLR-14335) > > > Not sure how big of a job the web.xml thing is, but there is definitely a > potential of unifying test and production code in this area and thus get > much better test coverage of some of this. > > However, removing web.xml is perhaps such a big change that we’ll have to > target 9.0 while my initial goal of just creating a bootstrapper to lock > memory could have been merged to 8.x as well?? Or do we consider web.xml an > implementation detail for which we don’t need to provide backward > compatibility? > > I’m a bit back and forth with myself on this. Perhaps if we reduce scope > to just the bootstrap module, mem locking and some sysprop renames, it can > be done quickly and end up in 8.6 already, then increment from there? > > Jan > > 25. mar. 2020 kl. 16:13 skrev Mike Drob <md...@apache.org>: > > I'm in favor of this approach mainly because of the line mentioned in the > Test Plan: > > > If we move servlet initialization into Java code and get rid of web.xml, > we may be able to start Solr in the same way both in tests and in real life! > > I feel that this should be a top level goal, along with taking another > look at EmbeddedSolrServer (perhaps it moves out of SolrJ?). Right now, I > feel like we effectively have no testing of the configurations that go into > the various xml files - can't speak for others, but it made me reluctant to > make changes to them. > > > Mike > > On Tue, Mar 24, 2020 at 6:36 PM Jan Høydahl <jan....@cominvent.com> wrote: > >> This SIP has changed name to SIP-6 and I have changed the email subject >> of this thread, please keep this new subject going forward. >> New SIP link: >> https://cwiki.apache.org/confluence/display/SOLR/SIP-6+Solr+should+own+the+bootstrap+process >> >> Jan >> >> 24. mar. 2020 kl. 22:48 skrev Uwe Schindler <u...@thetaphi.de>: >> >> Of course it's a single jvm. It's only a replacement for start.jar. the >> mock-up is already there. >> >> Uwe >> >> Am March 24, 2020 9:45:33 PM UTC schrieb Bram Van Dam < >> bram.van...@intix.eu>: >>> >>> On 24/03/2020 16:01, Jan Høydahl wrote: >>> >>>> It has been proposed many times to make Solr a truly standalone app and >>>> that we should start Jetty from within Solr and not the other way around :) >>>> >>> >>> Do you see this running in a single JVM, i.e. you run solr.jar and it >>> then starts an embedded Jetty server? Or would solr.jar exec a new Java >>> process and take it from there? >>> >>> If it's all in one JVM, then the startup scripts probably won't be all >>> that different. Memory settings, OOM killers etc will still have to be >>> set up before using startup shellscripts and whatnot. If it's just a >>> small bootstrap jar which execs another JVM, a lot of the complicated >>> shell foo could probably be simplified. >>> >>> - Bram >>> ------------------------------ >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> <dev-unsubscr...@lucene.apache.org> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> <dev-h...@lucene.apache.org> >>> >>> >> -- >> Uwe Schindler >> Achterdiek 19, 28357 Bremen >> https://www.thetaphi.de >> >> >> >
