[Design of JBoss Web Services] - Error while using Wise Soap Client
by ashwindesikan
I am trying to consume an external webservice in my jboss-esb.xml using the Wise SOAPClient
I receive the following error during execution
18:44:41,871 INFO [STDOUT] [ERROR] com.sun.tools.javac.Main is not available in the classpath, requires Suns JDK version 5.0 or latter.
18:44:41,876 INFO [STDOUT] unknown location
18:44:41,876 INFO [STDOUT] compilation failed, errors should have been reported
18:44:41,877 INFO [STDOUT] Failed to invoke WsImport
18:44:41,877 INFO [STDOUT] java.lang.IllegalStateException: WsImport invocation failed. Try the verbose switch for more information
What can I do to fix this issue? I have jdk 1.5 and when I try to import the wsdl using wsimport from command i don't receive any errors?
Following is the log from my error console
18:43:55,876 INFO [Server] JBoss (MX MicroKernel) [4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181439)] Started in 34s:70ms
18:44:40,813 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
18:44:40,814 INFO [STDOUT] Request map is: {toWhom=Jimbo}
18:44:40,814 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
18:44:41,071 INFO [STDOUT] parsing WSDL...
18:44:41,835 INFO [STDOUT] generating code...
18:44:41,855 INFO [STDOUT] it/javalinux/wise/HelloWorld.java
18:44:41,860 INFO [STDOUT] it/javalinux/wise/HelloWorldWSService.java
18:44:41,862 INFO [STDOUT] it/javalinux/wise/ObjectFactory.java
18:44:41,864 INFO [STDOUT] it/javalinux/wise/SayHello.java
18:44:41,865 INFO [STDOUT] it/javalinux/wise/SayHelloResponse.java
18:44:41,866 INFO [STDOUT] it/javalinux/wise/package-info.java
18:44:41,871 INFO [STDOUT] [ERROR] com.sun.tools.javac.Main is not available in the classpath, requires Suns JDK version 5.0 or latter.
18:44:41,876 INFO [STDOUT] unknown location
18:44:41,876 INFO [STDOUT] compilation failed, errors should have been reported
18:44:41,877 INFO [STDOUT] Failed to invoke WsImport
18:44:41,877 INFO [STDOUT] java.lang.IllegalStateException: WsImport invocation failed. Try the verbose switch for more information
18:44:41,877 INFO [STDOUT] at org.jboss.ws.tools.jaxws.impl.SunRIConsumerImpl.consume(SunRIConsumerImpl.java:220)
18:44:41,877 INFO [STDOUT] at org.jboss.wsf.spi.tools.WSContractConsumer.consume(WSContractConsumer.java:196)
18:44:41,877 INFO [STDOUT] at it.javalinux.wise.core.client.WSDynamicClient.importObjectFromWsdl(WSDynamicClient.java:165)
18:44:41,877 INFO [STDOUT] at it.javalinux.wise.core.client.WSDynamicClient.init(WSDynamicClient.java:125)
18:44:41,877 INFO [STDOUT] at it.javalinux.wise.core.client.WSDynamicClient.init(WSDynamicClient.java:94)
18:44:41,877 INFO [STDOUT] at it.javalinux.wise.core.client.WSDynamicClientFactory.getClient(WSDynamicClientFactory.java:120)
18:44:41,878 INFO [STDOUT] at org.jboss.soa.esb.actions.soap.wise.SOAPClient.process(SOAPClient.java:225)
18:44:41,878 INFO [STDOUT] at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:316)
18:44:41,878 INFO [STDOUT] at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:530)
18:44:41,878 INFO [STDOUT] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
18:44:41,878 INFO [STDOUT] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
18:44:41,878 INFO [STDOUT] at java.lang.Thread.run(Thread.java:619)
18:44:41,879 ERROR [STDERR] it.javalinux.wise.core.exceptions.WiseRuntimeException: Error occurred while consuming wsdl: /tmp/Wise0.xml
18:44:41,879 ERROR [STDERR] at it.javalinux.wise.core.exceptions.WiseRuntimeException.rethrow(WiseRuntimeException.java:44)
18:44:41,880 ERROR [STDERR] at it.javalinux.wise.core.client.WSDynamicClient.init(WSDynamicClient.java:151)
18:44:41,880 ERROR [STDERR] at it.javalinux.wise.core.client.WSDynamicClient.init(WSDynamicClient.java:94)
18:44:41,880 ERROR [STDERR] at it.javalinux.wise.core.client.WSDynamicClientFactory.getClient(WSDynamicClientFactory.java:120)
18:44:41,880 ERROR [STDERR] at org.jboss.soa.esb.actions.soap.wise.SOAPClient.process(SOAPClient.java:225)
18:44:41,880 ERROR [STDERR] at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:316)
18:44:41,880 ERROR [STDERR] at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:530)
18:44:41,880 ERROR [STDERR] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
18:44:41,880 ERROR [STDERR] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
18:44:41,880 ERROR [STDERR] at java.lang.Thread.run(Thread.java:619)
18:44:41,881 ERROR [STDERR] Caused by: java.lang.NullPointerException
18:44:41,881 ERROR [STDERR] at it.javalinux.wise.core.client.WSDynamicClient.getClassNames(WSDynamicClient.java:181)
18:44:41,881 ERROR [STDERR] at it.javalinux.wise.core.client.WSDynamicClient.init(WSDynamicClient.java:127)
18:44:41,881 ERROR [STDERR] ... 8 more
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218123#4218123
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218123
16 years, 6 months
[Design of JBoss Web Services] - Re: JBossWS Test Approach
by alessio.soldano＠jboss.com
"richard.opalka(a)jboss.com" wrote : "alessio.soldano(a)jboss.com" wrote : what would you suggest instead of that? I don't like that much the idea of specifying the surefire additionalClasspath with a list of jar from the curent AS... any other idea?
| I'm thinking exactly about that ;) But I have to googlize this problem much more. I don't believe we're the first one facing this problem.
|
OK, let's see if there's a better solution :-)
anonymous wrote : "alessio.soldano(a)jboss.com" wrote :
| | After all, we also get advantages from using maven dependencies to build test classpath, otherwise we need keep track of jar changes (names, position), addition of jars (while we simply get the new dependency for free when somebody updates the dependency in an artifact we include), etc.
| Wrong point of view. I'd maintain all this staff like we did it before JBossWS mavenization and like we do it now (see our binary distribution) and be sure we're using proper jars directly from AS than using current approach which is broken.
|
| Current approach doesn't save anything. It just makes me sleep really very bad :(
| I have a nightmare regularly at nights where I'm debugging for hours/days something and finally solving the problem with conclusion we're using wrong client classpath and hotfixing it with one maven dependencies exclusion in our testsuite pom.xml
|
Don't get me wrong, I'm not saying there's not a problem and we have an easy life with this way of working ;-) Just trying to evaluate the situation, let's think about alternatives (at least given the current state of the AS).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216146#4216146
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216146
16 years, 7 months
[Design of JBoss Web Services] - Re: JBossWS Test Approach
by alessio.soldano＠jboss.com
"richard.opalka(a)jboss.com" wrote : Because we're supporting multiple AS versions we can't
| construct proper client classpath using maven dependencies..
Given that I see the issue that drove to this forum thread, I don't get why you think we can't construct proper client classpath using m2 dependencies because we're using multiple AS versions.
anonymous wrote :
| Example:
|
| JBossWS 3.0.5
| AS 5.0.0
|
| Which jaxb-impl version will be used in testing if we don't exclude it?
|
| (dependency:tree output from testsuite module in jboss500 configuration)
| [INFO] org.jboss.ws.native:jbossws-native-testsuite:pom:3.0.5.GA
| [INFO] +- org.jboss.ws.native:jbossws-native-client:jar:3.0.5.GA:compile
| [INFO] | +- org.jboss.ws.native:jbossws-native-core:jar:3.0.5.GA:compile
| [INFO] | | +- com.sun.xml.bind:jaxb-impl:jar:2.1.6:compile
| ...
| [INFO] +- org.jboss.ws:jbossws-jboss500:jar:3.0.5.GA:compile
| [INFO] | +- org.jboss:jbossxb:jar:2.0.0.GA:compile
| [INFO] | | +- sun-jaxb:jaxb-api:jar:2.1.4:compile
| ...
|
The artifact that's closest to the root will be used (with the distance being defined by the number of nested dependencies you need to go through to reach the artifact).
anonymous wrote :
| We can't exclude jaxb-impl neither from jbossws-native-client (note doesn't matter the different group.id)
| neither jaxb-impl from jbossws-jboss500 because it's compile dependency (it won't compile without it).
| We could exclude jaxb-impl either from jbossws-native-client or from jbossws-jboss500 in testsuite.pom xml.
Exclusions are required only when the closest version of a given artifact is not the one you want to use, but this should not happen if the dependency hierarchy is well done (which did not apply in our webservice module since some days ago).
This is besides the original problem, just to be clear on maven.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216141#4216141
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216141
16 years, 7 months
[Design of JBoss Web Services] - Re: JBossWS Test Approach
by richard.opalka＠jboss.com
"alessio.soldano(a)jboss.com" wrote : Basing the tests on maven dependencies was the most natural solution when the mavenization took place,
Well I have different point of view on it:( It don't think it was the most natural solution to mavenize our test suite.
"alessio.soldano(a)jboss.com" wrote : what would you suggest instead of that? I don't like that much the idea of specifying the surefire additionalClasspath with a list of jar from the curent AS... any other idea?
I'm thinking exactly about that ;) But I have to googlize this problem much more. I don't believe we're the first one facing this problem.
"alessio.soldano(a)jboss.com" wrote :
| After all, we also get advantages from using maven dependencies to build test classpath, otherwise we need keep track of jar changes (names, position), addition of jars (while we simply get the new dependency for free when somebody updates the dependency in an artifact we include), etc.
Wrong point of view. I'd maintain all this staff like we did it before JBossWS mavenization and like we do it now (see our binary distribution) and be sure we're using proper jars directly from AS than using current approach which is broken.
Current approach doesn't save anything. It just makes me sleep really very bad :(
I have a nightmare regularly at nights where I'm debugging for hours/days something and finally solving the problem with conclusion we're using wrong client classpath and hotfixing it with one maven dependencies exclusion in our testsuite pom.xml
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216135#4216135
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216135
16 years, 7 months
[Design of JBoss Web Services] - Re: JBossWS Test Approach
by richard.opalka＠jboss.com
JBossWS supports AS 5.0.0, 5.0.1, Branch_5_x and trunk (version numbers will change in the future).
Each AS has it's dependencies specifed using maven.
Each of these dependencies specified in AS components matrix
has its own dependencies on another subprojects.
To be absolutely clear the main problem I'm talking here is:
Because we're supporting multiple AS versions we can't
construct proper client classpath using maven dependencies..
Example:
JBossWS 3.0.5
AS 5.0.0
Q1) Which jaxb-impl version will be used in testing if we don't exclude it?
(dependency:tree output from testsuite module in jboss500 configuration)
[INFO] org.jboss.ws.native:jbossws-native-testsuite:pom:3.0.5.GA
[INFO] +- org.jboss.ws.native:jbossws-native-client:jar:3.0.5.GA:compile
[INFO] | +- org.jboss.ws.native:jbossws-native-core:jar:3.0.5.GA:compile
[INFO] | | +- com.sun.xml.bind:jaxb-impl:jar:2.1.6:compile
...
[INFO] +- org.jboss.ws:jbossws-jboss500:jar:3.0.5.GA:compile
[INFO] | +- org.jboss:jbossxb:jar:2.0.0.GA:compile
[INFO] | | +- sun-jaxb:jaxb-api:jar:2.1.4:compile
...
We can't exclude jaxb-impl neither from jbossws-native-client (note doesn't matter the different group.id)
neither jaxb-impl from jbossws-jboss500 because it's compile dependency (it won't compile without it).
We could exclude jaxb-impl either from jbossws-native-client or from jbossws-jboss500 in testsuite.pom xml.
But doing so for each conflicting component (there are many such) would be a real maintainability nightmare (especially for moving AS versions even they would be fully mavenized as mentioned in above post)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216131#4216131
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216131
16 years, 7 months
[Design of JBoss Web Services] - Re: JBossWS Test Approach
by richard.opalka＠jboss.com
"alessio.soldano(a)jboss.com" wrote :
| ... we're evaluating this still a bit early ...
| I don't think so. We were talking about this problem a year ago for the first time. I'm afraid we'll be talking about it next years :(
"alessio.soldano(a)jboss.com" wrote :
| ... AS is not completely mavenized yet ...
| and won't be next few years ;) Note that AS mavenization process runs already more than 1 year and it's still at its beginnings.
"alessio.soldano(a)jboss.com" wrote :
| ...Once the process will be completed I think we will be pretty sure we're testing against the right artifacts.
| Almost true, but not absolute ;)
"alessio.soldano(a)jboss.com" wrote :
| This said, the specific failures that made us to stop and think about our testing approach were caused by some mistakes we actually did in the webservice module pom.xml in the AS. IOW it didn't have the right dependencies which were instead specified in the container integration pom.xml files. Of course this caused the trunk and 5_x branch only to fail, but I fixed that. The whole "exclusion game" in the stacks' testsuite pom.xml is not required anymore, there're few dependencies still specified there and they're quite straightforward.
| Thanks for the hotfix Alessio, but it didn't solve the problem I'm discussing here. It just hotfixed the result of the problem. I'd like to fix the reason of all these problems instead. I'll explain this argument in next post following this one.
"alessio.soldano(a)jboss.com" wrote :
| Finally, considering we're using maven for the project, I think it's important to run tests using surefire. IOW my point of view is that either we use this tool (maven) completely or we don't use it (which currently is not an option given the direction taken 1 year ago by the whole AS development).
| Basing the tests on maven dependencies was the most natural solution when the mavenization took place, what would you suggest instead of that? I don't like that much the idea of specifying the surefire additionalClasspath with a list of jar from the curent AS... any other idea?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216117#4216117
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216117
16 years, 7 months