RE: getting rid of ArrayOf in WSDL

2005-03-23 Thread aedemar . cooke
Title: RE: getting rid of ArrayOf in WSDL






Thanks Julian.


If they add the patch in the next release (as you requested) are the indexed accessors still required?


-Original Message-

From: WAJSBERG Julien RD-BIZZ [mailto:[EMAIL PROTECTED]]

Sent: 23 March 2005 9:51 

To: axis-user@ws.apache.org

Subject: Re: getting rid of ArrayOf in WSDL



try to use indexed accessors for queries in addition to normal accessors.

I mean :


getQueries(int i)

and

setQueries(int i, Query value)


see http://issues.apache.org/jira/browse/AXIS-1673 for more information



[EMAIL PROTECTED] a écrit :


> Sorry if this has been asked before...

>

> Is there anyway of using the Java2WSDL command to produce 

> wrapped/literal WSDL that does NOT create separate complex types for 

> Arrays.

>

> In other words, I would like to see

>

> 

> 

>  

>   

>    

>    

> type="tns10:Query"/>

>   

>  

> 

>    

>

>

> (as I cannot get ArrayOf version to work with .NET client)  instead of 

>

>    

> 

>  

> type="tns10:Query"/>

> 

>    

>

> .

>

> 

> 

>  

>   

>    

>    

> type="impl:ArrayOf_tns10_Query"/>

>   

>  

> 

>    

>

> 

>

> This e-mail may be privileged and/or confidential, and the sender does 

> not waive any related rights and obligations. Any distribution, use or 

> copying of this e-mail or the information it contains by other than an 

> intended recipient is unauthorized. If you received this e-mail in 

> error, please advise me (by return e-mail or otherwise) immediately.

>

> Ce courrier électronique est confidentiel et protégé. L'expéditeur ne 

> renonce pas aux droits et obligations qui s'y rapportent. Toute 

> diffusion, utilisation ou copie de ce message ou des renseignements 

> qu'il contient par une personne autre que le (les) destinataire(s) 

> désigné(s) est interdite. Si vous recevez ce courrier électronique par 

> erreur, veuillez m'en aviser immédiatement, par retour de courrier 

> électronique ou par un autre moyen.

>

> 

>






This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.




getting rid of ArrayOf in WSDL

2005-03-23 Thread aedemar . cooke
Title: getting rid of ArrayOf in WSDL






Sorry if this has been asked before...


Is there anyway of using the Java2WSDL command to produce wrapped/literal WSDL that does NOT create separate complex types for Arrays.

In other words, I would like to see 




    

 

  

   

   

  

 

    

   



(as I cannot get ArrayOf version to work with .NET client)  instead of  


   

    

 

    

   


.




    

 

  

   

   

  

 

    

   






This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.




RE: .NET and Axis

2005-03-18 Thread aedemar . cooke
Title: .NET and Axis



Hi 
Dino,
 
thanks 
for your suggestion but I have found that I can generate helper classes 
using --helperGen on the WSDL2Java command.  These helper classes contain 
the typeDesc code that Axis uses for it serialization.  BeanSer/Deser actually tries to load these _Helper classes if the 
getTypeDesc static method is not found is the X.class in order to get the 
TypeDesc.
 
I have 
found that I need to use a variation of the WSDL first approach as the axis 
generated WSDL contains ArrayOf elements which I cannot get to work with my .NET 
client.
 
But I can use my existing classes and a wrapped/literal service 
if I include the generated Helper classes and edit the WSDL as 
below.   
 
The 
steps I follow are therefore:
1. 
Java2WSDL
2. 
Edit the ArrayOf XML
3. 
WSDL2Java using --helperGen 
 
and it 
works.
 
Thanks 
for all your help.
 













