I use Camel 2.22.1 with springboot 2.0.4.RELEASE. The camel component camel-saxon use default Saxon-HE. I have some Xquery files, which call Java method, so I want to replace Saxon-HE with Saxon-PE. I requested one test license for Saxon-PE and tried different ways and didn't get it work. The Saxon-PE jar file saxon9pe.jar is already loaded, however, it is still working as Saxon HE edition. I guess, the license is not correctly loaded by Saxon-PE.
I tried following ways, none of them has worked.
put license file saxon-license.lic and saxon9pe.jar in the same folder
define an environment variable SAXON_HOME, and put saxon-license.lic and saxonpe.jar in SAXON_HOME\bin
modify org.apache.camel.component.xquery.XQueryBuilder.configuration in class XqueryBuild.java in package org.apache.camel.component.xquery to set LICENSE_FILE_LOCATION ( I got Error: Unknown configuration property http://saxon.sf.net/feature/licenseFileLocation)
The Saxon Documentation mentioned to create an XML configuration file, but I don't know where should I put this XML configuration file.
When running an Xquery with Java call I got the error:
Caused by: net.sf.saxon.trans.XPathException: Cannot find a 0-argument function named Q{java:java.lang.Double}MAX_VALUE(). Reflexive calls to Java methods are not available under Saxon-HE at net.sf.saxon.query.UnboundFunctionLibrary.bindUnboundFunctionReferences(UnboundFunctionLibrary.java:166) ~[saxon9pe.jar!/:na]
at net.sf.saxon.query.QueryModule.bindUnboundFunctionCalls(QueryModule.java:1172) ~[saxon9pe.jar!/:na]
at net.sf.saxon.expr.instruct.Executable.fixupQueryModules(Executable.java:462) ~[saxon9pe.jar!/:na]
at net.sf.saxon.query.XQueryParser.makeXQueryExpression(XQueryParser.java:176) ~[saxon9pe.jar!/:na]
at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:597) ~[saxon9pe.jar!/:na]
at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:658) ~[saxon9pe.jar!/:na]
at org.apache.camel.component.xquery.XQueryBuilder$3.createQueryExpression(XQueryBuilder.java:276) ~[classes!/:2.23.1]
at org.apache.camel.component.xquery.XQueryBuilder.initialize(XQueryBuilder.java:745) ~[classes!/:2.23.1]
at org.apache.camel.component.xquery.XQueryBuilder.evaluateAsDOM(XQueryBuilder.java:190) ~[classes!/:2.23.1]
at org.apache.camel.component.xquery.XQueryBuilder.evaluate(XQueryBuilder.java:151) ~[classes!/:2.23.1]
... 40 common frames omitted
Can some share some experience with setting up Saxon-PE with camel to get calling Java working within Xquery?
Thanks!
From the extra information supplied, it looks as if you're picking up the Saxon JAR file but not the license file.
Putting the license file in the same folder as the JAR file is often enough, but it only works with some classloaders.
In general you either need to ensure that the directory containing the JAR file is on the classpath, or you need to (somehow) set Saxon's configuration property LICENSE_FILE_LOCATION.
According to https://github.com/apache/camel/blob/master/components/camel-saxon/src/main/docs/xquery-component.adoc, you can set Saxon configuration properties using configuration and configurationProperties, but I don't see any further explanation of how this works. I'll have a dig around.
Related
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.
I attempted to install the Traffic library for the book "A Touch of Class" but was not able to compile the examples. EiffelStudio complained about a base2.ecf file.
Error code: VD00
General configuration parsing error.
What to do: fix the configuration file.
Could not open file: \base2.ecf
$EIFFELBASE2\base2.ecf
base2.ecf is found in where Windows installed Eiffel: C:\Program Files\Eiffel Software\EiffelStudio 18.11 GPL\unstable\library\base2.ecf The offending line of code seems to be this in the Traffic configuration files:
I have attempted to change this configuration file pointing directly to where the file is, using the actual path, to no avail.
Setting the variable EIFFELBASE2 might help:
set "EIFFELBASE2=C:\Program Files\Eiffel Software\EiffelStudio 18.11 GPL\unstable\library"
Then, EiffelStudio should be started from the environment where the variable is set.
(However, I wonder if this is the library to be used with the examples, or if there is another one that comes together with the examples.)
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.
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)
So I followed the tutorial on the H2 Documentation page and used the "Connecting to a Database using JDBC" method of connecting to the database. I First added the h2-*.jar file to the Lib Folder (through Netbeans) and used the following to make the connection to my database I previously created.
Class.forName("org.h2.Driver");
connection = DriverManager.getConnection("jdbc:h2:~/" + DatabaseName);
This turned out to work in the IDE environment, however when I attempted to run the application directly from the jar executable I get the following error:
java.lang.ClassNotFoundException: org.h2.Driver ...
this error occurs at the Class.forName() class loader. So I did a little looking around and found that this was a prominent problem. One solution people use was to extract the class Loader from the current Thread as so:
Thread t = Thread.currentThread();
ClassLoader cl = t.getContextClassLoader();
cl.getClass().getClassLoader();
Class toRun = cl.loadClass("org.h2.Driver");
Unfortunately this seems to still result in the same error, so i'm wondering what i'm doing wrong. Should I be doing something to make sure the Driver is in the class path? I have no I idea how if that's the case.
Thanks!
You need to add the h2-*.jar file to the classpath when running the application, for example using
java -cp h2*.jar -jar yourApp.jar