I am having problems triying to create a WS client in java.
The libraries I'm using is apache-cxf 2.12. This is an old version but I want the web service to be added to a JBoss application that is already running and uses Spring 2.5.6, so this org.apache.cxf version uses same spring version.
But the question is (I know is quite generic, is related to maven, netbeans and apache-cxf)
When I execute my client project (maven proyect) from netbeans, it works sort of Ok.
When I try to run this class with a script (bot windows an linux) it gives me this error:
"Invocation failed with the following: org.apache.cxf.ws.policy.PolicyException: None of the policy alternatives can be satisfied."
Java versions are the same, I've copied all the dependency jar into lib dir and added then to %classpath%
So, what can be different that when I execute my sample program with maven org.codehaus.mojo:exec-maven-plugin:1.2.1:exec it works and it doesn't when I run it with a srcipt? (I have checked all dependencies, java version, ... )
I guess it has to be related to JAX-WS o JCE (Java Cryptography Architecture) initialization.
¿Is there a way to see what %classpath maven is creating when in runs java.exe?
Maven script that works:
JAVA_HOME=D:\\LOCAL\\Java\\jdk1.5.0_15
D:\\LOCAL\\apache-maven-2.0.9\\bin\\mvn.bat
-Dexec.classpathScope=runtime
-DskipTests=true
"-Dexec.args=-Djavax.net.debug=all -classpath %classpath es.webservice.aaTest TESTFILE"
-Dexec.executable=D:\\LOCAL\\Java\\jdk1.5.0_15\\bin\\java.exe
-Dmaven.repo.local=D:\\bsrepo\\.m2 process-classes
org.codehaus.mojo:exec-maven-plugin:1.2:exec
Thanks
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 want to change the version of cxf on Service Mix 7.0.1 where cxf version is 3.1.9 . Because of using Brave tracing that is implemented in 3.1.12 version of cxf.
So Is there a way to change the version of the CXF on Service Mix.
I have deleted manually everything in the system/apache/cxf folder that has 3.1.9 version and add a file with 3.2.5 version. But it is still not working. When I write feature:list all of the cxf dependencies are with 3.1.9 version...
Deleting files from the system folder won't work. It does not scan the system folder for files, but rather uses it as a cache to go looking for specific versions. You don't need to add new versions to system either because it will download them from the central maven repo it they arn't in system.
If it starts up without a data folder, it will install features & versions listed in org.apache.karaf.features.cfg
One would expect to be able to delete the data folder, change the version in org.apache.karaf.features.cfg & start it up, but I tried that and Camel was broken. Unsure why.
I find it easier to deal with it using the management console.
Install the management console by dropping the following xml file into the deploy folder:
<features name="features-murray" xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.0.0 http://karaf.apache.org/xmlns/features/v1.2.0">
<repository>mvn:io.hawt/hawtio-karaf/1.5.7/xml/features</repository>
<feature name="murray" version="1" install="auto">
<feature>hawtio-offline</feature>
</feature>
</features>
Then point your browser at http://localhost:8181/hawtio and login with SMX/SMX.
From OSGI/Features add the your new feature version with the plus button:
mvn:org.apache.cxf.karaf/apache-cxf/3.1.12/xml/features
It may take some time to install, because it downloads it from the net. I found it bounced me out of the management console also, but after logging back in I could uninstall the old cxf 3.1.9. It again logged me out of the management console, but after logging back in I had Camel active and CXF on 3.1.12.
No testing though - goodness knows what else is broken.
I followed this tutorial
to get a Bigtable client up and running in Google Managed VMs. But is there a way to run this locally? Reason is that deploying the code remotely in development is a pain.
Normally I can use dev_appserver.sh to run GAE app locally. But when I run it, I'm getting this error:
Caused by: java.lang.IllegalStateException: Jetty ALPN has not been
properly configured.
Which means we need to include ALPN library? Since our codebase is in Java 7, I used this ALPN version: 7.1.3.v20150130.
I then tried again with this:
dev_appserver.sh --jvm_flag=-Xbootclasspath/p:/Users/shouguoli/tmp/alpn-boot-7.1.3.v20150130.jar
still getting this error:
Caused by: com.google.apphosting.api.ApiProxy$CallNotFoundException:
The API package 'urlfetch' or call 'Fetch()' was not found.
How do you get it to work locally?
The sample was updated last week. It's based on the java 8 compat runtime, which means that you have access to most of the App Engine API's including Users, Task Queues, and Datastore.
There is a new Netty TCNative module that uses Boring SSL.
To use it with the pom.xml in the sample, do:
mvn clean -Pmac jetty:run -Dbigtable.projectID=<your-project> -Dbigtable.clusterID=<your-cluster> -Dbigtable.zone=<your-zone>
To use on Windows, use -Pwindows instead of -Pmac. For linux, omit the Profile -P as it's the default.
To deploy:
mvn clean gcloud:deploy -Dbigtable.projectID=<your-project> -Dbigtable.clusterID=<your-cluster> -Dbigtable.zone=<your-zone>
NOTE - it is advisable to do the clean between running locally and running remotely as the TCNative module is currently specific to the platform the code runs on.
We are in the process of updating all of our samples to use TCNative, we hope to have this by 3/10/16.
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)