Bug 777631 (SOA-141) - wsconsume.sh script doesn't work
Summary: wsconsume.sh script doesn't work
Keywords:
Status: CLOSED NEXTRELEASE
Alias: SOA-141
Product: JBoss Enterprise SOA Platform 4
Classification: JBoss
Component: Tooling
Version: 4.2 IR6
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.2 IR9
Assignee: Jaroslaw Kijanowski
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-13 17:02 UTC by Jaroslaw Kijanowski
Modified: 2007-12-20 08:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
standalone-soa-4.2.0-IR5.0
Last Closed: 2007-12-20 08:32:41 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SOA-141 0 Major Closed wsconsume.sh script doesn't work 2012-09-03 06:05:38 UTC

Description Jaroslaw Kijanowski 2007-11-13 17:02:04 UTC
Date of First Response: 2007-11-13 22:02:30
project_key: SOA

when tying to run the bin/wsconsume.sh script I get:

JBossWS-Native stack deployed
Exception in thread "main" java.lang.NoClassDefFoundError: gnu/getopt/LongOpt
        at org.jboss.wsf.spi.tools.cmd.WSConsume.parseArguments(WSConsume.java:85)
        at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:78)

Comment 2 Len DiMaggio 2007-11-14 03:10:20 UTC
Seeing the same error with wsprovide.sh

sh ./wsprovide.sh
JBossWS-Native stack deployed
Exception in thread "main" java.lang.NoClassDefFoundError: gnu/getopt/LongOpt
        at org.jboss.wsf.spi.tools.cmd.WSProvide.parseArguments(WSProvide.java:83)
        at org.jboss.wsf.spi.tools.cmd.WSProvide.main(WSProvide.java:76)


Comment 3 Mark Little 2007-11-20 16:37:30 UTC
Is it related to http://lists.jboss.org/pipermail/jbossws-users/2007-June/002380.html

Comment 4 Kevin Conner 2007-11-24 07:22:57 UTC
The issue is that the classpath of these scripts assume that the libraries are located in the /client directory.  This is true for the full version but not for the standalone one.

[kevin@rincewind Desktop]$ unzip -l soa-4.2.0-IR7.0.zip | grep getopt
    15858  11-14-07 19:01   jboss-soa-p.4.2.0/jboss-as/client/getopt.jar
    15858  11-14-07 19:01   jboss-soa-p.4.2.0/jboss-as/lib/getopt.jar
(The above is the version which Trev gave me yesterday and is not the repackaged release)

[kevin@rincewind Desktop]$ unzip -l standalone-soa-4.2.0-IR6.0.zip | grep getopt
    15860  11-16-07 15:31   jboss-soa-p-standalone.4.2.0/lib/getopt.jar


Comment 5 Kevin Conner 2007-11-24 07:24:36 UTC
Assigning to Trev as it is a build issue.

This should disappear once we start slimming down the EAP release to create the standalone version.

Comment 6 trev 2007-11-28 13:19:46 UTC
bash-3.2$ ls standalone-version/lib/getopt.jar
standalone-version/lib/getopt.jar


Comment 7 trev 2007-11-28 13:20:44 UTC
new standalone version based on eap installs it

Comment 8 Jiri Pechanec 2007-12-06 09:30:57 UTC
soa-4.2.0-IR8.0.zip - all config

The problems is that JBossWS tools are not probably present in the classpath

JBossWS-Native stack deployed
Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/tools/ws/wscompile/WsimportTool
        at org.jboss.ws.tools.jaxws.impl.SunRIConsumerFactoryImpl.createConsumer(SunRIConsumerFactoryImpl.java:36)
        at org.jboss.wsf.spi.tools.WSContractConsumer.newInstance(Unknown Source)
        at org.jboss.wsf.spi.tools.WSContractConsumer.newInstance(Unknown Source)
        at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(Unknown Source)
        at org.jboss.wsf.spi.tools.cmd.WSConsume.main(Unknown Source)


Comment 9 trev 2007-12-06 11:23:25 UTC
Link: Added: This issue depends JBPAPP-426


Comment 10 trev 2007-12-06 11:25:18 UTC
This class occurs in jbossws-native-2.0.1.CP2/thirdparty/jaxws-tools.jar
which does not exist in EAP beta 4 and therefore does not make into either SOA version

Comment 11 trev 2007-12-06 11:26:41 UTC
Heiko I've assigned it to you as the EAP Jira was assigned to you, if it's fixed in EAP we will automatically pick it up

Comment 12 Heiko Braun 2007-12-07 16:37:03 UTC
I'll look into it. Sorry for the delay I don't seem to receive JIRA nootifications from this particular project.

Comment 13 Heiko Braun 2007-12-10 16:29:58 UTC
It's a build issue. The magic switch (-Dsoa.build=true) misses a great deal build steps required to install 2.0.1.SP2. Please see JBPAPP-426 for more information. 


Note You need to log in before you can comment on or make changes to this bug.