HoustonPutman commented on code in PR #1179:
URL: https://github.com/apache/solr/pull/1179#discussion_r1022987716


##########
solr/server/contexts/solr-jetty-context.xml:
##########
@@ -5,4 +5,19 @@
   <Set name="war"><Property name="jetty.base"/>/solr-webapp/webapp</Set>
   <Set name="defaultsDescriptor"><Property 
name="jetty.base"/>/etc/webdefault.xml</Set>
   <Set name="extractWAR">false</Set>
+  <Set name="parentLoaderPriority">true</Set>
+  <Call name="addServerClassMatcher">
+    <Arg>
+      <New id="removeServerClasses" 
class="org.eclipse.jetty.webapp.ClassMatcher">

Review Comment:
   Yeah will definitely add a comment. But here's the gist:
   
   
https://www.eclipse.org/jetty/documentation/jetty-9/index.html#jetty-classloading
   
   Jetty protects access to certain "server" classes. You can see the defaults 
if you scroll down to the "Setting Server Classes" section in the documentation 
link above. (Annoyingly the same documentation doesn't exist for Jetty 10 or 
11, although the functionality is the same, other than a method signature) This 
means that the webapp cannot use these classes unless they are also provided in 
the WEB-INF/lib directory as well, meaning that we have to duplicate these jars 
using the default settings.
   
   However when we add this set of `serverClassMatchers`, which all start with 
`-`, it removes these classes from the protected "server" class definition. 
This allows us to use the same jars between the jetty server and our webapp.
   
   The documentation doesn't actually give any good reasons why these classes 
should be protected, or maybe I just missed it. So we can always go back to 
duplicating the jars, but I think this is probably a better way forward.
   
   Obviously we need some pretty extensive testing to make sure that the 
`setParentLoaderPriority​(true)` option doesn't mess with any of our class 
loader stuff. So far the integration tests, docker tests and unit tests all 
work so far. But we will definitely need to do some more.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to