[Solr Wiki] Update of "WhyNoWar" by ShawnHeisey

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "WhyNoWar" page has been changed by ShawnHeisey:
https://wiki.apache.org/solr/WhyNoWar?action=diff&rev1=6&rev2=7

Comment:
Updated information about third-party containers.  Solr 5.3 is pre-extracted, no actual .war file.

  
  == Can I still deploy Solr 5.x in another container? ==
  
+ For the moment, yes.
+ 
+ === Solr 5.0 through 5.2.1 ===
+ 
- For the moment, yes.  There is still a solr.war file in the download, found in the server/webapps directory.  If you take that solr.war file, the logging jars in server/lib/ext, and the log4j.properties in server/resources, then you can deploy in a third-party servlet container just like you could with Solr 4.x.
+ There is still a solr.war file in the download, found in the server/webapps directory.  If you take that solr.war file, the logging jars in server/lib/ext, the log4j.properties in server/resources, and the jetty context fragment in contexts, then you can deploy in a third-party servlet container just like you could with Solr 4.x.
+ 
+ === Solr 5.3 and later ===
+ 
+ Instead of a .war file, the Solr application is pre-extracted in the solr-webapp/webapp directory.  Aside from changes in the location and the context configuration fragment, installation into another container would be similar to what you would do for previous 5.x versions that included a .war file.
+ 
+ === Information that's not version specific ===
  
  Note that if you choose to do this kind of deployment, you are on your own.  The project cannot support every container out there.  Solr already has problems deploying in some containers, even with older releases that DID have the .war file in the dist directory.  There is a guava dependency problem that prevents Solr from working in GlassFish 4.x, documented in [[https://issues.apache.org/jira/browse/SOLR-5109|SOLR-5109]].  This bug has been closed with a status of "Won't Fix" because we no longer officially support deploying in a user-provided container.