gets 
changes to








 

  -Original Message-From: Dino Chiesa 
  [mailto:[EMAIL PROTECTED]Sent: 15 March 2005 2:19 
  To: Dino Chiesa; axis-user@ws.apache.orgCc: Cooke, 
  AedemarSubject: RE: .NET and Axis
  Aedmar, One last thing. . .
   
  If I take your inquiry.wsdl, and modify it, I 
  can generate a .NET client that accepts the response.xml that you 
  included previously.  
   
  The modifications are: 
   
  - collapse all  into a single 
  , 
  targetNamespace="http://inquiry.webservice.gpb.rbc.com"
  -  re-define tns3 and tns4 to be 
  "inquiry.webservice.gpb.rbc.com" rather than util... and customer 
  
   
  In other words, effectively I redefine all types used 
  in the wsdl to reside in a single namespace.  
  ("inquiry.blah.blah").  
   
  Then, the .NET client generated from such a WSDL can 
  consume the response document you sent out. 
   
  I don't feel quite right in doing this.  
  Effectively I have turned the contract on its head - I am writing the WSDL to 
  conform to the actual XML on the wire, rather than the other way 'round ("WSDL 
  First", which as you know is the One True Way to Interop Enlightenment).  
  
   
  But, on the other hand, WSDL is just a 
  tool, no?   Modifying the WSDL in this way may be completely 
  acceptable.  Of course, a better approach is to convince AXIS to 
  generate a WSDL like that, automatically.   How?  Just modify 
  the WSDD so that all your custom types (Code, BankIdentifier, 
  GPBException, etc) all reside in the same XMLNS, 
  "http://inquiry.webservice.gpb.rbc.com"
   
   
  Then, the auto-gen'd WSDL should reflect the XML on 
  the wire.  
   
  -Dino
   
   
  
  
  From: Dino Chiesa Sent: Tuesday, 
  March 15, 2005 7:59 AMTo: 
  'axis-user@ws.apache.org'Subject: RE: .NET and 
  Axis
  
  ahh, sorry, I don't know much about custom serializers 
  for AXIS, someone else maybe on the list can help you with that.  maybe 
  you need to restate the question (it has been a long-ish thread, and probably 
  lots of people tuned out). 
   
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 6:30 
  AMTo: axis-user@ws.apache.orgSubject: RE: .NET and 
  Axis
  
  Hi 
  Dino,
   
  you can get it working because you are using the Axis generated 
  Java beans which contains class specific Serializer and Deserializer 
  code.
   
  If I cut and paste the Axis 
  generated Serializer and Deserializer code into my existing classes it 
  works aswell. 
   
  Thanks to you I have recognised the problem, i.e., 
  that using the de/serializers specified in the server-config.wsdd file creates 
  name space issues.
   
  
  
  Any idea how I can continue to use my preexisting 
  Java classes (and there are a lot of them) without having to cut and paste the 
  de/serializer code into each of 
  them?
   
  
  Example of Axis generated 
  Serializer and Deserializer code 
  
  private static org.apache.axis.description.TypeDesc typeDesc 
  =
  new 
  org.apache.axis.description.TypeDesc(BankIdentifier.class, true);
  static 
  {
  typeDesc.setXmlType(new javax.xml.namespace.QName("http://util.gpb.rbc.com", "BankIdentifier"));
  org.apache.axis.description.ElementDesc elemField = 
  new 
  org.apache.axis.description.ElementDesc();
  elemField.setFieldName("bank");
  elemField.setXmlName(new javax.xml.namespace.QName("http://util.gpb.rbc.com", "bank"));
  elemField.setXmlType(new javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "int"));
  typeDesc.addFieldDesc(elemField);
  elemField = new 
  org.apache.axis.description.ElementDesc();
  elemField.setFieldName("transit");
  elemField.setXmlName(new javax.xml.namespace.QName("http://util.gpb.rbc.com", "transit"));
  elemField.setXmlType(new javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "int"));
  typeDesc.addFieldDesc(elemField);
  elemField = new 
  org.apache.axis.description.ElementDesc();
  elemField.setFieldName("key");
  elemField.setXmlName(new javax.xml.namespace.QName("http://util.gpb.rbc.com", "key"));
  elemField.setXmlType(new javax.xml.names

RE: is it possible to change soapenc:string to xsd:string in generated WSDL?

2005-03-15 Thread aedemar . cooke
Title: RE: is it possible to change soapenc:string to xsd:string in generated WSDL?



I 
couldn't get it to work either - that's why I said "They say" :)  - 
 but I haven't had time to do a lot of research into 
