I suppose I'm not the only one having to cope with the kind of policies I was describing (& their idiosynchrasies); in some organizations, trying to get IT to modify anything related to 'deployment policy' is just (very close to) impossible... Within those, having a dedicated Tomcat to run the application is the best thing that can happen! But even in this case, some will impose only one web application deployed in it...
Anyway, I've been looking deeper in removing the various static refs & singletons. The SolrCore singleton is the easy one but the various Configs are a bit more tedious. Would you rather have: a/ 1 'config' package to gather all those configuration objects (Query/Index/Admin/Cache/etc...) b/ generalize the SolrIndexConfig kind, one SolrxxxConfig per configuration sensitive class Would it be ok to refactor the SolrConfig to aggregate those and have one instance of SolrConfig per SolrCore? I lack understanding about JMX though to see how the different SolrCore instances would be exposed as MBeans (if SolrInfoMBean end up being used this way); any hint would be appreciated. Henri Chris Hostetter wrote: > > > : 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 > > > -- View this message in context: http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html#a10020669 Sent from the Solr - User mailing list archive at Nabble.com.
