rzo1 commented on PR #1833: URL: https://github.com/apache/stormcrawler/pull/1833#issuecomment-4150792769
> I resolved it by pinning specific versions (12.1.6) in the Solr archetype POM, but I'm not sure whether this is a good idea or there are better ways around this. @rzo1 ? Thanks for tracking this down and documenting all the steps. Pinning Jetty to `12.1.6` in the Solr archetype POM works for now, but it tightly couples us to whichever Jetty version Storm happens to ship, so the next Storm upgrade could silently break things again. The more robust fix (imho) would be to shade the Solr client with its own relocated Jetty (e.g. under `org.apache.stormcrawler.solr.shaded.jetty`) using the Maven Shade plugin. That way Storm's Jetty and Solr's Jetty coexist on the classpath without interfering with each other, regardless of what either project ships. The downside is that shading is known to confuse CVE scanners, which won't be able to match the relocated classes against vulnerability databases, so any Jetty CVEs would need to be tracked manually. If we keep the pinning approach, it would be worth adding a comment in the POM to make the coupling explicit: otherwise it's easy to miss during a future Storm upgrade. The StringUtils stuff is fixed in #1847 . -- 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]