it.

  -Original Message-From: Merten Schumann 
  [mailto:[EMAIL PROTECTED]Sent: 15 March 2005 5:03 
  To: axis-user@ws.apache.orgSubject: RE: is it possible 
  to change soapenc:string to xsd:string in generated WSDL?
  Wow, aedemar, thank you, that looks exactly like what I 
  need. Tried it with 1.2RC3, but seems to have no effect, there are still these 
  soapenc:string beasts in the generated WSDL ... Will continue my tries 
  ...
   
  cu
     Merten
  


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 5:51 
PMTo: axis-user@ws.apache.orgSubject: RE: is it 
possible to change soapenc:string to xsd:string in generated 
WSDL?

see http://issues.apache.org/jira/browse/AXIS-1834. 

They say it can be solved with by adding the new 
"dotNetSoapEncFix" flag in your server-config.wsdd's globalConfiguration 
section. Axis documentation has more info. 
-Original Message- From: 
Merten Schumann [mailto:[EMAIL PROTECTED]] 
Sent: 15 March 2005 4:46 To: 
axis-user@ws.apache.org Subject: is it possible to 
change soapenc:string to xsd:string in generated 
WSDL? 
Hello, 
when testing my web service (Axis 1.2RC3) with MS 
SOAPToolkit 3.0 I found that it's not working 
obviously due to this soapenc:string encodings 
instead of xsd:string. I found some cries for help regarding 
this interop issue in the web, but no solution as far as I 
could see. Maybe you've seen this message from 
MSSoapInit too "SoapMapper for element string could 
not be created". 
I could try to hand over my own WSDL file (created with 
Sun's wscompile from J2EE stuff) to the WSDD deploy 
step, but I guess Axis will not accept it or 
so. 
My Perl and Python clients work fine. Some .NET stuff too. 
But I need this MS SOAPToolkit stuff (to use the 
Axis powered web service from VBA in MS Office 
documents). I think it's a problem in the SOAPToolkit, not in Axis, but the SOAPToolkit is there and will not be 
changed/supported in the future ... 
For boolean, Axis is using xsd:boolean. Is there a way to 
let Axis create xsd:string elements? 
Thanx a lot!    
Merten 
This 
e-mail may be privileged and/or confidential, and the sender does not waive 
any related rights and obligations. Any distribution, use or copying of this 
e-mail or the information it contains by other than an intended recipient is 
unauthorized. If you received this e-mail in error, please advise me (by 
return e-mail or otherwise) immediately. Ce courrier électronique 
est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et 
obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce 
message ou des renseignements qu'il contient par une personne autre que le 
(les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier 
électronique par erreur, veuillez m'en aviser immédiatement, par retour de 
courrier électronique ou par un autre 
moyen.



This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.

 

RE: is it possible to change soapenc:string to xsd:string in generated WSDL?

2005-03-15 Thread aedemar . cooke
Title: RE: is it possible to change soapenc:string to xsd:string in generated WSDL?






see http://issues.apache.org/jira/browse/AXIS-1834.


They say it can be solved with by adding the new "dotNetSoapEncFix" flag in your server-config.wsdd's globalConfiguration section. Axis documentation has more info. 

-Original Message-

From: Merten Schumann [mailto:[EMAIL PROTECTED]]

Sent: 15 March 2005 4:46 

To: axis-user@ws.apache.org

Subject: is it possible to change soapenc:string to xsd:string in

generated WSDL?



Hello,


when testing my web service (Axis 1.2RC3) with MS SOAPToolkit 3.0 I

found that it's not working obviously due to this soapenc:string

encodings instead of xsd:string. I found some cries for help regarding

this interop issue in the web, but no solution as far as I could see.

Maybe you've seen this message from MSSoapInit too "SoapMapper for

element string could not be created".


I could try to hand over my own WSDL file (created with Sun's wscompile

from J2EE stuff) to the WSDD deploy step, but I guess Axis will not

accept it or so.


My Perl and Python clients work fine. Some .NET stuff too. But I need

this MS SOAPToolkit stuff (to use the Axis powered web service from VBA

in MS Office documents). I think it's a problem in the SOAPToolkit, not

in Axis, but the SOAPToolkit is there and will not be changed/supported

in the future ...


For boolean, Axis is using xsd:boolean. Is there a way to let Axis

create xsd:string elements?


Thanx a lot!

   Merten





This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.



Custom De/Serializers and Wrapped/Literal Axis services

2005-03-15 Thread aedemar . cooke
Title: Custom De/Serializers and Wrapped/Literal Axis services






This is a follow on from the mail I posted with subject .NET and Axis. 


I am experiencing Serialization problems when exposing my service as Wrapped/Literal.  I don't have these problems with rpc/encoded.

Axis generates customer serialization code in the JavaBean classes which is fine, but if I don't use these Axis generated classes but use my own simple JavaBean classes containing no custom serialization code, there are namespace issues in the XML - see Soap Envelopes below and attached WSDL.  

Notice that in the example using the custom serializer the getCustomerReturn is in the  namespace, as the WSDL specifies, and the child elements of that element are all in the  namespace, again, as the WSDL specifies.  However in the example where the custom serializer is not used, the child elements of getCustomerReturn do not specify a namespace so will be in the namespace of their parent, , which is incorrect. .

 <> 

As I said I didn't have to use the custom serialization code for my rpc/encoded service but could just specify the org.apache.axis.encoding.ser.BeanDe/SerializerFactory as the de/serializer in the server-config.wsdd as shown below 

http://util.gpb.rbc.com"/>

http://util.gpb.rbc.com"/>

I would like help on how I can continue to use my existing Java classes (and there are a lot of them) without having to cut and paste the de/serializer code into each of them.

The Soap Envelope for the two scenarios are below...

//Not using custom serializer

http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">http://inquiry.webservice.gpb.rbc.com">falsefalsefalse11880117Test Name

//using custom serializer

http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">http://inquiry.webservice.gpb.rbc.com">http://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com">falsehttp://customer.util.gpb.rbc.com">Bankrupthttp://customer.util.gpb.rbc.com">falsehttp://customer.util.gpb.rbc.com">http://util.gpb.rbc.com">1http://util.gpb.rbc.com">1880http://util.gpb.rbc.com"/>http://util.gpb.rbc.com">117http://customer.util.gpb.rbc.com">falsehttp://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com">Inactivehttp://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com">2005-03-15T13:53:33.873Zhttp://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com">2005-03-15T13:53:33.873Zhttp://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com"/>http://customer.util.gpb.rbc.com">Test Name





This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.

 

inquiry.wsdl
Description: inquiry.wsdl


RE: .NET and Axis

2005-03-15 Thread aedemar . cooke
Title: .NET and Axis



Hi 
Dino,
 
you can get it working because you are using the Axis generated 
Java beans which contains class specific Serializer and Deserializer 
code.
 
If I cut and paste the Axis 
generated Serializer and Deserializer code into my existing classes it 
works aswell. 
 
Thanks to you I have recognised the problem, i.e., that 
using the de/serializers specified in the server-config.wsdd file creates name 
space issues.
 


Any 
idea how I can continue to use my preexisting Java classes (and there are a lot 
of them) without having to cut and paste the de/serializer code into each of 
them?
 

Example of Axis generated 
Serializer and Deserializer code 

private static org.apache.axis.description.TypeDesc typeDesc =
new 
org.apache.axis.description.TypeDesc(BankIdentifier.class, true);
static 
{
typeDesc.setXmlType(new javax.xml.namespace.QName("http://util.gpb.rbc.com", "BankIdentifier"));
org.apache.axis.description.ElementDesc 
elemField = new 
org.apache.axis.description.ElementDesc();
elemField.setFieldName("bank");
elemField.setXmlName(new javax.xml.namespace.QName("http://util.gpb.rbc.com", "bank"));
elemField.setXmlType(new javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "int"));
typeDesc.addFieldDesc(elemField);
elemField = new 
org.apache.axis.description.ElementDesc();
elemField.setFieldName("transit");
elemField.setXmlName(new javax.xml.namespace.QName("http://util.gpb.rbc.com", "transit"));
elemField.setXmlType(new javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "int"));
typeDesc.addFieldDesc(elemField);
elemField = new 
org.apache.axis.description.ElementDesc();
elemField.setFieldName("key");
elemField.setXmlName(new javax.xml.namespace.QName("http://util.gpb.rbc.com", "key"));
elemField.setXmlType(new javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "string"));
elemField.setNillable(true);
typeDesc.addFieldDesc(elemField);
elemField = new 
org.apache.axis.description.ElementDesc();
elemField.setFieldName("number");
elemField.setXmlName(new javax.xml.namespace.QName("http://util.gpb.rbc.com", "number"));
elemField.setXmlType(new javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "int"));
typeDesc.addFieldDesc(elemField);
}
/**
* Return type metadata object
*/
public static 
org.apache.axis.description.TypeDesc getTypeDesc() {
return 
typeDesc;
}
/**
* Get Custom Serializer
*/
public static 
org.apache.axis.encoding.Serializer getSerializer(
java.lang.String mechType, 

java.lang.Class _javaType, 

javax.xml.namespace.QName _xmlType) 
{
return 

new 
org.apache.axis.encoding.ser.BeanSerializer(
_javaType, _xmlType, 
typeDesc);
}
/**
* Get Custom Deserializer
*/
public static 
org.apache.axis.encoding.Deserializer 
getDeserializer(
java.lang.String mechType, 

java.lang.Class _javaType, 

javax.xml.namespace.QName _xmlType) 
{
return 

new 
org.apache.axis.encoding.ser.BeanDeserializer(
_javaType, _xmlType, 
typeDesc);
}



