Hi Wolfgang (and all), Thanks for your offer to help! A lot of implementation work has already been done on the JSR-181 processor; however, there are still pieces missing. I'm currently working on test cases and scenarios; we would certainly appreciate any help in that area. More specifically, for testing functionality and feature completeness we'll soon need:
1) Test cases/scenarios a) We need to identify test scenarios and create annotated .jws files for test cases that model those test scenarios; e.g. for testing JSR-181 rules such as '@Oneway cannot have any "out" parameters', etc. b) We need to integrate those test files into a test framework (see 2) ). 2) Test framework, which takes test scenarios in form of a <Web service> (see below) and does something like the following: a) Automatically builds and deploys the <Web service> in Axis b) Retrieves the WSDL descriptor for the (deployed) <Web service> from Axis c) Tests the equivalence of Axis' WSDL w/ the original WSDL d) Generates a client for the <Web service> (e.g. in a temporary directory) w/ junit tests (e.g. w/ WSDL2Java) e) Builds the client f) Runs generated junit tests against the <Web service> g) Returns the results and removes all temporarily generated files The aforementioned <Web service> contains all source-, class- and other files that make up a Web service, including a WSDL descriptor for the Web services. The files would ideally reside in a directory structure such as: +- <Web service> name +-+- service (contains the .jws file) +- src (contains source files for all supporting classes) +- wsdl (contains the WSDL descriptor for the Web service) An example (with documentation) that adheres to the same directory structure will soon be added to the Beehive/wsm repository. Let me know if you have any questions/suggestions, please. Generally, any form of contributions to discussions/feedback/suggestions on the overall architecture/implementation is also greatly appreciated. Cheers, -michael
