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.
Related
I'm using org.jboss.redhat-fuse/fabric8-maven-plugin in one my project but somehow the latest version is always behind.
Is there any reason why we are encouraged to use org.jboss.redhat-fuse/fabric8-maven-plugin for RH Fuse project? instead of io.fabric8/fabric8-maven-plugin
I'm the maintainer of io.fabric8/fabric8-maven-plugin.
org.jboss.redhat-fuse/fabric8-maven-plugin is Jboss's fork of upstream fabric8 maven plugin i.e io.fabric8/fabric8-maven-plugin. Jboss's fork may contain some jboss related patches as per it's requirements. I think it is used under FUSE internals like for Fuse Online. Usually it's synced with upstream plugin from time to time.
If you want to use plugin as a general purpose Kubernetes/Openshift plugin. I recommend to use upstream Fabric8 Maven Plugin. If you are working around FUSE related stuff, then maybe go with Jboss's fork since it's tried and tested. But I think upstream would also work fine.
I am developing a project, which have dependencies on 3rd party libraries, that use Google Protobuf both of 2.4.x and 2.5.x versions. Is there a way to make them live together in a single project?
Are the third-party libraries open source? If so, the best thing to do is rebuild both of them using the latest version of protobufs. Newer protobuf versions (like any good library) are backwards-compatible with code written against older versions. You will have to make sure to regenerate the code generated by protoc, if the projects' build systems don't do that automatically.
If they are not open source, and you can't get the vendors to update them, then I think the only thing you can do is load the libraries with separate ClassLoaders. That's pretty ugly, obviously.
I am developing a framework where jars can be dropped into a folder and scanned for a function that can be called later. My first implementation used naive ClassLoader method where the jars were loaded and the class instance created. This is plugin architecture.
The problem I ran into is the versioning. Let's say for example my host app is using third-party lib that depends on org.joda time version 1.6 and the plugin is dependent on version 2.1 of the same (newer ) library.
I tried to use the Java Simple Plugin Framework but it does not seem to load my plug-ins using custom class loaders (which is what i assume i will need to overcome the version conflict and have the 2.1 version actually loaded).
My next step is to try osgi.
So, the question is: is this the right approach or is there a simple way that i don't know, I am coming from .net world and don't know java too well but i remember dll hell, and this seems to be the java version of it. I am developing in Scala btw, but that should not matter to the main question.
I had a similar use-case. I wanted a simple plugin framework much like you have described, but was not ready to jump into OSGi. I went the custom classloader route, but ran into much the same problems as you have. I did try a Parent-Last Classloader, which did help with some of the jar conflicts. That might be something to look into. I looked fairly seriously into what the CI Server Jenkins had done for their plugin system - and found this article interesting.
In the end, I needed to be able to track when services are coming and going, have a service registry, etc... and realized that I was re-inventing OSGi. I switched over to pure OSGi, and even though there is a learning curve and it can be a pain sometimes, I'm glad I did.
Try ScalaScriptEngine. It allows you to dynamically load and compile classes from source files and supports quite a few advanced features.
I have a question about Apache Commons projects. We know there are many nice classes and methods are available in Apache Commons Projects. But it is related to particular Java edition, I think. If I start use Apache Commons projects now, when Java updates itself to 1.8, I have to make sure Apache Commons projects has the similar update before I update to Java version 1.8? Having some 3rdparty libs is a good thing but I always worry about the compatibility between them and the main programming language I am using.
In general Java is fully backwards compatible, so if you start using e.g. commons-io in JSE1.6 it's going to work in JSE1.8 as well. Working with Java since 1999 I've never seen any issues regarding backwards compatibility.
EDIT: As long as Oracle does not change its compatibility policy, you should not run into trouble. If you later run into trouble anyway, you still have the source to fix it on your own (but may have to give back to the community depending on the license).
The Apache Commons projects update a lot more often than the JDK does. I would strongly advise to keep you libraries current. Even if only to get the newest fixes. That will also take care of any possible problems with JDK versions (which are backwards-compatible and have changed very little over the years and could be considered rather stable).
But it is related to particular Java edition, I think.
The only case where I have ever seen this be true with Apache Commons, Jakarta Anything or Spring was when one version used new JVM and/or compiler features. For example, Spring 2.5 had several jars which were for 1.5 and newer which means that in theory they would work on Java 5 through Java 8 without any bugs caused by the platform. You just couldn't use them on a Java 3 or 4 VM.
This is pretty much the norm throughout the Java community, for SE anyway. JavaEE compatibility may break because it's a matter of library compatibility and development methodology.
I am making my first foray into scala for a production app.
The app is currently packaged as a war file.
My plan is to create a jar file of the scala compiled artifacts and add that into the lib folder for the war file.
My enhancement is a mysql-backed app exposed via Jersey & will be integrated with a 3rd party site via HttpClient invocations. I know how to do this via plain java. But when doing it in scala, there are several decision points that I am pussyfooting on.
scala 2.7.7 or 2.8 RC ?
JDBC via querulous Is this API ready for production ?
sbt vs maven. I am comfortable with maven.
Is there a scala idiomatic wrapper for HttpClient (or should I use it just like in java) ?
I'd love to hear your comments and experiences on starting out with scala.
I would use 2.8.0. There are just too many useful features in 2.8. Besides, 2.8 is closing in on a final release. If you're just starting out, why not start out with that? FWIW, I've been using 2.8.0 since Beta1, in various tools and libraries that I use daily. While there have been bugs, they haven't been enough to make me fall back to 2.7.7. YMMV, though.
This isn't going to make your decision any easier, but there are other possibilities for database access. I've been using SQueryL, for instance; I like it. ORBroker is another option.
If you're comfortable with Maven, then use it, by all means. Personally, I prefer SBT. I get the full power of a real programming language, when I need to implement special build logic. Just as useful, I don't have to deal with XML configuration files. (XML is good for data, but it's a crappy format for a human-edited configuration file.)
You might try Databinder Dispatch. See this article for a nice overview.
If you're only going to start development, Scala 2.8 GA will probably be available by the time you go production. Even if it's not, I would choose the freshest 2.8RC pack rather than sticking to 2.7.7. 2.8 not only has a number of great features, but also contains lots of 2.7.7 bugfixes.
There're not too many production-ready ORMs designed for Scala these days. I would probably choose Lift Persistence, because of the team of professionals and friendly community behind Lift Framework. But if you don't want to risk, you should consider using old good proven Java ORMs: Hibernate, JPA, iBatis (that was recently renamed to myBatis), etc.
You should give SBT a try! It's compatible with maven POMs, so migration to SBT shouldn't be too painful for you. Benefits from using SBT:
It's designed for Scala, so you will be relieved from the burden of maintaining countless number of plugins for Maven to make it work with Scala consistently
You will be able to write build scripts in Scala (it's an amazing experience compared with XMLs)
SBT has a killer feature - continuous whatever (building, testing, deploying). SBT monitors your code, detects when its changed, and triggers an action (test, re-deployment, etc.).