-
Notifications
You must be signed in to change notification settings - Fork 24.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.90.0 Java API Compilation Error: "org.apache.lucene.util.ByteRef cannot be resolved" #2950
Comments
The class org.apache.lucene.util.ByteRef was patched by ES before 0.90 and that version was included in the ES jar but this is no longer the case in 0.90 Note, ES did never include the Lucene jars by intention. You have to add this dependency separately. I agree this is confusing developers (there are more confusing things when it comes to shading dependencies into the ES jar and to the optional jars). I assume this is just because ES deployments can be upgraded to a fix version of Lucene without the release of a new ES version. Of course, you can build your own version of ES, adding Lucene into the shaded jar. |
how can you build something with ES and not have the lucene core jar? |
This is a little confusing because the elasticsearch 0.20 used to be all we needed to use ES in a Java application, but now in 0.90 there are other dependencies that must be included. I guess we never realized that there were other dependencies, since the ES jar seemed to be intended as a standalone mega-jar. A couple questions then:
Regardless, thanks for the help @jprante and @s1monw , good to learn from the experts! |
This change removes the InternalClient and the InternalSecurityClient. These are replaced with usage of the ThreadContext and a transient value, `action.origin`, to indicate which component the request came from. The security code has been updated to look for this value and ensure the request is executed as the proper user. This work comes from elastic#2808 where @s1monw suggested that we do this. While working on this, I came across index template registries and rather than updating them to use the new method, I replaced the ML one with the template upgrade framework so that we could remove this template registry. The watcher template registry is still needed as the template must be updated for rolling upgrades to work (see elastic#2950).
This change removes the InternalClient and the InternalSecurityClient. These are replaced with usage of the ThreadContext and a transient value, `action.origin`, to indicate which component the request came from. The security code has been updated to look for this value and ensure the request is executed as the proper user. This work comes from #2808 where @s1monw suggested that we do this. While working on this, I came across index template registries and rather than updating them to use the new method, I replaced the ML one with the template upgrade framework so that we could remove this template registry. The watcher template registry is still needed as the template must be updated for rolling upgrades to work (see #2950).
I originally posted about the issue here: https://groups.google.com/forum/?fromgroups=#!topic/elasticsearch/dljiLl-cDFw
I think ES 0.90.* is not getting JAR'd correctly. The google thread has a self-contained test that I created to reproduce the error.
I have a patch for it which I can submit if need be.
The text was updated successfully, but these errors were encountered: