java.lang.RuntimeException: Unable to find specification: com/concordion/Concordion.html
I'm using Concordion 2.2.0 with Junit 5 jupiter using the Junit 4 vintage engine and a TFS build agent using maven. The maven surefire picks up the Concordion java file but simply can't find the corresponding Concordion html and so the auto-tests fail.
The html specification file is in the resources directory but it doesn't matter where I put it, the surefire / concordion libraries can't find it!
The specification files need to be on the classpath in the same package as the Java class. Typically this is under the src/test/resources folder. See https://concordion.org/coding/java/markdown/#locating-the-specification for more details.
Are you able to provide a simplified test case showing the issue?
Moving the specifications to the same location as the java files (src/test/java or src/main/java) should get it working in the short term.
Related
The following command used to work flawlessly:
C:\tools\apache-cxf-3.3.1\bin\wsdl2java -client -d generated foo.wsdl
It no longer works with the latest version of JDK - 12. I have downloaded the latest version of Apache CXF, and still get the same error:
-Djava.endorsed.dirs=C:\tools\apache-cxf-3.3.1\bin\..\lib\endorsed is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Could anyone offer a tip on how to remedy this?
I got the Apache CXF 3.3.1 wsdl2java utility to work with the latest OpenJDK 11 by doing 4 things:
Pull down this jar and place it into the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.jws/jsr181-api/1.0-MR1
Pull down this jar and also place it in the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.xml.ws/jaxws-api/2.3.1
In my case, since I'm running on a Mac, I vi'd the wsdl2java script and made sure these two jars are explicitly being set on the CXF classpath, by doing the following declaration within the script right before the execution of the java command:cxf_classpath=${cxf_classpath}:../lib/jaxws-api-2.3.1.jar:../lib/jsr181-api-1.0-MR1.jar
Lastly, I removed the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' parameter from the java command at the end of the script, since newer JDKs no longer support this argument, so my command now looks like this:$JAVA_HOME/bin/java -Xmx${JAVA_MAX_MEM} -cp "${cxf_classpath}" -Djava.util.logging.config.file=$log_config org.apache.cxf.tools.wsdlto.WSDLToJava "$#"
Now, using OpenJDK11, I'm able to point to an external WSDL file and successfully generate the client code I need to consume this SOAP service with the following command:
./wsdl2java -client -d src https://somewhere.com/service\?wsdl
Whether or not this all works yet is TBD in terms of being able to call and consume the SOAP service I'm coding against, but I've at least now overcome the Java9+ support issue with this tool specific to generating client code from a WSDL.
If your needs are different, I would at least remove the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' JVM parameter and start calling the wsd2java command with the parameters you need set and just start iteratively adding back in the missing libs it starts throwing java.lang.NoClassDefFoundError errors for.
Their FAQ specifically says starting in 3.3.x, Java 9+ will be supported but something clearly dropped the ball between the no-longer-supported hardcoded JVM arguments still being passed in the utility and the missing libraries to support the newer JDKs where these legacy libs have been removed.
Hope this helps someone out there unfortunate enough to ALSO still be programming against SOAP endpoints but trying to at least keep the client-side code you're writing up to date and taking advantage of the newer features of the modern JDK.
I have been having a terrible time figuring out a method not found problem. I've found similar questions on the appengine google group but none of the answers have helped solve the problem. Running my war locally with the dev server works fine but when I deploy my app I get the error below. I've included the top of the exception, the top of the last caused by and a list of the jars in my war's lib folder.
Here is the top part of the exception. I put each agurment on it's own line to make it easier to read
java.lang.NoSuchMethodError: com.google.appengine.api.datastore.Key.<init>(
Ljava/lang/String;
Lcom/google/appengine/api/datastore/Key;
Ljava/lang/String;
Lcom/google/appengine/api/datastore/AppIdNamespace;)V
Here is the top of the last caused by.
Caused by: java.lang.NoSuchMethodError: com.google.appengine.api.datastore.Key.<init>(
Ljava/lang/String
;Lcom/google/appengine/api/datastore/Key;
Ljava/lang/String;
Lcom/google/appengine/api/datastore/AppIdNamespace;)V
at com.google.appengine.api.datastore.KeyFactory.createKey(KeyFactory.java:84)
at com.google.appengine.api.datastore.KeyFactory.createKey(KeyFactory.java:77)
at com.googlecode.objectify.Key.<init>(Key.java:97)
Here is a listing of the jars in my war's WEB-INF/lib folder.
aopalliance-1.0.jar
appengine-api-1.0-sdk-1.9.6.jar
appengine-api-labs-1.9.6.jar
appengine-jsr107cache-1.9.6.jar
asm-3.1.jar
cglib-2.2.1-v20090111.jar
client-only-0.1.jar
datanucleus-appengine-1.0.10.final.jar
datanucleus-core-1.1.5.jar
datanucleus-jpa-1.1.5.jar
geronimo-jpa_3.0_spec-1.1.1.jar
geronimo-jta_1.1_spec-1.1.1.jar
gin-1.5.0.jar
guava-15.0.jar
guava-gwt-15.0.jar
guice-3.0.jar
guice-assistedinject-3.0.jar
guice-multibindings-3.0.jar
guice-servlet-3.0.jar
gwt-servlet.jar
hibernate-validator-4.1.0.Final-sources.jar
hibernate-validator-4.1.0.Final.jar
hibernate-validator-annotation-processor-4.1.0.Final.jar
javax.inject-1.jar
jdo2-api-2.3-eb.jar
jsr107cache-1.1.jar
jsr173-1.0.jar
jsr305-1.3.9.jar
jta-1.1.jar
libservice.jar
log4j-over-slf4j-1.6.1.jar
mgwt-1.2.0-rc-opera-removed.jar
objectify-5.0.2.jar
persistence-api-1.0.jar
server-and-client-0.1.jar
server-only.jar
slf4j-api-1.7.2.jar
uadetector-core-0.9.2.jar
uadetector-resources-2013.02.jar
validation-api-1.0.0.GA-sources.jar
validation-api-1.0.0.GA.jar
This was happening because of a quirk of gradle and javac with a little help from GWT and Objectify.
Since ~version 4.1, Objectify has had a separate jar with some appengine java sources in it so that Objectify classes can be used in the browser via GWT.
By default, sources included in compile dependencies in gradle will included in the compile output of the compile task. This is because gradle does not use the sourcepath parameter to the java compiler and according to Oracle's javac documentation:
If the -sourcepath option is not specified, the user class path is
also searched for source files.
I fixed the problem by adding this to my gradle file
compileJava.options.compilerArgs += "-sourcepath"
compileJava.options.compilerArgs += ""
I'm trying to analyze a example project which was provided by the sonarQube examples. I have this C/C++ version 2.0 plugin installed on my SonarQube.
My sonar-project.properties has these contents.
sonar-project.properties
sonar.projectKey=org.codehaus.sonar:simple-c-project
sonar.projectName=Simple C project analyzed with the SonarQube Runner
sonar.projectVersion=1.0
sonar.sources=src
sonar.language=c
sonar.sourceEncoding=UTF-8
When i run the sonar-runner command for this project i get an error as given below
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
at org.sonar.runner.api.Runner.execute(Runner.java:90)
at org.sonar.runner.Main.executeTask(Main.java:70)
at org.sonar.runner.Main.execute(Main.java:59)
at org.sonar.runner.Main.main(Main.java:41)
Caused by: com.A.A.A.B.A: Missing or bad plugin license. Please check logs.
Am i missing any plugins or is the plugin installed not proper.
Thank You.
Alternatively you can use another plugin in sonar called sonar-cxx if you don't want to use the commercial plugin. Its community edition Plugin. You can find it Here- https://github.com/wenns/sonar-cxx/wiki/Installation
You can download it from here - https://github.com/wenns/sonar-cxx/releases/tag/cxx-0.9.1
The C/C++ plugin is a commercial plugin, which requires a purchased licenses. I suspect the problem is that it can't find your licenses.
According to the official instructions, you need to do this:
Log in as a System administrator, go to Settings > General Settings > Licenses, paste your license key and Save (was Settings > General Settings > C/C++ (SonarSource) prior to version 1.6).
I try to use this command to deploy my application to
appspot.google.com:
c:\a\appeng\bin\appcfg.cmd --use_java7 update c:\a\u3e
Generates the error messsage.
C:\a>c:\a\appeng\bin\appcfg.cmd --use_java7 update c:\a\u3e
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.7', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
I tried setting the path to use the Java 1.6 SDK we downloaded
but that did not help or change any thing.
The web resources talk about what version of Java is used
by the application once it appears on Google's servers; I
did not see anything about the Java version for the upload
process including developers.google.com/appengine/docs/java/gettingstarted/uploading and developers.google.com/appengine/docs/java/tools/uploadinganapp#Command_Line_Arguments as well as searching this site specifically and checking google.
Can I deploy
an application from the computer in my house without
deinstalling the Java 1.7 I use for other purposes?
Thank you for looking at this question. I resolved the problem. It was not related to Google Application Development
Server. It was a difficult-to-resolve path problem to the directory where the Java executables were kept.
Here is the problem:
I have packaged my Java application into a single jar using the Maven plugin One-Jar.
Now I want to run the application as a Unix Daemon using JSVC, i.e. Apache Commons Daemon.
I am using JSVC as follows (which works for Jars made with the Maven assembly plugin, etc):
jsvc -user $USER -home $HOME -pidfile $PID_PATH -cp $PATH_TO_ONE_JAR my.package.MyClass
The error is this:
jsvc.exec error: Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader
jsvc.exec error: Service exit with a return value of 1
Does anyone know if it is even possible to use JSVC and One-Jar together, since One-Jar uses a custom class loader? The jar runs just fine when I run java -jar my-one-jar.jar.
What can be done?
Thank you for any insight!
I had to add all jars dependencies to the classpath option from jsvc. It seems jsvc doesn't use the jars inside another jar
If you use the (poorly-documented) Maven Shade Plugin instead of One-jar (they can achieve similar results as each other), it should solve your problems. It unpacks the dependent jars and stores the class files directly in the fat Jar (rather than having jars within the jar). I have used it to create an executable jar for running under JSVC with some success.
Of course, things are seldom as simple as they sound. With the Shade plugin, you may have to do some work to relocate classes when there are conflicts in your dependency tree, or use resource transformers to handle your non-Java resource files. But hopefully not.
(Of course Mkyong.com has a guide on this)