I've lately upgraded my Cassandra nodes from version 1.0.11 to version 2.1.8.
Version 1.0.11 uses Hector Java Driver, which isn't supported anymore, whereas for v.2.1.8, we are using Native CQL Driver.
When I've added the libraries for the new version, I've encountered a serious problem with Guava library:
Hector Driver - works with (legacy) guava-r09.jar.
Native CQL Driver - works with guava-18.0.jar.
So, I tried to remove the old Guava jar (v.09) and replace it with the new one (v.18), but it's not compliant with Hector, since Hector is pretty much deprecated for a while and is not compatible with newer versions of anything.
On the other hand, Native CQL driver won't work with Guava versions lower than v.18.
And of course, both together will crash the whole system since many functions will override each other.
Some possible solutions I've been thinking about are:
Migrating our whole project to new Driver - this is a solution but it will take ages, since we've got a lot of complex code.
Deep digging into Hector Classes and manually changing them to be compatible with v.18 - This is another solution, but it will take time and be very risky. Besides, each Guava update I'll need to do modifications which may possibly take much time.
Two parallel apps? Can't really figure this one...
Does anyone have any other easier suggestions? Like some sort of selective library version for one query and a different version for others? Maybe some sort of Docker? or perhaps a Virtual Env solution?
Thanks in advance,
Adam.
Related
I'm working on a project where I'd like to use Apache Tika and Apache Jena. However, when I try to run the project I get the following exception:
java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String; Ljava/lang/Object;Ljava/lang/Throwable;)V
My understanding is that this is because Apache Tika includes an old version of SLF4J (pre 1.6.0) and Apache Jena includes a newer version (1.6.0 or later), and that there is a breaking change between the two versions of SLF4J.
How do I get around this issue so that I can use both Tika and Jena at the same time?
Some existing posts talk about using Maven to work around this, but a) I don't use Maven and I'm not familiar enough with it to fully understand the solutions and b) I'm working on a development network that isn't connected to the internet.
slf4j is actually fairly compatible across versions for many usages. Jena does not use many features of SLF4j. It does not LocationAwareLogger as far as I'm aware. It may work with pre 1.6.X. While nothing is guaranteed (AKA you have to test it), it's worth a try.
If that fails, you'll need to rebuild one system and tweak what needs to be changed. Both systems are open source with both code and build system is available.
I wouldn't use these 2 libraries until they have the same version unless I'm absolutely have to do that.
If you think so, then a good explanation of the issue is here: java-classpath-classloading-multiple-versions-of-the-same-jar-project
The solution was to change the order of the libraries so that the library with the newer version of SLF4J (Apache Jena) was before the older version(s) on the build path.
I am trying to connect to a broker that is using FIX 5.0
I would like to leverage quickfixj for ease and speed of implementation.
Is this going to work? I am assuming 5.0 extends (so to speak) the features of prior versions, but I do not want to get too far along and wind up causing more issues than it is worth to use quickfix.
I ask this because the current website says that quickFixJ is okay for versions of fix between 4.0 and 4.4.
Will this still work with 5.0?
Many financial institutions use quickfix and it is quite likely that if QuickFix has an issue with version 5.0 the other end has the same issue as it's pretty standard. BTW You can change the implementation fairly easily, if for example you want to improve the performance. (which is ok, but not great)
quickfixj is generating its classes out of the standard fix dictionaries, so there is no limitation in terms of the framework and from my experience it is very accurate, new releases from 1.5.3 to 1.6 seems to have some issues between 4.x and 5.x compatibility but in general it is quite straight in managing a mix of versions and custom fields, it boils down to the version of reference between the counterparties which applies to every message but essentially on the message level all versions can be woven in / customised
Folks, I am in the process of releasing a plugin for Solr (under ASF license) that implement different ranking strategies. I have tested it against 3.5 version, it works great, since I started fairly recently on open sourcing it went with latest version of Solr (3.5). But then a request came in to use that plugin for version 1.4. The problem is that Solr API has undergone some significant changes between 1.4 & 3.5.
For instance, SolrQueryResponse was moved from
org.apache.solr.REQUEST.SolrQueryResponse (1.4)
to
org.apache.solr.RESPONSE.SolrQueryResponse (3.5)
I use Git for DVCS, Maven for Build/Project Management, Google Code for project hosting, what would be an ideal strategy to make changes & maintain the code for different versions of underlying Solr/Lucene API. Branch could be way to achieve it, but I am not really convinced.
Would like to know if there is a better way to develop/maintain code for different underlying API versions & distribute them ?
I know... you must be calling me nuts by now, for using text files as databases.
If thats ok to you, certainly using java 1.3 will be enough to call me insane.
Let me explain (yes there's an excuse for that):
I work for a company that for a thousand reasons can't (or won't) upgrade to java 5 or 6 and so on...
It doesn't allow us to create/modify databases on it's DB2 systems as well.
I know... It looks like they don't wanna let us do our jobs...
Well, enough said. The point is that we are using text files to feed our 300 reports.
300 and growing... And our servers are on the verge of breaking down...
I tried using SQLite, but could not find any connector/wrapper that would work with java 1.3...
And now I'm out of ideas...
If anyone has been through that road (and survived to tell), and could give me any piece of advise...actually, any idea, from anyone....
Edit: I forgot to mention that I can't install any database server. That's why I considered SQLite, 'cos it is a "serveless" database.
Java 1.3, ye gods, do you use punch cards as well? :)
On a serious note, HSQLDB claims to support every JDK, even the prehistoric 1.1 one. Maybe that will be of use to you.
There are a number of open-source embedded databases for Java that may fit your requirements:
http://java-source.net/open-source/database-engines
The big question is which (if any) of them still support Java 1.3. I suggest having a rummage around in their docs to see what you can find.
Versions of Apache Derby prior to 10.3.1.4 support JDK 1.3, see the release notes for 10.2.2.0.
It's worth noting that Derby uses the same SQL dialect as DB2 with a few differences over supported data types and functions, you can see more details at developerworks
I'm wondering what adoption rate is of the (now officially supported) ServiceLoader facility in Java 6. I'd like to begin using it as a preferred way to locate dependencies. Obviously this would be made much easier if the jars already ship with with the necessary configuration file in place.
Just poking around I was happy to see the MySQL JDBC driver has the "META-INF/services" in place (at least in v5.1 of mysql-connector-j).
I'd be interested to know what other major/widely used libraries are known to provide this this.
Hibernate, PostgreSQL JDBC to name two.