Sorry, I didn't mean remove the URLs with the cores on them, I meant the constructor functions. The URLs are all intercepted by SolrDispatchFilter and passed to the handlers on CoreContainer anyway, and that's fine.
So for example InfoHandler has a no-argument constructor, that sets this.cc to null. If you use this constructor, you can never get useful information out of the InfoHandler - it will always throw a SolrException. So it seems a bit pointless to have this constructor at all.
Also, some of these probably don't need to take CoreContainers at all. SystemInfoHandler just uses it to determine if it's Zk-aware or not, which it could do as easily with a boolean passed to its constructor. LoggingHandler could take a LogWatcher rather than a CoreContainer. Makes it easier to test things, for a start.
OIC, looking at it more closely, they need the no-arg constructors because they could be defined in solrconfig.xml as request handlers, and need to go through the normal construct/init/inform lifecycle. So yes, we should probably open another issue to deprecate defining the handlers that are container-wide in individual core configs.