David Smiley commented on SOLR-6733:

I think this comes down to the distinction of what do we want to "officially 
support", vs. allow something to be possible for those that know what they are 
doing (and forgo support).  And not producing a war does not mean we need to 
hide jetty configs; there's plenty of middle-round from early days of 'war 
only' to a total black box.  Perhaps the current jetty config in plain sight 
makes it too easy to tempt people to modify it; I dunno.  For me; I have zero 
motivation to make things _harder_ to configure, and this would be more 
annoying to users.  It would annoy me.  I've seen stackoverflow tips on, for 
example, adding CORS to Solr this way, and some additional things that I forget 
as well but have found useful.  I've modified Solr's jetty configs before, and 
it'd be nice to continue to do so with the same ease.

As a side note, I think it would be helpful to rename server/lib to 
server/jetty-lib so as it's less confusing/tempting to put libs there when 
that's almost always the wrong thing to do.  Someone recently made this mistake 
and I helped them.  I suppose we'd need an internal/jetty lib dir wether we 
have jetty config files or not, so this may not actually relate to this issue.

> Umbrella issue - Solr as a standalone application
> -------------------------------------------------
>                 Key: SOLR-6733
>                 URL: https://issues.apache.org/jira/browse/SOLR-6733
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Shawn Heisey
>            Priority: Major
> Umbrella issue.
> Solr should be a standalone application, where the main method is provided by 
> Solr source code.
> Here are the major tasks I envision, if we choose to embed Jetty:
>  * Create org.apache.solr.start.Main (and possibly other classes in the same 
> package), to be placed in solr-start.jar.  The Main class will contain the 
> main method that starts the embedded Jetty and Solr.  I do not know how to 
> adjust the build system to do this successfully.
>  * Handle central configurations in code -- TCP port, SSL, and things like 
> web.xml.
>  * For each of these steps, clean up any test fallout.
>  * Handle cloud-related configurations in code -- port, hostname, protocol, 
> etc.  Use the same information as the central configurations.
>  * Consider whether things like authentication need changes.
>  * Handle any remaining container configurations.
> I am currently imagining this work happening in a new branch and ultimately 
> being applied only to master, not the stable branch.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to