[jira] Commented: (AXIS2-2610) wsdl2java tool to allow additional java classes to be added for schema generation

2007-06-22 Thread Bo Xie (JIRA)

[ 
https://issues.apache.org/jira/browse/AXIS2-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507446
 ] 

Bo Xie commented on AXIS2-2610:
---

Hi Dims,

  Thanks for the good news. How do I get the fix? Any doc on the new command
options?

Thanks,
-Bo



> wsdl2java tool to allow additional java classes to be added for schema 
> generation
> -
>
> Key: AXIS2-2610
> URL: https://issues.apache.org/jira/browse/AXIS2-2610
> Project: Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Bo Xie
>Assignee: Deepal Jayasinghe
>
> Bo,
> Please log an enhancement issue in JIRA for adding support to
> Java2WSDL to specify additional classes for which schema needs to be
> generated.
> thanks,
> dims
> On 4/28/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> > You might try JiBX or XMLBeans.
> >
> > On 4/27/07, Bo Xie <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > >   I need advice on how to use java2wsdl or other tools to generate XML
> > > schema from java class for operation parameters. I understand using
> > > java2wsdl, it will generate the schema for all the data type used as
> > > parameter for the operation. But I could not find a way to generate schema
> > > for any derived class types. For example, if I have a method doSomething(
> > > BaseType type). The generated schema will include schema for BaseType 
> > > only.
> > > I need to handcraft the schema for devicedTypeA, devicedTypeB into the 
> > > WSDL
> > > schema definition in order to pass deviceTypeA, deviceTypeB instances in
> > > doSomething operation at runtime.
> > >
> > > Thanks for your time.
> > >
> > > -Bo
> > >
> > > 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (AXIS2-2610) wsdl2java tool to allow additional java classes to be added for schema generation

2007-04-30 Thread Bo Xie (JIRA)
wsdl2java tool to allow additional java classes to be added for schema 
generation
-

 Key: AXIS2-2610
 URL: https://issues.apache.org/jira/browse/AXIS2-2610
 Project: Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: Tools
Reporter: Bo Xie


Bo,

Please log an enhancement issue in JIRA for adding support to
Java2WSDL to specify additional classes for which schema needs to be
generated.

thanks,
dims

On 4/28/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> You might try JiBX or XMLBeans.
>
> On 4/27/07, Bo Xie <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> >   I need advice on how to use java2wsdl or other tools to generate XML
> > schema from java class for operation parameters. I understand using
> > java2wsdl, it will generate the schema for all the data type used as
> > parameter for the operation. But I could not find a way to generate schema
> > for any derived class types. For example, if I have a method doSomething(
> > BaseType type). The generated schema will include schema for BaseType only.
> > I need to handcraft the schema for devicedTypeA, devicedTypeB into the WSDL
> > schema definition in order to pass deviceTypeA, deviceTypeB instances in
> > doSomething operation at runtime.
> >
> > Thanks for your time.
> >
> > -Bo
> >
> > 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (AXIS2-1938) [axis2] WSDL2JAVA with XMLBean binding does not create instance of the derived type or ignore xsi:type in the xml

2007-01-27 Thread Bo Xie (JIRA)

[ 
https://issues.apache.org/jira/browse/AXIS2-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468050
 ] 

Bo Xie commented on AXIS2-1938:
---

Looks like this is related with xsd resource loading on the service side. This 
kinda explain why the same code worked on client side(with the xsi:type 
generated) but not on the service side. Update with more info on the email 
thread.

Thanks,
-Bo

Hi,

   My previous issue is caused by org.apache.xmlbeans.impl

.schema.SchemaTypeLoaderImpl's findTypeRef () not be able to load the 
following resource in service: 


schemaorg_apache_xmlbeans/type/http_3A_2F_2Fquickstart_2Esamples_2Fxsd/EU_2DAddress.xsb

This resource is actually in my .aar file under 
dir\XBean-packaged.jar(generated from WSDL2JAVA)

Do anyone know how to make it work?

Thanks a lot!

-Bo



