Skip to content
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

Closed
dexter87 opened this issue Apr 29, 2013 · 3 comments

Comments

@dexter87
Copy link

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.

@jprante
Copy link
Contributor

jprante commented Apr 30, 2013

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.

@s1monw
Copy link
Contributor

s1monw commented Apr 30, 2013

how can you build something with ES and not have the lucene core jar?

@s1monw s1monw closed this as completed Apr 30, 2013
@ash211
Copy link

ash211 commented Apr 30, 2013

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:

  1. Are there other dependencies that need to be included besides lucene-core? The full list of dependencies in the 0.90 pom.xml?
  2. The Java API seems to be less frequently used than the REST API in all the examples. I don't think it's a problem to depend on the Java API since the REST API is built atop the Java API, but are there other gotchas we should know about?
  3. Is there a good place to add documentation on building projects using the Java API? This page is probably the best spot. Maybe these are just things I would know if I was more immersed in the pom ecosystem.

Regardless, thanks for the help @jprante and @s1monw , good to learn from the experts!

martijnvg pushed a commit to martijnvg/elasticsearch that referenced this issue Jan 31, 2018
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).
martijnvg pushed a commit that referenced this issue Feb 5, 2018
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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants