I think Scott's proposal is the right thing to do because most data stores' configuration are not portable among all of them, and even if we don't want to duplicate libraries, there might be different open source projects which different needs ): So what would you say the impact be for this architectural change?
Renato M. 2013/6/30 Scott Stults <[email protected]> > AFAIK, the only way to resolve #3 is to have separate class loaders and > libs for the two storage engines. That would be the only way to get a > single app to talk to both HBase and Solr using two different versions of > the Zk libs. > > Seems like a pretty radical change to the architecture, so it'd be awesome > if someone came up with a better idea! > > > -Scott > > > On Jun 30, 2013, at 4:12 PM, Lewis John Mcgibbney < > [email protected]> wrote: > > > Hi All, > > There are three issues with the patch which have been flagged up since > > commuting. > > > > 1. a 'solr' directory containing test output was generated and not > cleanup > > during and after unit tests respectively... this is trivial and now > > resolved. > > 2. The new code to parent pom.xml upgraded guava from 10.0.1 to 14.0.1. > > This is now addressed and is actually what Renato and me discovered when > > trying to progress with the pluggable Cassandra clients (Hector & > Astyanax) > > as they relied upon different but newer version of Guava than we > supported. > > This is also now fixed. > > 3. Now for the awkward one. It is well known that we need to upgrade the > > HBase stuff. This has again been brought to the light as the solr module > > supports Zookeeper 3.4.5 and HBase 0.90.4 relies upon 3.3.2. The builds > are > > throwing Exceptions like java.lang.NoClassDefFoundError: > > org/apache/zookeeper/server/NIOServerCnxn$Factory, which obviously relate > > to Zookeeper stuff. > > > > Any ideas about getting this working in harmony? > > I'll look in to it today and update the thread if I find anything. > > Thanks > > > > -- > > *Lewis* > >
