Metro has been contributed to Eclipse Foundation. This repository is for legacy review only. Please refer to the Eclipse EE4J Metro project for the very latest
I needed quite a while to figure out how to solve the error message I was confronted with (see below).
The problem starts with the Maven plugin executing a long command line (like cmd.exe /X /C ""C:\Program Files\Java\jdk1.8.0_05\jre\bin\java.exe" "-Xbootclasspath/p:C:\Users[1000 characters more]) and printing/piping/pumping stdout and stderr of that command line. The problem was, in this case it only printed this:
Exception in thread "main" java.lang.ClassCastException: java.lang.AssertionError cannot be cast to java.lang.Exception
at org.jvnet.jax_ws_commons.jaxws.Invoker.main(Invoker.java:87)
How was I supposed to find out what went wrong with this useless information? This wasn't easy to figure out.
I finally succeeded by copying the generated command line to a console, extending it with parameters for the jpda debugger, handling this ever deleted jax-ws-mvn-plugin-cp6264895763968054586.txt file, and going through with the debugger of my IDE.
It turned out that the java.lang.AssertionError was thrown from class com.sun.tools.xjc.SchemaCache, line 80, and was going back to an org.xml.sax.SAXParseException reading "schema_reference: Failed to read schema document 'xjc.xsd', because 'file' access is not allowed due to restriction set by the accessExternalSchema property."
That's the message I quoted/linked to at the beginning of this bug report.
Now, I think throwing this as an AssertionError seems a little suspicious there. If it's part of your code, you might consider using a declared exception instead.
My main point is however that org.jvnet.jax_ws_commons.jaxws.Invoker, which indeed seems to be part of your code should not do this:
I'm not even sure this exception needs to be caught at all. Perhaps you should just let it fall through, and that's it.
I hope you're getting my point and why this would help a real lot.
To sum it up: The current design of your code causes a certain class of problems (namely all kinds of java.lang.Error s) to print a useless message about a class cast problem which make it extremely hard to find out what really wrong.
Thanks for fixing it for all future users of the framework.
Hi, to cut a long story short, when using the wsimport Maven plugin, I ran into the following problem, but at that time I didn't know it was that problem: http://stackoverflow.com/questions/23011547/webservice-client-generation-error-with-jdk8
I needed quite a while to figure out how to solve the error message I was confronted with (see below).
The problem starts with the Maven plugin executing a long command line (like cmd.exe /X /C ""C:\Program Files\Java\jdk1.8.0_05\jre\bin\java.exe" "-Xbootclasspath/p:C:\Users[1000 characters more]) and printing/piping/pumping stdout and stderr of that command line. The problem was, in this case it only printed this:
How was I supposed to find out what went wrong with this useless information? This wasn't easy to figure out.
I finally succeeded by copying the generated command line to a console, extending it with parameters for the jpda debugger, handling this ever deleted jax-ws-mvn-plugin-cp6264895763968054586.txt file, and going through with the debugger of my IDE. It turned out that the java.lang.AssertionError was thrown from class com.sun.tools.xjc.SchemaCache, line 80, and was going back to an org.xml.sax.SAXParseException reading "schema_reference: Failed to read schema document 'xjc.xsd', because 'file' access is not allowed due to restriction set by the accessExternalSchema property."
That's the message I quoted/linked to at the beginning of this bug report.
Now, I think throwing this as an AssertionError seems a little suspicious there. If it's part of your code, you might consider using a declared exception instead.
My main point is however that org.jvnet.jax_ws_commons.jaxws.Invoker, which indeed seems to be part of your code should not do this:
Instead that code should read something like this:
I'm not even sure this exception needs to be caught at all. Perhaps you should just let it fall through, and that's it.
I hope you're getting my point and why this would help a real lot.
To sum it up: The current design of your code causes a certain class of problems (namely all kinds of java.lang.Error s) to print a useless message about a class cast problem which make it extremely hard to find out what really wrong.
Thanks for fixing it for all future users of the framework.
Environment
JDK 8, Windows 7
Affected Versions
[2.3]