Would being able to manage CORS settings be part of this?  

Now that Solr is ramping up it’s default security posture, there are many 
applications that used to work that don’t.  Today, changing Solr’s CORS 
settings is very cumbersome, requiring changing an embedded web.xml.

Making it easier to set your CORS type settings would be great.

Eric

> On Mar 25, 2020, at 12:29 PM, 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 
>> <mailto: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 
>> <mailto: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
>>  
>> <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 
>>> <mailto: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 
>>> <mailto: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 
>>> <mailto:dev-unsubscr...@lucene.apache.org>
>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>>> <mailto:dev-h...@lucene.apache.org>
>>> 
>>> 
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de <https://www.thetaphi.de/>
> 

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | 
My Free/Busy <http://tinyurl.com/eric-cal>  
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
<https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
    
This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Reply via email to