This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.




RE: .NET and Axis

2005-03-14 Thread aedemar . cooke
Title: .NET and Axis



Thanks 
again Dino.  I have replied below.

  -Original Message-From: Dino Chiesa 
  [mailto:[EMAIL PROTECTED]Sent: 14 March 2005 3:27 
  To: axis-user@ws.apache.orgSubject: RE: .NET and 
  Axis
  hmm, some questions
  your steps are:
   
  1. java2wsdl 
  (as I have a fully functional web application currently exposed using 
  rpc/encoded)
  2. wsdl2java 
  3. deploy using deploy.wsdd
  4. generate c# code from wsdl
  5. invoke from c# web app
   
   
  
  can you explain a bit more about 
  that first step?  What do you mean "I have a fully 
  functional web application currently exposed using 
  rpc/encoded"?  How is that relevant 
  here?   What do 
  you do with the WSDL returned from that step?   
  I was just explaining that I use the Java 2 wsdl 
  approach not the wsdl FIRST approach as the java classes already exist.  
  
   
  Looking at your WSDL, I would remove the ArrayOf_tns2_Message and 
  replace it with an maxOccurs="unbounded" 
   
  eg remove 
     
  and replace with
     
  and also 
  remove 
     
      
       
     
  
  ... but that should 
  not affect interop at all, only the server-side (Java) programming 
  model.  
  Had already 
  tried that to see if it would make any difference but it didn't... (as 
  you said)  The wsdl is auto 
  generated. 
   
  you wrote:
  > The main difference I can see between your service and 
  mine is that there are type mappings for the getX and getXResponse elements, 
  do you know why this is?
   
  I don't 
  understand this.  I don't have type mappings for the getX and 
  getXResponse in the deploy.wsdd that is generated for the ComplexTypes 
  web service example.  And, if I run WSDL2Java on your inquiry.wsdl, I 
  again do not get type mappings for getX and getXResponse in the 
  deploy.wsdd.   I do get type mappings for all the complex types 
  (Code, Message, etc).   Maybe you could explain what you mean 
  in more detail?  Which one has type mappings, and which does not?  
  and where do you find these type 
  mappings? 
  If you look in the deploy.wsdd that 
  I attached with the last mail you should see a typeMapping for 
  getCustomerResonse (X = Customer). Are you saying you don't get these 
  typeMappings when you run WSDL2Java on my inquiry.wsdl?  Any idea why 
  that is? 
   
  
  
  xmlns:ns="http://inquiry.webservice.gpb.rbc.com"
  qname="ns:>getCustomerResponse"
  type="java:com.rbc.gpb.webservice.inquiry.GetCustomerResponse"
  serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
  deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
  encodingStyle=""
  />
   
  I'll have more time to look at this 
  later. . . 
  Thanks - I am ready to give up and stick 
  to my rpc/encoded service 
  :)
   
  
   


