I'm learning Camel by the book of Claus Ibsen and I would like to have your advise on this.
I have got the book and the code from the side.
In chapter1 it says run:
C:\camelinaction-master\chapter1\file-copy>mvn compile exec:java -Dexec.mainClass=camelinaction.FileCopierWithCamel
The error it produces is:
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.1.1:java (default-cli) on project chapter1-file-copy: An exception occured while executing the Java class. null: InvocationTargetException: javax/xml/bind/annotation/XmlRootElement: javax.xml.bind.annotation.XmlRootElement -> [Help 1]
I'using
java 15.01 and
mavem 3.3.5
Since I got this issue at the very beginning of the book I thought before I start debugging the issue perhaps it is good to ask if the code from the book is still working or is it to old and not maintained? If that is not the case it is worth solving the issue otherwise is there newer learning material that you have used and good experience with?
The JAXB APIs are considered to be Java EE APIs and therefore are no longer contained on the default classpath in Java SE 9. In Java 11, they are completely removed from the JDK. (Quote from Java: How to resolve java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException )
Try using Java 8.
UPDATE: As Claus (one of the authors of the book) pointed out, there are branches for Camel 3.x versions in the book source code repository:
https://github.com/camelinaction/camelinaction2/tree/camel37
3.x supports Java LTS versions: 8, 11, or 14, but does not officially support the non LTS Java versions.
As Kristof advised, short answer is use Java 8.
In addition to that, the Camel in Action book (2nd ed.) uses Camel 2.x and it supports only Java 8 so otherwise the sample code doesn't work.
If you really want to use later Java versions (11 and higher) you should use Camel 3.x (the latest version as of now is 3.7.1). Since it's a major upgrade you'd need to go through some migration work in order to make the sample code run with Camel 3.x. See the following official migration/upgrade guides for what to do:
https://camel.apache.org/manual/latest/camel-3-migration-guide.html
https://camel.apache.org/manual/latest/camel-3x-upgrade-guide.html
Thank you Claus Ibsen.
With the link to the new source files I'm able to continue my study.
https://github.com/camelinaction/camelinaction2/tree/camel37
Related
Currently Pentaho Kettle (v.9.1) officially only support Java 8. This is a problem for us, since we are maintaining a plugin that needs Java 11 because of a essential library that needs Java 11. Does anyone have details on the roadmap for the migration to Java 11. I could only find some older information that Java 11 is on the roadmap, but not when it will be available for Kettle.
Our current solution is to use Java 11. You can get Spoon running when removing the JAVA_ENDORSED_DIRS from the bat/sh file. But this is not the best solution since the application is not fully compatible and we are experiencing more and more problems.
Also alternative ideas or solutions are welcome.
As of May 20, the README.md of the Pentaho Kettle repository explicitly mentions Java 11, so it seems as if that is now officially supported.
I am migrating Java 1.8 to OpenJDK 11. Getting some dependency errors.
"sun.security.x509" is not visible.
BASE64Encoder error
How can I resolve these? I am using Apache Ant for build.
We can't tell you how to address the first problem since you haven't shown us the code where you are using classes in the sun.security.x509 package. A possible workaround might be to use --add-exports and/or --add-opens as described in this blog post:
All You Need To Know For Migrating To Java 11
However, that work-around is liable to stop working in the future. The solution would be to find a way to avoid depending on those classes.
The second problem can be used by rewriting your code to use the java.util.Base64 class (javadoc) that was introduced in Java 8.
I am using Apache Ant for build.
That is not directly relevant. The root cause of the problem is in the code you are building not the build tool you are using.
AWS allows to create Lambda function with Java 8 (OpenJDK 8) as runtime.
I need to create a simple function using Open JDK 11. Something like that:
package example;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.LambdaLogger;
public class Hello {
public String myHandler(int myCount, Context context) {
LambdaLogger logger = context.getLogger();
logger.log("received : " + myCount);
return String.valueOf(myCount);
}
}
There is an option allowing to use a custom runtime and a tutorial that contains an example with Shell. However there is no example with Java.
Is anyone have already deal with an AWS lambda with custom java runtime?
I was also curious as to why we haven't seen any custom runtimes for Java yet, so about a month ago I started playing around with the idea of building one in Java 11 using Jigsaw to produce small runtime. While it's not exactly a tutorial, I did write a fairly detailed Readme on how to build this and the code is simple enough to follow.
Here's my project on GitHub:
https://github.com/andthearchitect/aws-lambda-java-runtime
I just published this recently and it's most certainly a POC so use at your own risk.
Corretto seems interesting but I would guess there will still be people out there who are more comfortable with the official OpenJDK release. I'm hoping maybe this can be the starting point for a production ready open source runtime for Java.
There's no longer a need to use a custom runtime, as AWS Lambda now supports Java 11.
However, Lambda functions that use this runtime will be run with Amazon Corretto 11 and not OpenJDK 11.
If you wish to run your Lambda function with OpenJDK 11 instead of Corretto 11, then using a custom runtime is still recommended.
As Arun Gupta said, they are working on Corretto 11 builds corresponding to Open JDK 11 and will release with time for testing before April, 2019...
However, it is still possible to add a custom runtime, which allow to "implement an AWS Lambda runtime in any programming language".
There is no example for JDK 11 in official AWS documentation, but I found a project, which use a custom runtime of 25MB, build from JDK 11, with jlink. You can take a look at this link
I doubt you can do that yet. According to AWS:
"We are working on Corretto 11 builds corresponding to Open JDK 11 and will release with time for testing before April, 2019."
https://forums.aws.amazon.com/thread.jspa?messageID=875742&tstart=0
https://aws.amazon.com/blogs/opensource/amazon-corretto-no-cost-distribution-openjdk-long-term-support/
Can anyone help me with this error message I'm getting from IntellIJ?
(I'm using Java 8 - the error is only occurring on a very small percentage of the classes)
[2014.05.06 10:14:39] (Coverage): Error during class instrumentation: xxx.yyyy: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on interfaces require ASM 5
Thanks
Daniel
If you Google for that exception message, you will find that there are a small number of hits in a variety of code analysis tools. It seems to be a tool-chain compatibility issue. Java 8 code breaks various third party tools that use older versions of the ASM library.
You need to report this to the developer for the tool or plugin that is having problems.
I have been testing a patch from intellij which fixes the problem.
It will be released publicly in 13.1.3 EAP.
I am working on a Java-EE project involving Glassfish 3.1.2.2 and the client component is running with Java 7 Update 21. The Swing-based client was formerly based on Java 6 Update 38 until we decided to migrate to the new Java 7 Update 21.
I get the following compilation warning in Netbeans 7.3:
warning: Supported source version 'RELEASE_6' from annotation processor 'org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor' less than -source '1.7'
At this point, the compilation process hangs for about 1 minute.
Btw, we still have the javaee-api-6.0.jar referenced that is provided by the Netbeans platform (I think there's no javaee-api-7.0.jar available yet?)
Does somebody know the reason for this warning and how I can get rid of it ?
Any help highly appreciated - many thanks in advance.
It seems (I think) that the eclipseLink annotation processing for JPA is up-to-date until Java 6. You could make a Java 6 library with the JPA sources, and only there use eclipseLink annotation processing. Having a library never hurts, and later you may upgrade to Java 7 independantly.
Can't image using much Java 7 functionality in the JPA sources.
Java version 7 has more features as compared to Java 6. In netbeans, go to Tools-->Java Platforms and check whether your netbeans ponts to the latest version of JAVA.
I thing You have added unwanted library,first, you have to check your library of your project and delete the unwanted files there. On the other hand, you can retry it by copying only the JFrames and Main Classes into a new Project. But One thing, You have to replace the name of package as the new name.