I also think its an area where we can make fast progress. It seems to me that the new architecture can be much more effective than the old architecture.
Dims - maybe it would be useful if you or one of the old hands in Axis1 could go through old JIRAs or your deep memory banks and come up with a list of potential issues you think we should deal with, and then we can work through them. The fact is that there is no simple way we can "learn" from Axis1 other than the considered and helpful input of the guys who did it first time.
The only other thing is that WSDL2Java v2 is a complete mystery to me - and maybe to others. Perhaps we need to make a concerted effort to get one or two more people up and running on it so that we can progress faster.
Paul
PS I don't think its a mess ..... its just at an earlier stage than the other parts of Axis2. I've been playing with WSDL2Java quite a bit. I'm not sure it helps to say its a mess when people are working hard at improving it!
PPS One area that needs some improvement is getting line numbers in error messages - or we need a WSDL validator to run first. I tend to have to use Axis1 to debug my WSDL before I run Axis2.
On 1/5/06, Sanjiva Weerawarana (JIRA) <[EMAIL PROTECTED]> wrote:
[ http://issues.apache.org/jira/browse/AXIS2-359?page=comments#action_12361868 ]
Sanjiva Weerawarana commented on AXIS2-359:
-------------------------------------------
Um, is the fix to this just the stuff that was in the original issue report? If so that hardly qualifies as "deep mess".
Come on Dims, we *do* leverage Axis1 .. I can't believe you are saying that we should get much/anything out of the old symboltable mess that Axis1's WSDL2Java was/is. Just because there are certain cases we don't handle doesn't mean we are not learning from the past. That's exactly why we're still in 0.93+ and not in 1.xx.
BTW http://soapinterop.java.sun.com/round3/groupd/imported/import2B.wsdl does not appear to be WS-BP 1.0 compliant; did they not outlaw importing XSDs using wsdl:import?
> Stack overflow when processing XSD with mutual recursion
> --------------------------------------------------------
>
> Key: AXIS2-359
> URL: http://issues.apache.org/jira/browse/AXIS2-359
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Components: wsdl
> Versions: 0.9, 0.91, 0.92, 0.93
> Environment: Win2K, Java 1.4.2_08-b03, Axis2 0.91, Axis2 0.93
> Reporter: Kevin J. Winters
>
> The recursive method WSDLPump.pushSchemaElement(...) does not protect against schemas with mutual recursion. A check of already processed namespaces could be used to prevent the stack overflow in a manner similar to:
> ...
> /** begin mod **/
> private HashSet schemaCache = new HashSet();
> /** end mod **/
>
> private void pushSchemaElement(Schema originalSchema,Stack stack){
> if (originalSchema==null){
> return;
> }
>
> /** begin mod **/
> if ( schemaCache.contains(originalSchema.getDocumentBaseURI())) {
> return;
> } else {
> schemaCache.add(originalSchema.getDocumentBaseURI());
> }
> /** end mod **/
> stack.push(originalSchema);
> ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
