[ 
https://issues.apache.org/jira/browse/SOLR-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215039#comment-17215039
 ] 

Houston Putman commented on SOLR-14915:
---------------------------------------

I think it makes sense to remain as a contrib module, so in the same repo.

I think releasing the exporter individually would be a good idea, as well as 
creating a separate docker image. I had a PR for the docker-solr repo around a 
year ago that did something similar, but didn't get merged for various reasons. 
In general there is no reason why the two need to live together, so I'm all for 
it.

 I don't think there's any harm in providing the composite binaries, in 
addition to having the individual binaries available. More choices with little 
extra work for us :) 

> Prometheus-exporter should not depend on Solr-core
> --------------------------------------------------
>
>                 Key: SOLR-14915
>                 URL: https://issues.apache.org/jira/browse/SOLR-14915
>             Project: Solr
>          Issue Type: Improvement
>          Components: contrib - prometheus-exporter
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Minor
>         Attachments: patch.patch
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> I think it's *crazy* that our Prometheus exporter depends on Solr-core -- 
> this thing is a _client_ of Solr; it does not live within Solr.  The exporter 
> ought to be fairly lean.  One consequence of this dependency is that, for 
> example, security vulnerabilities reported against Solr (e.g. Jetty) can (and 
> do, where I work) wind up being reported against this module even though 
> Prometheus isn't using Jetty.
> From my evaluation today of what's going on, it appears the crux of the 
> problem is that the prometheus exporter uses some utility mechanisms in 
> Solr-core like XmlConfig (which depends on SolrResourceLoader and the rabbit 
> hole goes deeper...) and DOMUtils (further depends on PropertiesUtil).  It 
> can easy be made to not use XmlConfig.  DOMUtils & PropertiesUtil could move 
> to SolrJ which already has lots of little dependency-free utilities needed by 
> SolrJ and Solr-core alike.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Reply via email to