: but does not want to deal with the application itself, leaving the 'business : users' side administer it. Even if there is a dedicated Tomcat for the main : app, IT will not let the 'business users' install other applications (scope : of responsibility, code versus data, validation procedures, etc). Thus the : 'one application' constraint.
There tends to be a lot of devils in the details of policy discussions like this, but perhaps you could redefine the definition of an "application" from your ops/biz standpoint to be broader then the definition from a servlet container standpoint (ie: let the "application" be the entire Tomcat setup running several webapps) Alternately, I've heard people mention in past discussions issues regarding service provider run servlet containers with self serve WAR hot deployment and the issues involved with only being able to hange your WAR and not having any control over hte container itself and i've always wondered: how hard would be to wrap tomcat (or jetty) so that it is a war that can run inside of another servlet container ... then you can have multiple wars embeded in that war and control the tomcat configsto your hearts content -- treating the ISPs servlet container like an OS. : For the sake of argument :-), besides the SolrCore singletons which is easy : to circumvent (a map of cores & at least a pointer from the instantiated : schema to the core handling it, are there others that are hiding : (Config.config, caches...) that would preclude the multiple core track? There are lots of places in the code where class instances use static refs to find the Core/Config/IndexSchema which would have to know know about your Map and keys ... it would be a lot of non trivial changes and refactoring i believe. That said: If anyone is interested in tackling a patch to eliminate all of the static Singletons i (and many others i suspect) would be extremely gratefull .. both for how much it would improve hte reusability of Solr in embedded situatiosn like this, but also for how it would (hopefully) make hte code eaier to follow for future developers. -Hoss