This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.



RE: .NET and Axis

2005-03-11 Thread aedemar . cooke
Title: .NET and Axis



Hi 
Dino,
 
thanks 
for taking the time to reply in such detail..
 
I am 
not sure whether we completely understand each other, so just to make sure 
I will explain what approaches I have tried.
 
I have started with a Java class (field names in camelCase), 
generated the WSDL (element names in camelCase) and generated the c# code 
from that (field name in camelCase).
 
I have 
also tried the WSDL first approach using element names in 
camelCase.
 
Both 
cases I get the same problem, i.e., when I query the c# object for the 
stringValue there it is an empty string although I can see that Axis has sent 
the correct XML
 
Aedemar42005-03-09T15:34:35.573Z2005-03-09T15:34:35.573Z1.0http://rbc.com">AedemarstringValue>> 
 
Java code
 

public class MyComplexType implements 
java.io.Serializable {
private java.lang.String 
stringValue;/**

* Gets the stringValue value for this MyComplexType.
* 
* @return stringValue
*/
public java.lang.String getStringValue() {
return stringValue;
}
 
/**
* Sets the stringValue value for this MyComplexType.
* 
* @param stringValue
*/
public void setStringValue(java.lang.String stringValue) 
{
this.stringValue = stringValue;
}
}
 
generated WSDL
 






 
 generated c#
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://rbc.com")]
public class 
MyComplexType {

/// 
[System.Xml.Serialization.XmlElementAttribute(IsNullable=true)]
public string stringValue;

}
 
 
 -Original Message-From: 
