I'm setting up a SOAP service using spring-boot and run it in a docker container.
When I run the jar alone everything works fine, but when I try to run it in a docker container it fail to initialize and throws this error:
Failed to instantiate [org.springframework.ws.wsdl.wsdl11.Wsdl11Definition]: Factory method 'defaultWsdl11Definition' threw exception;
nested exception is java.lang.NoClassDefFoundError: javax/wsdl/extensions/ExtensibilityElement
I already try different images, also creating a base docker image and install oracle jdk manually.
You can find the exact code here and try by yourself.
To run the app:
gradle build
java -jar build/libs/service-0.0.1-SNAPSHOT.jar
To create the docker image:
docker build -t soap:service --build-arg JAR_FILE=./build/libs/service-0.0.1-SNAPSHOT.jar .
To run the docker image:
docker run soap:service
Any help is appreciated.
If someone wants to know, the problem was that wsdl4j library was setted to be on compileOnly and by changing it to compile the library was presented on the final jar.
For more information visit https://community.liferay.com/blogs/-/blogs/gradle-compile-vs-compileonly-vs-compileinclude
Related
I am trying to build a native image of a micronaut (v1.0.4) application.
This application uses Consul as service discovery.
I've created the app using --features option:
$ mn create-app my-app --features discovery-consul --features graal-native-image --build maven
The application works perfectly on my local machine, but when I try to build a docker container with the native image I get an error:
$ ./docker-build.sh
error: No instances are allowed in the image heap for a class that is initialized or reinitialized at image runtime:
sun.security.provider.NativePRNG
Detailed message:
Error: No instances are allowed in the image heap for a class that is initialized or reinitialized at image runtime: sun.security.provider.NativePRNG
Trace: object java.security.SecureRandom
method com.sun.jndi.dns.DnsClient.query(DnsName, int, int, boolean, boolean)
Call path from entry point to com.sun.jndi.dns.DnsClient.query(DnsName, int, int, boolean, boolean):
at com.sun.jndi.dns.DnsClient.query(DnsClient.java:178)
at com.sun.jndi.dns.Resolver.query(Resolver.java:81)
at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:434)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129)
at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
at io.micronaut.discovery.client.DnsResolver.getCNamesFromTxtRecord(DnsResolver.java:59)
at io.micronaut.discovery.client.EndpointUtil.getEC2DiscoveryUrlsFromZone(EndpointUtil.java:197)
at io.micronaut.discovery.client.EndpointUtil.getServiceUrlsFromDNS(EndpointUtil.java:141)
If I remove Consul integration, it works without any problem.
I could not find anything useful on the official documentation:
Microservices as GraalVM native images
Consul Support
Does anyone know where the problem is?
After going over several issues and posts, I ended up finding the answer.
To remove this failure, just add this class com.sun.jndi.dns.DnsClient to the list of classes under the option --delay-class-initialization-to-runtime when you create the native image in you Dockerfile:
Dockerfile
RUN native-image --no-server \
...
--delay-class-initialization-to-runtime=...,com.sun.jndi.dns.DnsClient \
-H:-UseServiceLoaderFeature \
--allow-incomplete-classpath \
-H:Name=model-quotes \
-H:Class=model.quotes.Application
...
After doing that, everything works ok and the docker image is generated successfully.
It should be a good idea to add this class in Dockerfile generated by default. It is a bit annoying to generate a new project using Micronaut CLI and find that native images does not work without changing anything.
I have a issue with asciidoctor. My application is working when I am running it outside the docker container. When I am using maven build to generate the jar and run it inside the docker container, it shows :
org.jruby.exceptions.RaiseException: (LoadError) no such file to load --
asciidoctor
at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:961)
at RUBY.require(uri:classloader:/META-
INF/jruby.home/lib/ruby/stdlib/rubygems/core_ext/kernel_require.rb:55)
at RUBY.<main>(<script>:12)
asciidoctorj: 1.5.6
asciidoctor-pdf: 1.5.0-alpha.15
org.jruby:jruby-complete: 1.7.26
dockerfile: openjdk:8u111-jdk
intellij
please help if anyone knows the way to solve the issue, thx!
I use JNA to load a c++ library (.so) in a java project. I package my library inside the jar, and load it from the jar when instantiating the java class that uses it. I do all this like so:
mvn install compiles the c++ code and packages the outcome dynamic library inside the jar.
I call in a static context when instantiating the LibraryWrapperClass the following
System.load( temp.getAbsolutePath() );
where temp is a temporary file containing the library which was found in the jar. This code is based on the work found here adamheinrich
- I call Native.loadLibrary(LIBRARYPATH) to wrap the library into a java class.
private interface Wrapper extends Library {
Wrapper INSTANCE = Native.loadLibrary( C_LIBRARY_PATH, Wrapper.class );
Pointer Constructor();
...
}
I run tests and validate that the library was found and up and running.
I use a java web project that depends on this project. It uses tomcat and runs fine in local.
My issue is that when I deploy on the server, the LibraryWrapperClass cannot instantiate. Error on server is:
java.lang.NoClassDefFoundError: Could not initialize class pacakgeName.LibraryWrapperClass
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at org.hibernate.annotations.common.util.StandardClassLoaderDelegateImpl.classForName(StandardClassLoaderDelegateImpl.java:57)
at org.hibernate.boot.internal.MetadataBuilderImpl$MetadataBuildingOptionsImpl$4.classForName(MetadataBuilderImpl.java:758)
at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.classForName(JavaReflectionManager.java:144)
at...
This error seems that the library is found, since there is not the UnsatisfiedLinkError exception thrown. But something else is failing. Do someone know what could happen? How could I debug?
I recall that everything works perfectly in local.
How could I debug?
1. with strace
strace will give you what files Tomcat is trying to open : strace -f -e trace=file -o log.txt bin/startup.sh
After this, look for packageName in log.txt, or other files not found with :
egrep ' open.*No such file' log.txt
2. with JConsole
Enable JMX, launch a JConsole, go to VM summary tab, and check/compare very carefully VM arguments/classpath/library path/boot class path
3. dependency listing with ldd
If a dependency issue is likely to be the problem, the ldd sharedLibraryFile.so command lists all the dependencies and allows to track which one might be missing.
I am exploring docker to deploy my dockerized java sample project on windows7 using boot2Docker. When I am building the dockerized java app using command ./gradlew build buildDocker. I am getting an issue as follows:
Execution failed for task ':buildDocker'.
> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
My build.gradle file had docker settings as follows:
docker {
useApi true
hostUrl 'https://192.168.59.103:2376'
}
I searched for some probable solution for the same and got this link. I tried both the workarounds but none working for me. For the first approach i.e. changing profile and tried building again the project also failed with above error.
In the second workaround, I tried to install and run
$(docker run sequenceiq/socat)
the command downloaded the package and runned as well. But when I tried to check the running images using command docker ps, Nothing came in result set.
After that I tried pinging using curl http://192.168.59.103:2375/_ping returned error as curl: (7) Failed to connect to 192.168.59.103 port 2375: Connection refused
Anyway I changed my docker configuration in build.gradle file as follows:
docker {
useApi true
hostUrl 'http://192.168.59.103:2375'
}
And run the build command i.e. ./gradlew build buildDocker again to get below error:
Execution failed for task ':buildDocker'.
> org.apache.http.conn.HttpHostConnectException: Connection to http://192.168.59
.103:2375 refused.
So it seems both the workaround is not working for me. Any one faced the same and have any clue about what I am missing here.
when I run sample IBM Bluemix Liberty for Java application https://github.com/ibmjstart/bluemix-java-postgresql-uploader.git following error:
-----> Downloaded app package (1.9M)
-----> Downloaded app buildpack cache (4.0K)
OK
/var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:101:in build_pack': Unable to detect a supported application type (RuntimeError) from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:74:inblock in compile_with_timeout'
from /usr/lib/ruby/1.9.1/timeout.rb:68:in timeout' from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:73:incompile_with_timeout'
from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:54:in block in stage_application' from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:50:inchdir'
from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:50:in stage_application' from /var/vcap/packages/dea_next/buildpacks/bin/run:10:in'
FAILED
Server error, status code: 400, error code: 170001, message: Staging error: cannot get instances since staging failed
TIP: use 'cf logs jpu-henryhan --recent' for more information
The top error looks like you left off the -p <path_to_war> parameter when doing a push. If you just push a directory containing a WAR file, it will not be detected by the Java buildpack.
The tip provided in the output of your cf push request is relevant.
TIP: use 'cf logs jpu-henryhan --recent' for more information
Running that command will tail the log files produced during the staging process and let you see what error may have been raised. Often, it can be a missing dependency or a transient failure of some sort.
I just successfully deployed the sample using the "deploy to Bluemix" button and manually via the cf command line tool. Unless you changed the code, it is most likely that this error is a transient failure.
Run following command:
$ cf push jpu- -b https://github.com/cloudfoundry/java-buildpack --no-manifest --no-start -p PostgreSQLUpload.war
add the parameter to set the buildpack "-b https://github.com/cloudfoundry/java-buildpack"