On 1/21/07, Bo Xie <[EMAIL PROTECTED] > wrote:

Hi all,

Sorry to ask this again, does anyone know what could cause the 
following call to return null, is it some kind of setup/configure issue in the 
service? How to workaround it? It is in 
org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl's findTypeRef (). This 
causes the derived type cannot be created properly with the xsi:type attribute.

SchemaTypeSystem ts = typeSystemForComponent("schema" + 
METADATA_PACKAGE_LOAD + "/type/", name);


Thanks,
-Bo



On 1/19/07, Bo Xie <[EMAIL PROTECTED] > wrote:

Hi,

  Looks like the problem is with the _typeCache in 
org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl's findTypeRef () not being 
populated correctly for derived type when deployed as a service. This in turn 
was caused by typeSystemForComponent() in findTypeRef() returning null. As 
comparison, the _typeCache is populated correctly if I run it locally in a test 
program's main() and in this case the typeSystemForComponent() is not null.

  Below is the findTypeRef method which suppose to return the derived 
type if Qname passed in is a derived type. In my case, the QName is { 
http://quickstart.samples/xsd}EU-Address .

  When in service, the _typeCache is populated with CACHED_NOT_FOUND 
for QName {http://quickstart.samples/xsd}EU-Address . So findTypeRef  will 
return null. This will result in the changeType() call to not return the 
derived type. (See call stack at the bottom.)

  In the local test program, the _typeCache was initially empty and was 
populated with the correct value at the end of findTypeRef call.

  The only way that CACHED_NOT_FOUND can be set for any QName type is 
when the following line in findTypeRef () return null.
SchemaTypeSystem ts = typeSystemForComponent("schema" + 
METADATA_PACKAGE_LOAD + "/type/", name);

  I have no idea why this typeSystemForComponent() could return null in 
service. Can someone help clarify the myth here? When I trace into the first 
incoming message, it indeed shows that the typeSystemForComponent return null!

  Below are the findTypeRef method and the call stack.

Thanks,
-Bo

public SchemaType.Ref findTypeRef(QName name)
{
/**
 * The maps are synchronized, we use two accesses to the cache 
(one read
 * and one write), but the code inbetween is not synchronized. 
The
 * assumption is that the underlying datastructures (the search 
path and
 * the classloader) do not change, so two threads running the 
code in
 * parallel will come up with the same result.
 */
Object cached = _typeCache.get(name);
if (cached == CACHED_NOT_FOUND)
return null; ==>exit here in bad one
   
SchemaType.Ref result = (SchemaType.Ref) cached;
if (result == null)
{
for (int i = 0; i < _searchPath.length; i++)
if (null != (result = _searchPath[i].findTypeRef(name)))
break;
if (result == null)
{
SchemaTypeSystem ts = typeSystemForComponent("schema" + 
METADATA_PACKAGE_LOAD + "/type/", name);
if (ts != null)
{
result = ts.findTypeRef(name);
assert(result != null) : "Type system registered 
type " + QNameHelper.pretty(name) + " but does not return it";
}
}
_typeCache.put(name, result == null ? CACHED_NOT_FOUND : 
result);
}
return result; ==>exit here in good case when the typeCache.put 
is call with good value.
}


Stack:
SchemaTypeLoaderImpl.findTypeRef(QName) line: 369   
SchemaTypeLoaderImpl(SchemaTypeLoaderBase).findType(Q

[jira] Updated: (AXIS2-1938) [axis2] WSDL2JAVA with XMLBean binding does not create instance of the derived type or ignore xsi:type in the xml

2007-01-17 Thread Bo Xie (JIRA)

 [ 
https://issues.apache.org/jira/browse/AXIS2-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bo Xie updated AXIS2-1938:
--

Attachment: StockQuoteServiceSkeleton.java

> [axis2] WSDL2JAVA with XMLBean binding does not create instance of the 
> derived type or ignore xsi:type in the xml
> -
>
> Key: AXIS2-1938
> URL: https://issues.apache.org/jira/browse/AXIS2-1938
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: databinding
>Affects Versions: 1.1
> Environment: Windows XP, tomcat 5.5, Axis2 1.1
>Reporter: Bo Xie
> Attachments: StockQuoteServiceSkeleton.java, XMLBeanBinding.zip
>
>
> There are basically two issues.
> 1. The java objects created does not use the xsi:type in the XML. In my case, 
> the xsi:type is for derived type, but the object created is still of base 
> type.
> 2. The XML string generated from the client side has the xsi:type for Address 
> object, so the service see it but did not generate the derived type according 
> to the xsi:type(this is the issue reported above). But the server side 
> generated XML string does not have the xsi:type for the objects, so the 
> object XML string does not have xsi:type when the message received on the 
> client side. Why the xsi:type is missing in this case? In both cases, I used 
> types derived from the Address type. The client and service code are based on 
> the XMLBean quickstart sample.
> Attached are 
> 1. the WSDL file. 
> 2.The build file that you can check if the WSDL2JAVA is proper for my case.
> 3. The client code
> 4. The server code.
> Below are the email exchange with Ajith Ranabahu.
> Subject: [axis2] WSDL2JAVA with XMLBean binding does not create instance of 
> the derived type
> 
> From: Bo Xie <[EMAIL PROTECTED]>
> To: axis-user@ws.apache.org
> Date: Tue, Jan 2, 2007 at 7:45 PM
> Hi there,
>   I am new to axis2 with XMLBean data binding, please help me with the 
> following issue.
>   I modified the quickstart sample XMLBean program to try a WSDL with the 
> following types. The type US-Address is a derived from type Address. I would 
> like to create a service operation updateAddresses to change addresses of a 
> company based on a symbol. The addresses is an array that can take either 
> Address or USAddress instances.
>   
> 
> 
> 
> 
> 
> 
>  
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
>  nillable="true"/>
>  maxOccurs="unbounded"/>
> 
> 
>   I used WSDL2JAVA with XMLBean data binding to generate the skeleton and 
> stub code. All looks great and the SOAP exchange looks fine too.
>   In the client code, I created one instance if USAddress and one 
> instance of Address and put them into the addresses list. In the SOAP request 
> message, the instances are as  shown as follows below. Note, xsi-type for the 
> instance indicate the correct types which is nice.
> 
> http://quickstart.samples/xsd";>
>   
> XYZ  
>  xmlns:xsd="
> http://quickstart.samples/xsd"; xsi:type="xsd:US-Address">
> company name
> Sunnyvale
> CA
> 94087
>
> xmlns:xsd="http://quickstart.samples/xsd
> " xsi:type="xsd:Address">
> company name
> Hong Kong
>
> 
>   
>The problem is when the XML object mapped into java object on the service 
> side, all the XML address object passed to the skeleton are all of Address 
> type. I would expect one instance be Address type, another be USAddress type. 
> Since xsi-type in the SOAP message has the right type, why the XMLBean object 
> is not created as the derived type? Is there any option in WSDL2JAVA to make 
> this work?
>From the XMLBean Address java object, how can I access the xsi-type 
> attribute that was available in the XML string?
>If I am not heading the right direction, can anyone suggest some 
> alternatives?
> Thanks for your time!
> -Bo
>  
> 
> From: Ajith Ranabahu <[EMAIL PROTECTED]>
> Reply-To: axis-user@ws.apache.org
> To: axis-user@ws.apache.org
> Date: Wed, Jan 3, 2007 at 5:16 AM
> Hi,
> The reason here is that you have set the type of the addresses element
> to be 'Address' rather than USAddress (the code generator would put
> the reference for the Address rather than the USAddress). However
> since the xsi:type at

[jira] Updated: (AXIS2-1938) [axis2] WSDL2JAVA with XMLBean binding does not create instance of the derived type or ignore xsi:type in the xml

2007-01-17 Thread Bo Xie (JIRA)

 [ 
https://issues.apache.org/jira/browse/AXIS2-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bo Xie updated AXIS2-1938:
--


I noticed that the same code behave differently when invoked standalone(from 
main()), or from the service.

>From standalone, the xsi:type are in the XML properly while from service, the 
>xsi:type attribute are missing. They are calling the same 
>method(populateAddress(), please see attached file 
>StockQuoteServiceSkeleton.java.

I am just wondering if there is any setting on the service side that may 
influence the generation of the xsi:type?

XML dump  when running from main().

http://quickstart.samples/xsd";>
http://www.w3.org/2001/XMLSchema-instance";>
Sunnyvale
XYZ
CA
94087

http://www.w3.org/2001/XMLSchema-instance";>
Hongkong
XYZ
2300331 E.C



XML dump when running as service
http://quickstart.samples/xsd";>

Sunnyvale
XYZ
CA
94087


Hongkong
XYZ
2300331 E.C




> [axis2] WSDL2JAVA with XMLBean binding does not create instance of the 
> derived type or ignore xsi:type in the xml
> -
>
> Key: AXIS2-1938
> URL: https://issues.apache.org/jira/browse/AXIS2-1938
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: databinding
>Affects Versions: 1.1
> Environment: Windows XP, tomcat 5.5, Axis2 1.1
>Reporter: Bo Xie
> Attachments: XMLBeanBinding.zip
>
>
> There are basically two issues.
> 1. The java objects created does not use the xsi:type in the XML. In my case, 
> the xsi:type is for derived type, but the object created is still of base 
> type.
> 2. The XML string generated from the client side has the xsi:type for Address 
> object, so the service see it but did not generate the derived type according 
> to the xsi:type(this is the issue reported above). But the server side 
> generated XML string does not have the xsi:type for the objects, so the 
> object XML string does not have xsi:type when the message received on the 
> client side. Why the xsi:type is missing in this case? In both cases, I used 
> types derived from the Address type. The client and service code are based on 
> the XMLBean quickstart sample.
> Attached are 
> 1. the WSDL file. 
> 2.The build file that you can check if the WSDL2JAVA is proper for my case.
> 3. The client code
> 4. The server code.
> Below are the email exchange with Ajith Ranabahu.
> Subject: [axis2] WSDL2JAVA with XMLBean binding does not create instance of 
> the derived type
> 
> From: Bo Xie <[EMAIL PROTECTED]>
> To: axis-user@ws.apache.org
> Date: Tue, Jan 2, 2007 at 7:45 PM
> Hi there,
>   I am new to axis2 with XMLBean data binding, please help me with the 
> following issue.
>   I modified the quickstart sample XMLBean program to try a WSDL with the 
> following types. The type US-Address is a derived from type Address. I would 
> like to create a service operation updateAddresses to change addresses of a 
> company based on a symbol. The addresses is an array that can take either 
> Address or USAddress instances.
>   
> 
> 
> 
> 
> 
> 
>  
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
>  nillable="true"/>
>  maxOccurs="unbounded"/>
> 
> 
>   I used WSDL2JAVA with XMLBean data binding to generate the skeleton and 
> stub code. All looks great and the SOAP exchange looks fine too.
>   In the client code, I created one instance if USAddress and one 
> instance of Address and put them into the addresses list. In the SOAP request 
> message, the instances are as  shown as follows below. Note, xsi-type for the 
> instance indicate the correct types which is nice.
> 
> http://quickstart.samples/xsd";>
>   
> XYZ  
>  xmlns:xsd="
> http://quickstart.samples/xsd"; xsi:type="xsd:US-Address">
> company name
> Sunnyvale
> CA
> 94087
>
> xmlns:xsd="http://quickstart.samples/xsd
> " xsi:type="xsd:Address">
> company name
> Hong Kong
>
> 
>   
>The problem is when the XML object mapped into java object on the service 
> side, all the XML address object passed to the skeleton are all of Address 
> type. I would expect one instance be Addres

[jira] Updated: (AXIS2-1938) [axis2] WSDL2JAVA with XMLBean binding does not create instance of the derived type or ignore xsi:type in the xml

2007-01-04 Thread Bo Xie (JIRA)

 [ 
https://issues.apache.org/jira/browse/AXIS2-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bo Xie updated AXIS2-1938:
--

Attachment: XMLBeanBinding.zip

> [axis2] WSDL2JAVA with XMLBean binding does not create instance of the 
> derived type or ignore xsi:type in the xml
> -
>
> Key: AXIS2-1938
> URL: https://issues.apache.org/jira/browse/AXIS2-1938
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: databinding
>Affects Versions: 1.1
> Environment: Windows XP, tomcat 5.5, Axis2 1.1
>Reporter: Bo Xie
> Attachments: XMLBeanBinding.zip
>
>
> There are basically two issues.
> 1. The java objects created does not use the xsi:type in the XML. In my case, 
> the xsi:type is for derived type, but the object created is still of base 
> type.
> 2. The XML string generated from the client side has the xsi:type for Address 
> object, so the service see it but did not generate the derived type according 
> to the xsi:type(this is the issue reported above). But the server side 
> generated XML string does not have the xsi:type for the objects, so the 
> object XML string does not have xsi:type when the message received on the 
> client side. Why the xsi:type is missing in this case? In both cases, I used 
> types derived from the Address type. The client and service code are based on 
> the XMLBean quickstart sample.
> Attached are 
> 1. the WSDL file. 
> 2.The build file that you can check if the WSDL2JAVA is proper for my case.
> 3. The client code
> 4. The server code.
> Below are the email exchange with Ajith Ranabahu.
> Subject: [axis2] WSDL2JAVA with XMLBean binding does not create instance of 
> the derived type
> 
> From: Bo Xie <[EMAIL PROTECTED]>
> To: axis-user@ws.apache.org
> Date: Tue, Jan 2, 2007 at 7:45 PM
> Hi there,
>   I am new to axis2 with XMLBean data binding, please help me with the 
> following issue.
>   I modified the quickstart sample XMLBean program to try a WSDL with the 
> following types. The type US-Address is a derived from type Address. I would 
> like to create a service operation updateAddresses to change addresses of a 
> company based on a symbol. The addresses is an array that can take either 
> Address or USAddress instances.
>   
> 
> 
> 
> 
> 
> 
>  
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
>  nillable="true"/>
>  maxOccurs="unbounded"/>
> 
> 
>   I used WSDL2JAVA with XMLBean data binding to generate the skeleton and 
> stub code. All looks great and the SOAP exchange looks fine too.
>   In the client code, I created one instance if USAddress and one 
> instance of Address and put them into the addresses list. In the SOAP request 
> message, the instances are as  shown as follows below. Note, xsi-type for the 
> instance indicate the correct types which is nice.
> 
> http://quickstart.samples/xsd";>
>   
> XYZ  
>  xmlns:xsd="
> http://quickstart.samples/xsd"; xsi:type="xsd:US-Address">
> company name
> Sunnyvale
> CA
> 94087
>
> xmlns:xsd="http://quickstart.samples/xsd
> " xsi:type="xsd:Address">
> company name
> Hong Kong
>
> 
>   
>The problem is when the XML object mapped into java object on the service 
> side, all the XML address object passed to the skeleton are all of Address 
> type. I would expect one instance be Address type, another be USAddress type. 
> Since xsi-type in the SOAP message has the right type, why the XMLBean object 
> is not created as the derived type? Is there any option in WSDL2JAVA to make 
> this work?
>From the XMLBean Address java object, how can I access the xsi-type 
> attribute that was available in the XML string?
>If I am not heading the right direction, can anyone suggest some 
> alternatives?
> Thanks for your time!
> -Bo
>  
> 
> From: Ajith Ranabahu <[EMAIL PROTECTED]>
> Reply-To: axis-user@ws.apache.org
> To: axis-user@ws.apache.org
> Date: Wed, Jan 3, 2007 at 5:16 AM
> Hi,
> The reason here is that you have set the type of the addresses element
> to be 'Address' rather than USAddress (the code generator would put
> the reference for the Address rather than the USAddress). However
> since the xsi:type attribute is present the deserializer should c

[jira] Created: (AXIS2-1938) [axis2] WSDL2JAVA with XMLBean binding does not create instance of the derived type or ignore xsi:type in the xml

2007-01-04 Thread Bo Xie (JIRA)
[axis2] WSDL2JAVA with XMLBean binding does not create instance of the derived 
type or ignore xsi:type in the xml
-

 Key: AXIS2-1938
 URL: https://issues.apache.org/jira/browse/AXIS2-1938
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: databinding
Affects Versions: 1.1
 Environment: Windows XP, tomcat 5.5, Axis2 1.1
Reporter: Bo Xie


There are basically two issues.
1. The java objects created does not use the xsi:type in the XML. In my case, 
the xsi:type is for derived type, but the object created is still of base type.
2. The XML string generated from the client side has the xsi:type for Address 
object, so the service see it but did not generate the derived type according 
to the xsi:type(this is the issue reported above). But the server side 
generated XML string does not have the xsi:type for the objects, so the object 
XML string does not have xsi:type when the message received on the client side. 
Why the xsi:type is missing in this case? In both cases, I used types derived 
from the Address type. The client and service code are based on the XMLBean 
quickstart sample.

Attached are 
1. the WSDL file. 
2.The build file that you can check if the WSDL2JAVA is proper for my case.
3. The client code
4. The server code.

Below are the email exchange with Ajith Ranabahu.
Subject: [axis2] WSDL2JAVA with XMLBean binding does not create instance of the 
derived type


From: Bo Xie <[EMAIL PROTECTED]>
To: axis-user@ws.apache.org
Date: Tue, Jan 2, 2007 at 7:45 PM

Hi there,

  I am new to axis2 with XMLBean data binding, please help me with the 
following issue.

  I modified the quickstart sample XMLBean program to try a WSDL with the 
following types. The type US-Address is a derived from type Address. I would 
like to create a service operation updateAddresses to change addresses of a 
company based on a symbol. The addresses is an array that can take either 
Address or USAddress instances.

  






 
   











 







  I used WSDL2JAVA with XMLBean data binding to generate the skeleton and 
stub code. All looks great and the SOAP exchange looks fine too.

  In the client code, I created one instance if USAddress and one instance 
of Address and put them into the addresses list. In the SOAP request message, 
the instances are as  shown as follows below. Note, xsi-type for the instance 
indicate the correct types which is nice.


http://quickstart.samples/xsd";>
  
XYZ  
http://quickstart.samples/xsd"; xsi:type="xsd:US-Address">
company name
Sunnyvale
CA

94087
   
   http://quickstart.samples/xsd
" xsi:type="xsd:Address">
company name
Hong Kong
   

  


   The problem is when the XML object mapped into java object on the service 
side, all the XML address object passed to the skeleton are all of Address 
type. I would expect one instance be Address type, another be USAddress type. 
Since xsi-type in the SOAP message has the right type, why the XMLBean object 
is not created as the derived type? Is there any option in WSDL2JAVA to make 
this work?

   From the XMLBean Address java object, how can I access the xsi-type 
attribute that was available in the XML string?

   If I am not heading the right direction, can anyone suggest some 
alternatives?

Thanks for your time!

-Bo
 



From: Ajith Ranabahu <[EMAIL PROTECTED]>
Reply-To: axis-user@ws.apache.org
To: axis-user@ws.apache.org
Date: Wed, Jan 3, 2007 at 5:16 AM

Hi,
The reason here is that you have set the type of the addresses element
to be 'Address' rather than USAddress (the code generator would put
the reference for the Address rather than the USAddress). However
since the xsi:type attribute is present the deserializer should create
the right object and you can just use a type cast to get to the right
object.

HTH

Ajith
[Quoted text hidden]
--
Ajith Ranabahu

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



From: Bo Xie <[EMAIL PROTECTED]>
Reply-To: axis-user@ws.apache.org
To: axis-user@ws.apache.org
Date: Wed, Jan 3, 2007 at 7:55 AM

Thanks Ajith for the quick response.

I have tried to use the instanceof to test if the instanc