: 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).
In a lot of cases, this is generally intentional to help reduce the surface area of the API. The less you can do in a subclass, the more flexibility there is in modifying the internals of a base class, and the less likeley that changes to the base class break your subclass. IIRC the key touch point for clients ot customize HttpSolrServer is by being able to specifying an arbitrary HttpClient that the HttpSolrServer uses for all of it's communication. By specifying your own HttpClient, you can do just about anything you might want, and i'm hard pressed to think of anything we'd want to let clients do that *can't* be done by specifying an arbitrary HttpClient. : 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 pretty easy at the HttpClient level using RequestWrapper arround any GET request you are asked to execute. -Hoss
