[seek-dev] Re: Stubs

[Matt Jones]

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?

> 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?.

> 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?

> 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.
> 
> 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.
> 
> Any suggestion, comment are appreciated!
> 
> Thanks.
> 
> Jing

Thanks for looking into all of this.

Matt

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------