In our project, we have many libraries that don't conflict in Eclipse, don't conflict in standalone apps, and don't conflict in a JBoss environment... but Elasticsearch's JarHell checking says there is a conflict and refuses to run.
Since I'm a user of Elasticsearch, and since I think I should be able to decide exactly how fastidious I want my classpath to be checked - why not provide a system property to skip that extra checking? All other components I'm using use the first-found class in the classpath, but Elasticsearch does all this extra checking that keeps my app from running in almost any environment.
PLEASE provide this as an option - engineers should be able to choose this if they wish!
Can you post what jars are affected?
Do you include jars of different versions?
Are you sure you have identical classes in the jars?
Have you identified a packaging problem of your software, or does it involve JBoss jars too?
How do you deploy ES in JBoss environment?
Note, Eclipse/JBoss are pretty lazy, they do not check for jar version conflicts at all.
Since JarHell quits checking on the first conflict, a complete list would take a long time to generate (I'd have to remove one jar at a time and record each conflict). I have already modified a copy of JarHell.java to ignore conflicts, and that seems to have solved my problem. But I can reenable it, but make it not stop on the first conflict, so that I can generate all possible conflicts. I do know that there are many, because at first I started removing one jar at a time to see how many there were in conflict, but stopped when the number got quite large.
We have a few jars of different versions, and MANY jars of the same version that appear in at least 2 places in the classpath. Didn't notice any packaging problem; we've been developing under Eclipse, but building the project with Ant (not Maven).
ES is deployed as a client in our main app, and a separate ES server is run on another machine. I doubt we'll have any problems with ES 2.2.0 running as a standalone server, but it's when the client JVM is also running an embedded ES server (local node) that this occurs.
I suggest to improve your packaging, to avoid dependency troubles.
Ant is not resolving dependencies, that is, you have to set up a very sophisticated process of resolving by yourself - most people have switched to Maven, because it automatically resolves dependencies to the version you declared.
One point where ES leaves us alone is the appearance of identical classes. This is perfectly valid from Java specification point of view, but ES does not agree and blocks it.
Lastly, the most important point: I learned the hard way that ES core team wants to lock out the community of using and deploying embedding client nodes. That means, NodeClient is discouraged. The NodeBuilder class was rendered useless, it does no longer pick up plugins. The alternative is to switch to TransportClient. Even TransportClient is maybe supposed to be dropped in the long run, when a HTTP client is ready.
So it all makes some more sense if you imagine that this ominous "jar hell check" is targeted to the private startup routine of ES cluster node only. Not for remote clients, not for community apps.
Thanks for your suggestions, jprante! Yes, it would be better if we used Maven or other more sophisticated build process; I've certainly advocated for that for several years, but our team is more focused on feature sets demanded by management and customers than it is fixing development infrastructure. Progress has been slow and frustrating in that regard.
Interesting about the ES team wanting to stop people embedding client nodes. Any idea what the motivation for that would be? Is that because they want to reserve that for their own development, or just that it is prone to problems they'd rather not have to deal with or provide support for?
Think about how much time you have spent with this JarHell problem. How
long would it take to transition to Maven? All of a sudden, the benefit of
transitioning can be quantified. That is how I would sell it to management.
The tools exist because there is a need. Management at my previous employer
did not understand why I was making a fuss about moving forward with new
tools and concepts, so I upgraded things without them knowing. Ant to
Maven was one of them. Nowadays, I would use gradle (although some might
not agree with me).
The motivation is due to increase security measures. Elasticsearch can only
guarantee security is met if everything is launched within their container.
Once the startup process escapes their codebase, there are no more
guarantees. I have done some projects with embedded nodes and it is sad
that it is going away.
Most of the answer can be found in the history of ES. kimchy (Shay Banon) had collected all Java sources into one giant project, producing one artifact. Note that still with ES 2.x, the codebase for server and client is the same.
I always found that design gives hard challenges. Server demands delicate pieces of protection and the history of ES is full of setbacks - see scripting, open TCP/IP ports by default, and such.
Client code was never involved in that kind of setbacks. Running client code is simpler and less risky than a server, and the ES clients are friendly to developers (embeddable, extensible). ES intermingled both and that created conflicts to achieve the goals.
When ES turned into a product, the company was faced with severe security challenges and the pressure got suddenly high to deliver more robust code while still being compatible to existing applications.
I hope for the future there will still be an embeddable, extensible, self-contained client codebase, with an own development drive, separated from server side requirements. The current situation looks very transitional.
Ivan - yes, it'd be nice to be able to go to Maven or something better than we've got. Believe me, I have pushed for it and made many convincing arguments. But management are so afraid of losing ANY time at all such that some time might be lost in bug fixing and feature implementation, that they won't allocate the time for it.
We're still using CVS, for example, and this project is 5 years old. And we only recently went to building from Ant; before that, the deployment folks would build in their own copy of eclipse and hand-package up the WARs.
So you can see... we're in no way even in the 21st century in some regards. :-/
Most of the answer can be found in the history of ES. kimchy (Shay Banon) had collected all Java sources into one giant project, producing one artifact. Note that still with ES 2.x, the codebase for server and client is the same.
.....[/quote]
Thanks for the good explanation, jprante! I do hope they keep the embedding feature around, it's very useful in development. We don't use it in any situations off our development machines, and since I can always switch to running a server on my own machine, that's fine; for now, though, I've modified JarHell.java to ignore such errors, and that ignoring can be turned on and off via an app config property.
Tim,
Even by removing the jar hell check which throws an exception and terminates the program, were you able to bring you server (embedded Elastic) up? I too have same situation as yours (ant project etc.) and faced with same problem. I also modified the JarHell.java to let the classes load even if there are dupes, but I'm getting another set of exceptions (IncompatibleClassChangeError) where JVM is confusing same name (not identical) classes. Did you have this problem?
-Vikas
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
Ant to