I use GWT 2.9 and JUnit 4, but i'm looking into going up to 5 using the junit-vintage-engine.
However, gwt 2.9 has a requirement on ASM 7 but with Junit 4 this is not an issue. So i tried changing my jUnit dependency to
<groupId>org.junit.vintage</groupId
<artifactId>junit-vintage-engine</artifactId>
<version>5.7.1</version>
Now, after trying to start Jetty in Intellij i get:
Java.lang.RuntimeException: Error scanning entry module-info.class from jar file:junit-vintage-engine-5.7.1.jar
Caused by: java.lang.UnsupportedOperationException: This feature requires ASM6
I can't see where junit vintage has a dependency on ASM6, so i'm not sure what's wrong. Is there a way for me to sort this out? Pointers appreciated.
Disclaimer: I have never used Jetty or GWT before, just looked around a bit because I was curious about your question.
GWT-Dev 2.9.0 has a Jetty 9.2.14 dependency.
According to this source, upgrading to Jetty 9.4.8+ seems to help with JDK 9+ problems when trying to scan module-info classes in multi-release JARs for annotations:
When looking at the parent POM, ...
<properties>
<jetty.version>9.2.14.v20151106</jetty.version>
<asm.version>7.1</asm.version>
</properties>
... maybe it would be enough to just override the jetty.version property in your POM. If that is not enough, you might still try to dependency-manage the Jetty artifacts to 9.4.40.v20210413, 10.0.2, 11.0.2 or whatever seems appropriate to you and is API-compatible with GWT.
Related
We have a Java EE 7 application running on a WildFly 9, consisting of an exploded EAR deployment, which contains several WAR files, some JARs at EAR level and a lib folder containing 3rd pary JARs. (I know this is not how one would do it today, but it is like it is.)
One of the WARs contains a JAX-RS REST service, which GETs and POSTs a data object which contains a Java 8 OffsetDateTime. Since JSON-B is not yet available, we used #JsonSerialize/#JsonDeserialize form jackson-databind in order to marshall it from and to JSON.
This worked quite well until due to a change of another WAR, the dependency jackson-jaxrs came into the lib folder at EAR level. What happened then was that the marshalling stopped working, since the container tried to set the date string from JSON directly into the OffsetDateTime type and when getting it, writing all the internal fields of the Java 8 date instead of the formatted string.
I assumed, that the processing of the above-mentioned annotations didn't take place and thus the server tried to map it like other simple types. When I deleted the JARs belonging to the jackson-jaxrs dependeny, everything worked fine again. The application server then probably used its own version of this very JAR from its modules folder.
So, my question is: What is the difference when having the jackson-jaxrs JAR in EARs lib folder additionally to the system provided module or only the latter? Why does it not consider the annontaions in the first case when de/serializing?
Wildfly 9 bundles jackson 1.9 as a base module and the annotations are in the org.codehaus.jackson package.
I suspect that the library added recently is the (more recent) jackson 2.x and the annotations are now in the com.fasterxml.jackson package.
If that's the case, upgrading to jackson 2.x (ideally the same version as the one your get from the EAR) should solve the problem.
Alternatively isolating your subdeployment from the jackson jar present in the EAR might work but it can be messy with transitive dependencies. See class loading in Wildfly
EDIT as you confirmed, there are two different versions running. If you can afford it, aligning the versions would most definitively help solving the problem.
Short of that, you might need to isolate each subdeployment's so it only sees the expected version. See this answer for example (which isolate the entire deployment from the base module).
The old monolithic clojure.contrib was available as a .jar from the same place you got the clojure .jar, and you used it by pointing your classpath at it. As far as I can tell, the new modular contribs aren't available in the clojure .jar -- instead, they exist as source files on github. What's the expected way for you to use them? Say, e.g., I wanted to use something in clojure.math.numeric-tower. What would I do?
I've found How do I install Clojure 1.3 with contribs on RHEL 6.1 / JDK7?, but the only answer ("use leiningen") isn't detailed enough for me to figure out. (Searching clojars for numeric-tower yields... nothing.)
You install a contrib module by adding its info to :dependencies in your project.clj file. The next time you run lein for something, it notices your change and automatically grabs the library for you.
I have some more detailed instructions written up here.
As stated in Maven Settings and Repositories the repository where all clojure artifacts are deployed is Sonatype OSS Nexus. If you don't want to go the leiningen or maven way, which I would still advise you to consider also for one-off experiments, you can still download manually all the artifacts from that repository. Specifically, here's all the uploaded versions of clojure.math.numeric-tower.
I can understand the reluctance to using leiningen though it took me longer to write this sentence than to create a new project.
my usual first stop for this sort of question is http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go
then clicking latest release and get the artifact I'd and version, then add a line to the project.clj's dependencies section like so
[math.numeric-tower "0.0.1"]
If you use Clojure, you should really also be using either Leiningen or Maven to manage your dependencies. I believe these are the only sane ways to stay on yop of a complex dependency graph as your project gets larger and has more complex build requirements.
For example, I use Maven and have the following in my project's pom.xml to include the numeric dependencies:
<dependency>
<groupId>org.clojure</groupId>
<artifactId>math.numeric-tower</artifactId>
<version>0.0.1</version>
</dependency>
All the modular Clojure contrib libraries can be included in the same way.
I've been using c3p0 with hibernate for a couple of years. When looking at exception stack traces, I see classes such as com.mchange.v2.c3p0.impl.NewProxyPreparedStatement in the stack. I went looking for the source code for these classes and came across the curous com.mchange.v2.c3p0.codegen package.
In particular, it looks like JdbcProxyGenerator is metaprogramming in Java. I'm having a hard time understanding the codegen mechanism and why it is used. The built jar contains these generated classes, so I'm assuming these classes are built during the build, perhaps as part of a two-phase build. The codegen package does not appear to be in the generated jar.
Any insight would be appreciated, just for my own curiosity. Thanks!
yes, you are absolutely right.
c3p0 uses code generation to generate non reflective proxy implementations of large JDBC interfaces, "java bean" classes with lots of properties, and some classes containing debug and logging flags (to set up conditional compilation within the build).
You can always see the generated classes by typing ant codegen in the source distribution, and then looking at the build/codebase directory. The latest binary distribution of c3p0 (0.9.2-pre2) includes the generated sources in a src.jar file, which you can also find as a maven artifact at http://repo1.maven.org/maven2/com/mchange/c3p0/0.9.2-pre2-RELEASE/c3p0-0.9.2-pre2-RELEASE-sources.jar
I hope this helps!
i'm trying to install and execute the cassandra API : hector.
During the launch of the process, 1 exception is throw and this trace appear :
Exception in thread "main" java.lang.NoSuchMethodError: org.apache.cassandra.thrift.Column.(Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;J)V
at me.prettyprint.cassandra.model.HColumnImpl.toThrift(HColumnImpl.java:112)
at me.prettyprint.cassandra.model.MutatorImpl.addInsertion(MutatorImpl.java:98)
at me.prettyprint.cassandra.model.MutatorImpl.insert(MutatorImpl.java:54)
at com.featherlite.example.dao.ObjectDAO.insert(ObjectDAO.java:87)
at com.featherlite.example.ClientExample.testWR(ClientExample.java:148)
at com.featherlite.example.ClientExample.main(ClientExample.java:225)
I just launch an project from the example. I didnt write this i just try.
I already saw it happens when i load 2 different or an old thrift jar library.
In my project, there are 2 thrifts jar files :
libthrift-0.7.0.jar
apache-cassandra-thrift-1.1.0.jar
The first is the jar concerning with this exception because when i delete him, i have more erors.
Apache Cassandra : 1.1.0
Sorry for my bad english :/
kinds regards,
The apache-cassandra-thrift-1.1.0.jar contains Cassandra's Thrift-related classes, while the libthrift-0.7.0.jar is the underlying Thrift protocol implementation. Sounds like you may have an old jar being referenced in your classpath, perhaps being loaded with higher precedence?
After installing jdk 7 and switching java platform for my project in ide i get this when im trying to build project.
warning: [options] bootstrap class path not set in conjunction with -source 1.6
An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.NoSuchMethodError: com.sun.tools.javac.util.Name$Table.instance(Lcom/sun/tools/javac/util/Context;)Lcom/sun/tools/javac/util/Name$Table;
at uk.org.retep.util.javac.JavacUtils.<init>(JavacUtils.java:128)
at uk.org.retep.util.annotation.AnnotationScannerProcessor.process(AnnotationScannerProcessor.java:76)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:722)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1700(JavacProcessingEnvironment.java:97)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1029)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1163)
at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1106)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824)
at com.sun.tools.javac.main.Main.compile(Main.java:419)
at com.sun.tools.javac.main.Main.compile(Main.java:333)
at com.sun.tools.javac.main.Main.compile(Main.java:324)
at com.sun.tools.javac.Main.compile(Main.java:76)
at com.sun.tools.javac.Main.main(Main.java:61)
I know that sun switched some apis or something, but ide doesnt tell me whats wrong exactly. Thanks in advance.
You should really share your code that's causing the exception, but the exception indicates that you're using an internal Java API (any class contained in the com.sun packages). You shouldn't be using those APIs directly, as they're considered private implementations and subject to change. As those APIs are private, it isn't as simple as looking for the Javadoc to see what methods are available, but suffice it to say that the method you're calling doesn't exist. You have a few options:
If you're calling this method directly, you need to refactor. You should look for ways to accomplish the same work using public APIs.
If this happens after calling a library method, you should file a bug with the library maintainer informing them about the error and the risks of using the com.sun APIs.
If this happens after calling a public Java API (anything in the java or javax packages) then You should file a bug report with Oracle. This one seems unlikely though.
Also, if you share your code, we may be able to better help you.
[edit]
Further, see this page for more information about why you shouldn't use classes in the com.sun packages.