[seek-dev] Re: Stubs

[Jing Tao]

Hi, Matt:

Thanks for the reply! I add some comments below your text too :)
On Wed, 8 Oct 2003, Matt Jones wrote:

> Hi Jing,
> 
> Well, those isues resolved as I expected. A few comments are 
> interspersed below in your text.
> 
> Jing Tao wrote:
> > Hi, Matt:
> > 
> > 1. <xs:restriction> in complexType
> > I searched the bug list in Axis, there is bug (#21981) about this issue. 
> > They said it was fixed in 07/30/2003. So I don't think it is avaliable in any 
> > release. The last release of Axis is 1.1 in June, 2003.
> 
> Maybe we can get WSDL2Java from the Axis CVS and use it for stub 
> generation until a new version of Axis is released and incorporated into 
> globus?

Yes, we can try it. But from the comment in this bug, it seem they just 
resolved partly and is waiting more comment. More over, cvs version 
probably broke other stuff :)


> 
> > I have to  modify the resultset.xsd to handle this issue:
> > Add an element named content in AnyRecordType and set content element 
> > AnyContentType. AnyContentType is a singleType with a restriction base on 
> > anyType. I know it is a hack but we have to :)
> > So the stub class can be generated with settor and gettor successfully. 
> 
> This will probably work fine, but can the simpleType contain element 
> content?.

No, I didn't add element "content" in a simpleType. I added element 
"content" in AnyRecordType which is complexType. I checked in the modified 
resultset.xsd yesterday and you might take a look. Thanks.

> 
> > But the code generated from Axis could not be compiled! Because it calls a 
> > constructor which never show in both java 1.3 and java 1.4! The line looks 
> > like:
> > Ojbect obj = new Object(String str); 
> > Actuarlly, java doesn't have this constructor at all. So we have to modify 
> > the code.
> 
> That's strange.  Is the Object generated associated with the 
> AnyRecordType?  Why would it be trying to use a non-existing constructor?

The Ojbect is in AnyContentType.java class. They try to make a constructor 
with parameter string. The string should be casted to the object, but they 
call a non-existed constructor to convert a string to a object. The line 
21 in AnyContentType.java is one I modified. The orginal one is:
this.value = new java.lang.Object(value);
//The first "value" is an Object, the second "value" is a String object.


> 
> > 2. Repeatable choice issue:
> > The bug 15789 is about the issue. This bug opened in jan 2003, but status 
> > is new. So we have to modify the code manully. A question: if we change 
> > the attribute from single object to an array in ANDType.java and ORType.java 
> > and compile it successfully, I am not sure if Axis can serialize and 
> > deserialize xml correctly? In another word, except the two classes, do we 
> > need change other stuff? 
> 
> Glad they recognize the issue at least.  I think we can modify the stub 
> and change them to arrays and we'll be able to handle the content model 
> without a problem.   The axis serialization strategy seems to rely on a 
> BeanSerializer that can handle basic types, and then custom serializers 
> for more complex types.  I don't know if their default serializer will 
> notice the change to an array -- one way to find out is to just try it 
> :)  Or you could try to look up the capabilities of the serializer in 
> more detail.

I will try it to see what will happen.


> > 
> > 3. Build file
> > Axis broke our automatation, so I have to break my build.xml too: ) In 
> > build.xml there is a target named stubs, it will generate stubs classes in 
> > build dir and copy the file to src.dir. In src.dir, we can modify the code 
> > if we want and check-in to cvs. When we run gar, now we don't call stubs 
> > but call target "copystubs" - which will copy the modified stubs files 
> > from src dir to build dir, then complie and jar them. So generatlly, if we 
> > changed the schema or wsdl, we need run stubs and modified the stub file. 
> > In other case, we only used the stubs file stored in src dir(in cvs too).
> 
> Sounds fine.  It would be nice if it could be more automated, but I 
> understand that we're trying to work around broken tools.  I think it 
> would be a good idea to lay out explicitly what needs to happen when a 
> change to the xsd files is made -- probably write down all of the steps 
> in the README.

I will write a README file for this.


> > 
> > Any suggestion, comment are appreciated!
> > 
> > Thanks.
> > 
> > Jing
> 
> Thanks for looking into all of this.
> 
> Matt
> 
> 

Thanks.

Jing


-- 
Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101