It may be too late but just for the sake of argument, Hoss's idea about a
ResourceLoader triggered more thinking...(sorry, I'm not as fast as Hoss). I
also remembered that things were easier before solr-215 because the core &
config were singletons. How could we get some sort of singletons back?
Through the class loader...
The Resource{Loader,Finder} is functionally equivalent to a ClassLoader;
ideally, we'd want classes loaded through that loader to have it as the
'real' class loader (not its parent). Btw, this is a difference in behavior
between classes that exist in the solr.jar and those that a user puts in a
lib directory; those in the lib directory have the SolrConfig's
URLClassLoader as real loader, solr ones end up with its parent class
loader.
Anyway, if the ResourceLoader was also the ClassLoader, we'd have one class
loader per config (as we already do) but each loaded class would be able to
access it; we then don't have any API change, we just do a ((ResourceLoader)
getClass().getClassLoader()) when/if needed. And that loader could even know
the config, the schema & the core. Not really the singletons that existed
before but close.
I fought a little with the idea and got a prototype ClassLoader that
implements this behavior; its 'Class forName(String name)' method ensures
that the loaded class does have this class loader as real class loader (even
for solr ones).
http://www.nabble.com/file/p13879843/ConcreteLoader.java
ConcreteLoader.java
http://www.nabble.com/file/p13879843/ConcreteLoaderTest.java
ConcreteLoaderTest.java
Should I pursue or drop the idea ?
--
View this message in context:
http://www.nabble.com/Initializing---break-init%28%29-API-compatibility--tf4808463.html#a13879843
Sent from the Solr - Dev mailing list archive at Nabble.com.
