First - I completely agree with keeping the moving parts to a minimum - but I do think that's a case by case decision, and in this particular case - it may just be worth opening up a little. Then - adding in a custom HttpClient may work - but HttpHeaders are set on a request (and may differ from one request to the other) - so doing it in a custom http client may be technically doable, but it's probably going to be (and look like - from the API POV) a workaround. As a quick example - I'm using a custom header to activate some functionality in SORL, and another - to activate another type of functionality. Ideally, I think the API should be: solrServer.request(request, headers); // where headers is = final Map<String, String> headers Or if that's to specific: solrServer.request(request, new HttpGet(...)); Now - I can definitely see how that may or may not be OK with the direction of the API - which is why I was just thinking of extending the HttpSolrServer and adding that method for my own version. And that is where I ran into the problems with extensibility. I think that - without going into adding overloading methods - a quick change would be to carefully open some of the internal details up so that they can be used by an extending class - either by making them protected, or by adding in getters. Since setters do exist - I also think getters won't add to much conceptual load or moving parts to the logic. Cheers, Eugen.
On Thu, Nov 21, 2013 at 12:49 AM, Shawn Heisey <s...@elyograg.org> wrote: > On 11/20/2013 3:28 PM, Eugen Paraschiv wrote: > >> The reason I needed access to internal details of the class - and it's not >> just these 2 fields (I used these just as a quick example) - was that I >> was >> trying to extend the class and overload the request method. As soon as I >> tried to do that, I noticed that I really couldn't easily do so - because >> much of the fields has no getters and were not protected either (as you >> pointed out). >> So - it's not specifically about this to particular fields - it's more >> about the overall extensibility of the class. >> The class is very closed off in terms of the API - so it stands to reason >> that it may be extended for some specific usecases (for example I am >> trying >> to allow setting custom HTTP Headers on the GET request before sending it) >> - this is mainly why I was asking if it would make sense to try to open it >> up a little and make it more extensible. >> > > That makes perfect sense. As Mark suggested, please file an issue in > Jira. We can then figure out on the back end exactly what to do. > > What kind of HTTP headers are you wanting to send? SolrJ should already > send all the headers that Solr requires. If there's a compelling general > use-case, we might want a Jira issue that makes it possible to define > custom headers for all SolrServer implementations. > > Thanks, > Shawn > >
