How do I eliminate concerning warnings about missing classes when using JanusGraph 1.0.0 with CQL in embedded mode #4349
Replies: 2 comments
-
Found any solution to this? |
Beta Was this translation helpful? Give feedback.
-
I will try to explain the decisions we made and why you see those warnings when updating to 1.0.0. Before the changes were merged from #3245 and ongoing related PRs, janusgraph-cql had the following dependencies:
Obviously, the reason you didn't get any warnings before upgrading is because you would get all these libraries into your classpath regardless of your JanusGraph usage. However, the problem with such structure was:
To resolve these challenges, the decision was made: making Hadoop and relative OLAP dependencies optional. As such, we created a new module called Are these warnings safe? - Yes. it doesn't influence JanusGraph OLTP functionality at all. If you really need OLAP functionality then it woult make sense to include hadoop dependencies and this will automatically solve the warnings issue. I don't recommend including these unnecessary dependencies if you don't use Hadoop in your use-case. Either ignoring these warnings or somehow silencing them would be more preferable. As for the next steps it would be nice to move all classes in this package out from |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We are using JanusGraph in embedded mode with the CQL backend. On upgrading to JanusGraph 1.0.0, we are getting some concerning warnings about missing classes when we do our first traversal. I am not sure whether I should be worried about these, or what combination of maven dependencies (and possibly exclusions?) I need to get rid of them.
I can reproduce this by doing anything which causes the class
JanusGraphTraverserUtil
to be loaded, in a maven project withorg.janusgraph:janusgraph-core
andorg.janusgraph:janusgraph-cql
as dependencies. I am providing the full text of the warnings and a minimal standalone reproduction below, but I'll summarize quickly here.We have a dependency on
janusgraph-cql
but not onjanusgraph-hadoop
. That means that we haveorg.janusgraph.hadoop.scan.CQLHadoopScanRunner
on the classpath, but notorg.janusgraph.hadoop.scan.AbstractHadoopScanRunner
whichCQLHadoopScanRunner
extends. That means that we'll never be able to load the classCQLHadoopScanRunner
. That doesn't seem to matter in itself, since (in our testing so far) we have not hit a code path which actually uses that class. However, the first time we do a traversal, the static initializer oforg.janusgraph.graphdb.util.JanusGraphTraverserUtil
uses theReflections
utility to scan every class underorg.janusgraph
, and that tries to expand the supertypes, and that logs a warningcould not get type for name org.janusgraph.hadoop.scan.AbstractHadoopScanRunner from any class loader
.We get a similar story for a few other classes (see the below). As well as several from
janusgraph-hadoop
, this includes one inorg.apache.hadoop:hadoop-mapreduce-client-core
, and one inorg.apache.tinkerpop:gremlin-server
.The upgrade instructions contain this note, which seems potentially relevant:
However, that makes no difference that I can tell. In my reproduction below, I put
in the
janusgraph-cql
dependency in mypom.xml
and nothing changed. I assume that this is because the classes likeCQLHadoopScanRunner
are injanusgraph-cql
, not incassandra-hadoop-util
.In my toy reproduction, I can make these warnings go away by adding dependencies on
janusgraph-hadoop
andgremlin-server
. In my real application, addingjanusgraph-hadoop
causes a different problem (to do with Spring initialization). I can try to debug that if adding this dependency is the correct thing to do, but I'd like confirmation that this really is the correct approach. We're not using Hadoop to the best of my knowledge, so being forced to add thejanusgraph-hadoop
dependency would feel like an odd thing to do.Alternatively, we could ignore the warnings, or we could even repackage the
janusgraph-cql
JAR to exclude the classes with missing superclasses. But I'd like confirmation that this is going to be safe — I don't know whether they'd be used on some code path that we just haven't happened to hit in our testing so far. (Repackaging the JAR would also seem like an odd thing to do.)Any advice on how to proceed would be very welcome! Thanks.
Full text of warnings:
Standalone reproduction:
In
src/main/java/com/example/Repro.java
I have:In
pom.xml
I have:And then I do
mvn clean compile exec:java -Dexec.mainClass=com.example.Repro
to get the output shown above.Beta Was this translation helpful? Give feedback.
All reactions