: Yes, but why ship any libraries w/ Solr then? We should write HTTPClient for : ourselves, as well as all the other dependencies. Class loader hell is at the : very heart of Java and is just something we all deal with unless we go to OSGi : (I'm told, anyway, but I don't know enough about it) or build everything : ourselves.
we do in fact depend on third party libraries for soemthings, and yes it's possible that those libraries might be version incompatible with libraries already in use by the containing app (regardless of whether it's a servlet container or something else) -- i have sweated over every one of those decisions in the past because of potential conflicts. BUT! ... There are two (really) three key differneces here... 1) we currently have no dependencies (that i know of) that are "core" dependencies -- ie: Solr won't work at all if there is a conflict. All of our external dependencies right now are things that if there is a conflict, that just means you may not be able to use an optional feature (ie: remote ContentStreams if commons-http has a conflict, the ShowFileHandler if commons-io has a conlfict, the PhoneticFilter if commons-codec has a conflict) 2) Almost all of our existing use cases of third party code are very isolated such that they are very unlikely to come into play when dealing with parent context classloaders -- in an enviornment where logging is centrally managed a "LogMessage" object is very likely to get propogated up the tree out of the Solr context to the point where class compatibility becomes an issue ... we don't exactly pass instances of HttpClient arround in ways that the ServletContainer is likely to encounter problems if they differ (multiple versions of a class can be loaded the same JVM, you just don't ever want to "cross the streams" as the ghost bsters use to say) (The third differnce I see is in the idea of adding a depndency that doesn't actually add a feature -- this is a philosophical argument, people could say that "easier third party logging abstractin is a feature", but i disagree, and am willing to ignore that issue, but i mention it for completeness since I (and Erik) have brought it up before) -Hoss