Dino Chiesa [mailto:[EMAIL PROTECTED]Sent: 11 March 2005 5:26 
To: axis-user@ws.apache.orgSubject: RE: .NET and 
Axis

  Your understanding is not quite right, but first let's 
  deal with the issue you are having.  
   
  you wrote: 
  > I don't want 
  to use the Axis generated classes for the reasons specified above, but do I 
  have any choice if I want to go to 
  wrapped/literal? 
   
  
  Yes, you have a choice.   You can specify 
  in-line code attributes on your .NET types to map element names to fields or 
  properties.   So you can tell .NET that a  
  element should get mapped to a field named StringValue.  Like this: 
  
   
   [XmlType(Namespace="urn:ionic.webservices.2005.03.Types")] 
      public class 
  MyComplexType { 
  [XmlElement("stringValue", IsNullable=true)]     public 
  string StringValue; 
  ...
      
  }
   
  
  By default .NET assumes the element name in the 
  XML is exactly the same as the field (or property name) in the .NET 
  class.  But you can specify any mapping you like. 
   
  Ok, now, getting back 
  to your issue.  you wrote:
  > 
  in order to use a 
  wrapped/literal service to send data between .NET and Axis, the Java Bean 
  property names need to start with an UPPER case character in the XML.  
  
   
  
  
  Considering what I wrote above, this is obviously not 
  true.  A better statement is, "the mapping on the server side 
  between JavaBean property name and XML element name,  must agree with the 
  mapping on the client side between XML element name and .NET field or 
  property." 
   
  In other words, if on the AXIS side you map a JavaBean property 
  named "foo" to an xml element name of , then you have to insure 
  that on the .NET side,  maps to the appropriate property or 
  field in your type.  And for those of you who care, that property or 
  field name on the .NET side certainly does not have to be "foo", it can be any 
  legal property name.  All I am saying is, the mapping has to be 
  consistent.  Let
    A = Java bean property name
    B = element name
    C = .NET property or field name
   
  then A maps to B, and B maps to C. 
   
  It sounds complicated, and that is why we rely on WSDL and tools 
  such as WSDL2Java and wsdl.exe to ensure these mappings agree.   And 
  in general, if you use the tools to generate code, what you get is 
  A=B=C.  This keeps it simple.  
   
  
  By trying to avoid half of the WSDL-to-sourcecode dance, so that 
  you can use your pre-existing types, you violate The First Law of 
  Webservices interop ("start with WSDL 
  first").   This is causing 
   
   A maps to B  and C maps to D.  
  
   
  where
   B = 
  and 
  C= 
   
  they are not the same!   Ne'er the twain shall 
  meet. 
   
  I am guessing that you have a WSDL, and you have an independent, 
  pre-existing set of Java types.  You might think they agree with 
  each other, but but they apparently do not.  If you then generate a .NET 
  client proxy from the WSDL, and then try to marry that client-side proxy to 
  the AXIS Service, it won't work.   
   
  But you can still get things to work, even if you do start with 
  Java first.  (Don't tell anyone I told you this.)  It just takes 
  more work on your part, and more understanding of the XML the various 
  webservices stacks generate.  Roll up your sleeves.     
  
   
  For simple cases, you can actually start with Java code, and 
  generate WSDL from it, and then generate VB or C# code from tha

.NET and Axis

2005-03-09 Thread aedemar . cooke
Title: .NET and Axis






Hi,


I have posted emails on this topic before but have never really understood the problem I was experiencing until now. Sorry for any misleading mails up to this point. I also apologise in advance for the length of this mail.  Hopefully people can understand what I am getting at!

The problem (as I now understand it) is that in order to use a wrapped/literal service to send data between .NET and Axis, the Java Bean property names need to start with an UPPER case character in the XML.  

Easier to explain with code I think


The Java Bean class can have the property name in lower case, e.g., stringValue


private java.lang.String stringValue;


but must serialise it to start with an upper case character, e.g., StringValue


org.apache.axis.description.ElementDesc elemField = new org.apache.axis.description.ElementDesc();

    elemField.setFieldName("stringValue");

    elemField.setXmlName(new javax.xml.namespace.QName("urn:ionic.webservices.2005.03.Types", "StringValue"));

    elemField.setXmlType(new javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "string"));

    elemField.setNillable(true);

    typeDesc.addFieldDesc(elemField);


so that the c# class has properties that start with upper case, e.g., StringValue not stringValue


[System.Xml.Serialization.XmlTypeAttribute(Namespace="urn:ionic.webservices.2005.03.Types")]

    public class MyComplexType {

    

    /// 

    [System.Xml.Serialization.XmlElementAttribute(IsNullable=true)]

    public string StringValue;

    

    /// 

    public int IntValue;

    

    /// 

    public System.DateTime DateTimeValue;

    

    /// 

    public System.DateTime Created;

    

    /// 

    public System.Single FloatValue;

    

    /// 

    [System.Xml.Serialization.XmlElementAttribute("ChildObjects", IsNullable=true)]

    public MyComplexType[] ChildObjects;

    }


If I don't include the Axis generated Custom Serializer and Deserializer in my classes (coz I have tons of existing classes that have lots of comments in them and existed before I needed to expose my application using web services), Axis uses org.apache.axis.encoding.ser.BeanDeserializerFactory for the serialization which means that the c# properties are generated with the same case as the Java class, i.e., starting with a lower case letter, and the data is not serialized correctly. 

For example, if the following code is executed from a .NET client


CTSOAP service = new CTSOAP();


MyComplexType type = service.getComplexType("caller");


type is not null but type.stringValue is an empty string.


If I use the Axis generated classes, then the properties are serialized and deserialized using properties where the first character is Upper case and this solves the problem.

I don't want to use the Axis generated classes for the reasons specified above, but do I have any choice if I want to go to wrapped/literal?  

This problem does not exist for rpc/encoded. 


Any comments would be appreciated.





This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.



RE: ?wsdl

2005-02-24 Thread aedemar . cooke
Title: ?wsdl




The 
namespace declarations are
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/ 

xmlns:xsd=http://www.w3.org/2001/XMLSchema
 

  -Original Message-From: Eugene Shershnev 
  [mailto:[EMAIL PROTECTED]Sent: 24 February 2005 3:54 To: 
  axis-user@ws.apache.orgSubject: Re: ?wsdl
  Just a note, it does not matter what is the namespace prefix 
  - xsd or soapenc.
  Both are just "shortcuts" to a namespace. If the "value" of 
  both is the same, the 2 XML fragments below are identical from parser's point 
  of view.
   
  So, just to complete your question you may want to post 
  declarations of those 2 namespaces.
  
- Original Message - 
From: 
[EMAIL PROTECTED] 
To: axis-user@ws.apache.org 
Sent: Wednesday, February 23, 2005 
8:18a
Subject: ?wsdl

does anyone know why the WSDL generated with ? at 
the end of the service URL is different from the WSDL generated using org.apache.axis.wsdl.Java2WSDL when working with 
rpc/encoded services? 
The main difference seems 
to be in the definition of the simple types as the Java2WSDL version 
defines the base type as xsd:string but the dynamic 
version defines it as soapenc:string.
This problem seems to have been 
introduced in Axis1.2RC2 as the dynamically generated wsdl running under 
Axis1.1 defines the base type as xsd:string. 
Example:- Java2WSDL version   base="xsd:string"> 
 
type="xsd:string"/>   
Axis1.2RC2 
automatically generated service description ?wsdl   
   
This 
e-mail may be privileged and/or confidential, and the sender does not waive 
any related rights and obligations. Any distribution, use or copying of this 
e-mail or the information it contains by other than an intended recipient is 
unauthorized. If you received this e-mail in error, please advise me (by 
return e-mail or otherwise) immediately. Ce courrier électronique 
est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et 
obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce 
message ou des renseignements qu'il contient par une personne autre que le 
(les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier 
électronique par erreur, veuillez m'en aviser immédiatement, par retour de 
courrier électronique ou par un autre 
moyen.


This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.



?wsdl

2005-02-23 Thread aedemar . cooke
Title: ?wsdl






does anyone know why the WSDL generated with ? at the end of the service URL is different from the WSDL generated using org.apache.axis.wsdl.Java2WSDL when working with rpc/encoded services? 

The main difference seems to be in the definition of the simple types as the Java2WSDL version defines the base type as xsd:string but the dynamic version defines it as soapenc:string.

This problem seems to have been introduced in Axis1.2RC2 as the dynamically generated wsdl running under Axis1.1 defines the base type as xsd:string. 

Example:-

Java2WSDL version 



 base="xsd:string">

























 type="xsd:string"/>






Axis1.2RC2 automatically generated service description ?wsdl 



soapenc:string">

























soapenc:string"/>










This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.




RE: import namespace

2005-02-23 Thread aedemar . cooke
Title: import namespace



Yes, I 
could use the workaround but that doesn't explain why it is happening. I 
prefer to use the dynamic wsdl as this typically means that clients are sure 
they are looking at the most up-to-date version of the service.  
Introducing a static file increases the possibility of 
errors.
 
I have compared the Java2WSDL static version against the version 
generated by the AdminService and the main difference is that the static version 
defines the base type as xsd:string but the dynamic version defines it as 
soapenc:string
 
I have 
tried converting my service to Wrapped/Document literal using Axis1.2 but 
it doesn't work for my service -  I am hoping Axis1.3 (http://issues.apache.org/jira/browse/AXIS-1547) 
resolves the issues with it.
 
 
Java2WSDL version
 


 
base="xsd:string">












type="xsd:string"/>


 
Axis1.2RC2 automatically 
generated service description Inquiry?wsdl


















 
 



This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.




import namespace

2005-02-21 Thread aedemar . cooke
Title: import namespace






Is there any way of configuring Axis so that the dynamic wsdl generation (http://hostname/WebProject/services//ServiceName?wsdl) does not import my package names as namespaces?

When I add a web reference to a .NET client using the wsdl containing the imports, the .NET code that is generated treats my classes as strings.

public abstract class Query {

    

    /// 

    public string matchCriteria;

    

    /// 

    public string queryValue;

    }


If I add a web reference to a static file (where I have commented out the import statements), the correct classes are created for my classes.

 public abstract class Query {

    

    /// 

    public MatchCriteria matchCriteria;

    

    /// 

    public string queryValue;

    }


extract from wsdl that works



http://xml.apache.org/xml-soap" xmlns:impl="urn:Inquiry" xmlns:intf="urn:Inquiry" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns10="http://account.util.gpb.rbc.com" xmlns:tns11="http://user.util.gpb.rbc.com" xmlns:tns12="http://portfolio.util.gpb.rbc.com" xmlns:tns13="http://fundHolding.util.gpb.rbc.com" xmlns:tns2="http://search.fundHolding.util.gpb.rbc.com" xmlns:tns3="http://search.util.gpb.rbc.com" xmlns:tns4="http://util.gpb.rbc.com" xmlns:tns5="http://lang.java" xmlns:tns6="http://search.portfolio.util.gpb.rbc.com" xmlns:tns7="http://customer.util.gpb.rbc.com" xmlns:tns8="http://search.account.util.gpb.rbc.com" xmlns:tns9="http://search.customer.util.gpb.rbc.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">



 

  http://search.util.gpb.rbc.com" xmlns="http://www.w3.org/2001/XMLSchema">

   http://schemas.xmlsoap.org/soap/encoding/"/>

   

    

 

 

 

 

 

 

 

    

   

   ...



extract from wsdl that doesn't work

http://xml.apache.org/xml-soap" xmlns:impl="urn:Inquiry" xmlns:intf="urn:Inquiry" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns10="http://account.util.gpb.rbc.com" xmlns:tns11="http://user.util.gpb.rbc.com" xmlns:tns12="http://portfolio.util.gpb.rbc.com" xmlns:tns13="http://fundHolding.util.gpb.rbc.com" xmlns:tns2="http://search.fundHolding.util.gpb.rbc.com" xmlns:tns3="http://search.util.gpb.rbc.com" xmlns:tns4="http://util.gpb.rbc.com" xmlns:tns5="http://lang.java" xmlns:tns6="http://search.portfolio.util.gpb.rbc.com" xmlns:tns7="http://customer.util.gpb.rbc.com" xmlns:tns8="http://search.account.util.gpb.rbc.com" xmlns:tns9="http://search.customer.util.gpb.rbc.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">



 

  http://search.util.gpb.rbc.com" xmlns="http://www.w3.org/2001/XMLSchema">

   http://account.util.gpb.rbc.com"/>

   http://lang.java"/>

   http://search.fundHolding.util.gpb.rbc.com"/>

   http://portfolio.util.gpb.rbc.com"/>

   http://util.gpb.rbc.com"/>

   http://search.customer.util.gpb.rbc.com"/>

   http://user.util.gpb.rbc.com"/>

   http://search.portfolio.util.gpb.rbc.com"/>

   

   http://fundHolding.util.gpb.rbc.com"/>

   http://customer.util.gpb.rbc.com"/>

   http://search.account.util.gpb.rbc.com"/>

   http://schemas.xmlsoap.org/soap/encoding/"/>

   

    

 

 

 

 

 

 

 

    

   

   ...








This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. 

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.