You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Campana Jr., Salvatore J" <sa...@hp.com> on 2004/07/28 21:23:48 UTC

FOLLOW-UP: Bug?? Issue with Wsdl2Java and extended schema types

I've done some digging on this and I see 2 possible areas where a fix
could occur....
 
1. In the generation (as described in the original email)
2. TypeDesc.getFieldNameForElement (where the actual look-up occurs)
 
Scenario #1:
 
Doing the fix in generation would entail when writing the request
objects the writer would need to traverse the defined schema types to
see if anything extends the current parameter type.  This seems as
though it would be rather difficult, if possible at all...
 
Scenario #2:
 
Modifying the TypeDesc.getFieldNameForElement would mean that once it
checks against the fields[], if it does not find a match it would then
need to find a way to lookup the type (typemapping??) and then it would
need to determine the type is an extension of the required type....
 
Which makes the most sense??  I am willing to write a patch, but I want
to make sure someone "in the know" can give me a nod...
 
thx!
 
-Sal
 
 
 

________________________________

From: Campana Jr., Salvatore J 
Sent: Monday, July 19, 2004 11:54 AM
To: 'axis-dev@ws.apache.org'
Subject: Bug?? Issue with Wsdl2Java and extended schema types


I noticed this issue when using Wsdl2Java to generate code for this
wsdl:
 
http://www-106.ibm.com/developerworks/webservices/library/ws-resource/WS
-ResourceProperties.wsdl
 
 
The bug appears to be associated with extending schema types using
extension base.  There is an operation SetResourceProperties which takes
a schema type SetRequestComponent.  There are three extensions to the
SetRequestComponent: InsertType, UpdateType, DeleteType.  Axis generates
the correct types for these objects which extend the generated
SetRequestComponentType, however they never get truly "wired-in" in the
generated _SetResourceProperties file, and thus requests containing
those types will not work....
 
I was able to hand-modify the code to make it work:
 
1. added ElementDescs to the typeDesc for each extension type. (static
block)
2. added SetRequestComponentType[] fields to the class for each type.
3. added associated Setters for the fields which handed off to the
generated setSetRequestComponent( setRequestComponent ); operation....
4. Commented section in static block which registered the basetype...
 
I've attached the src with comments (look for sjc in the comments)....
 
If this is truly a bug (and not my misunderstanding of things) then I
will submit it as such.
 
I'm hoping that this can be resolved so that I will not need to
hand-modify the generated source.  I will be happy to help in any way in
getting this issue resolved.  I am willing to assist in writing the fix
(with a little guidance ;-) )
 
thank you!!
 

________________________________


Sal Campana
HP Software
856.638.6284
sal_campana@hp.com <ma...@hp.com>  

<ma...@hp.com>  

 

Re: FOLLOW-UP: Bug?? Issue with Wsdl2Java and extended schema types

Posted by Davanum Srinivas <da...@gmail.com>.
My gut feeling....try #1 first :)

thanks,
dims

----- Original Message -----
From: Campana Jr., Salvatore J <sa...@hp.com>
Date: Wed, 28 Jul 2004 15:23:48 -0400
Subject: FOLLOW-UP: Bug?? Issue with Wsdl2Java and extended schema types
To: axis-dev@ws.apache.org

 
I've done some digging on this and I see 2 possible areas where a fix
could occur....
  
1. In the generation (as described in the original email) 
2. TypeDesc.getFieldNameForElement (where the actual look-up occurs) 
  
Scenario #1: 
  
Doing the fix in generation would entail when writing the request
objects the writer would need to traverse the defined schema types to
see if anything extends the current parameter type.  This seems as
though it would be rather difficult, if possible at all...
  
Scenario #2: 
  
Modifying the TypeDesc.getFieldNameForElement would mean that once it
checks against the fields[], if it does not find a match it would then
need to find a way to lookup the type (typemapping??) and then it
would need to determine the type is an extension of the required
type....
  
Which makes the most sense??  I am willing to write a patch, but I
want to make sure someone "in the know" can give me a nod...
  
thx! 
  
-Sal 
  
  
 
 
 ________________________________
 From: Campana Jr., Salvatore J 
Sent: Monday, July 19, 2004 11:54 AM
To: 'axis-dev@ws.apache.org'
Subject: Bug?? Issue with Wsdl2Java and extended schema types

 
 
 
I noticed this issue when using Wsdl2Java to generate code for this wsdl: 
  
http://www-106.ibm.com/developerworks/webservices/library/ws-resource/WS-ResourceProperties.wsdl
  
  
The bug appears to be associated with extending schema types using
extension base.  There is an operation SetResourceProperties which
takes a schema type SetRequestComponent.  There are three extensions
to the SetRequestComponent: InsertType, UpdateType, DeleteType.  Axis
generates the correct types for these objects which extend the
generated SetRequestComponentType, however they never get truly
"wired-in" in the generated _SetResourceProperties file, and thus
requests containing those types will not work....
  
I was able to hand-modify the code to make it work: 
  
1. added ElementDescs to the typeDesc for each extension type. (static block) 
2. added SetRequestComponentType[] fields to the class for each type. 
3. added associated Setters for the fields which handed off to the
generated setSetRequestComponent( setRequestComponent ); operation....
4. Commented section in static block which registered the basetype... 
  
I've attached the src with comments (look for sjc in the comments).... 
  
If this is truly a bug (and not my misunderstanding of things) then I
will submit it as such.
  
I'm hoping that this can be resolved so that I will not need to
hand-modify the generated source.  I will be happy to help in any way
in getting this issue resolved.  I am willing to assist in writing the
fix (with a little guidance ;-) )
  
thank you!! 
  
 

 ________________________________
 
 

Sal Campana
HP Software
856.638.6284
sal_campana@hp.com 

  
  





-- 
Davanum Srinivas - http://webservices.apache.org/~dims/