Ok, Wise-GUI is not tomcat ready is the answer.
Deploying to jbossas 7.1.1 CE things seems to be working fine.
Intial feedback notes:
*The visual appearance is good.
*A desperately missing tool that really tackles/solves problems around quick accessibility to test webservices for those not ready for the learning curve of a Jmeter or SoapUI. Supports agile-style quick testing, but not yet on saving those tests for re-run/repeatability/automation. Supports lower skillset to test webservices for functionality/requirement/interface testing instead of needing a webservice-expert for those types of tests.
*The delay in the UI around using webservices is a little longer than comfortable -- the dynamic nature is understandable, but still a little uncomfortable.
*Definately encourage supporting UI for both WSDL retrieval AND for Endpoint usage, as the endpoint may be different than the WSDL source location (including usage of URL parameters by various webservice vendors, for example a &noredirect=true flag in the URL). The username/password to support none/passwordtext/digest encoded options initially would be good to make it quickly available (SSO/WS-Security later).
---note, desire to support using the same WSDL/operations, but changing endpoint to test variations on different servers is a usecase (dev/qa/uat/staging/stress/production environments, or version 1.0 versus version 1.1). Due to the delay of parsing, may support endpoint swapping during the operational testing portion instead of re-processing the WSDL when changing endpoint. By supporting this feature, may need some (optional) way to do a 'check WSDL against endpoint' to see if it is compliant or not, or possible on a per-operation depending on usecases (i.e. version 1.1 of a WSDL against a 1.0 implementation where most of the old operations should still be valid/work).
*Ability to log in and store/retrieve 'profiles' of environments (potentially shared between users in a group), as well as a 'profile' of saved tests (again potentially shared between users in a group). Usecase is for setup by development/deployment staff for environment and WSDL source and endpoint identification, then have QA/Review staff use those profiles to quickly begin work. The storage of profiles should require username/password for security purposes.
--EDIT/addendum: another usecase would be to create an environment/test, and be able to 'export' that environment profile & test to a distributable file. This would allow transport/portability of environment/tests if working between different companies testing the same services with the same tool, as well as for easy publishing/attaching of tests to ticket systems (jira et al).
--note, as a proof-of-concept, I think in-memory would be ok/good enough to avoid database/file resources initially, and continue to support swapping between 'in-memory' profiles for quick setup/usage scenarios, and database/file profiles for long-term engagements and when associated infrastructure support is available.
I find it useful to get initial feedback thoughts, so I hope this is helpful!
thanks a lot for your feedback, very much appreciated.
Yes, atm the gui is meant to be deployed on JBoss AS only, not on Tomcat (many libraries are not included in the deployment archive as they're already available on JBoss AS).
I've created a few new feature jiras for some of your proposal above:
Some of them are tentatively scheduled for next 2.0.1 version, the others for future releases.