Re: How to not send nillable=true for null elements in a SOAP message

[Tim R J Langford]

Hello All,

Is it a bug in Axis1.3 that WSDL with nillable=false and 
minOccurs=0, still genrates a nilable=true string on serialisation? 
Is there somewhere I can log this bug or enhancement?


I may be able to do this in work time. Where would I start with Axis1.3 
to add/alter the code to deal with this? WSDL2Java mainly generates 
beans and a few other files. How would the code to analyse the presence 
of nillable=true in the schema and the unmarshalling of message 
objects fit together in the axis framework? some sort of variable set in 
the beans to indicate nillable should not be sent that is inspected on 
serilaisation; or some extracted supporting object that contains such 
information? Would this be a fairly simple task?


Thanks for you time,

Tim

Re: How to not send nillable=true for null elements in a SOAP message

[Tim R J Langford]

Thanks Kasi,

OK I am trying thsi approach now as it si my final option.

I have created a handler class that extend BasicHandler and have 
attached it to my outgoing Request SimpleChain in my 
EngineConfiguration. I can grab the message context and display it as a 
string. I also have access to the DOM and the various RPC elements, but 
it is becoming fairly complicated and bespoke to try and remove these 
nil elements. Is there any simple way of getting the string, processing 
it to remove the elements and setting my desired string back again at 
this level?


Thanks for your time,

Tim



Kasi, Anand wrote:


Write up a response flow handler that gets the response message from the
MessageContext object and removes the xsi:nil = true elements.


-Original Message-
From: Tim R J Langford [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 15, 2006 9:42 AM

To: axis-user@ws.apache.org
Subject: Re: How to not send nillable=true for null elements in a SOAP
message

Hello All,

I am still trying to remove 'nil=true' elements from my messages sent 
out by axis. I have modified the wsdl in elements where I want axis not 
to send these strings (i.e: have a blank element) as follows :


element name=sendNothingIfNull nillable=true type=xsd:string/

to :

element name=sendNothingIfNull nillable=false minOccurs=0 
type=xsd:string/


so that instead of sending :

someXML
   sendNothingIfNull xsi:type=xsd:string xsi:nil=true/
/someXML

I send something like :

someXML/someXML


I have tried a few other methods (such as the one Rod suggested not 
specifying nillable at all in the schema and setting minOccurs=0) 
but axis keeps sending these elements as nillable. Should this work or 
am I making a mistake somwhere?


It may be PEBCAK but I just cant get axis1.3  to exhibit the behavior 
the server expects. Is there any other lower level method in axis to 
deal with this? (I traced the code calls down to the HTTP sender class 
but even at this level there is no easy access to the string as it is 
being passed by chunk encoded HTTP - and of course in some cases the 
server we are trying to attach too actually wants us to send these 
nillable=true elements so this approach is not suitable).


I know I must have exhausted all you guys by now! Sorry, and thanks.


Tim

PS: I am generating the axis code form the wsdl using the following ant 
task configuration :


   axis-wsdl2java
 output=${src.dir}
 deployScope=Application
 verbose=true
 serverSide=true
wrapArrays=true
 url=eurostar_hack2.wsdl   
   /axis-wsdl2java








Rodrigo Ruiz wrote:

 

By what you describe, I think you should add minOccurs='0' and remove 
nillable='true'


Regards,
Rodrigo Ruiz

Tim R J Langford wrote:

   


Thanks Anne,

Thats what I thought. Unfortunatly our provider does not seem too 
clued up on their tech, and the wsdl does not allow minOccurs=0.  I
 



 

guess I will have to update our automated build process to fix their 
schema before generating my soap beans and classes. The best way to 
do this would be by adding minOccurs=0 to the faulty elements I 
presume?


Thanks to everybody for their time,

Tim


Anne Thomas Manes wrote:

 

If the service cannot accept xsi:nil=true then the service 
provider should adjust the schema accordingly. Does the schema allow
   



 

minOccurs=0? If not, then there's no valid way to send no element 
instead of xsi:nil=true.


Anne

On 2/14/06, *Tim R J Langford* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:



   Hi Jeff,

   Thanks for your response.

   Sorry for being unclear. Yes you are correct. I am sending
   'xsi:nil=true' and I want to configure axis to send  nothing 
instead

   of this string.  e.g : *

   XXX* xsi:type=xsd:string xsi:nil=true/*
   YYY* xsi:type=zzz:YYY xsi:nil=true xmlns:zzz=KKK*/

   *I think Axis 1.2 did it this way? Is there anyway of
   


configuring
 


   Axis
   1.3 to not send these 'xsi:nil=true' elements?

   Thanks for you time,

   Tim


   PS: The service wsdl does have  'xsd:nillable=true' elements 
in the
   message schema, but their system cannot actually handle the 
situation
   where it is null (even if they return it in a response), and 
they have
   asked us to remove the 'xsi:nil=true' elements from our 
requests. We

   could fix the wsdl schema, but this would impede our codegen
   system as
   we are the client, so were wondering if there was a way to do it
   



 


from
   within axis?*



   *

   Jeff Greif wrote:

   Just to be sure, you're sending xsi:nil=true, not
   xsd:nillable=true, right?
   
   The latter is used only in the schema, and means that the 
element is

   allowed to have no content.  The former means that this
   particular use
   of the element has no content.
   
   Jeff
   
   On 2/14/06, Tim R J Langford [EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED] wrote:
   
   
   Hello All,
   
   I am writing

Re: How to not send nillable=true for null elements in a SOAP message

[Tim R J Langford]

Thanks Anand,

I really appreciate your help, and thankyou for supplying your source 
code. It was very kind.


I was infact trying a similar method too,  although I need to process my 
outgoing request, which I accessed using either:


SOAPEnvelope currentEnvelope = 
msgContext.getCurrentMessage().getSOAPEnvelope();

or
SOAPEnvelope requestEnvelope = 
msgContext.getRequestMessage().getSOAPEnvelope();



The problem occurs when manipulating the DOM however, when I call 
'getElementsByTagName(str)' with a label I know exists, or even 
'getChildren()' recursively on nodes I can only decend two levels into 
my DOM based message structure before I start obtaining nulls for 
subsequent children. When I run it in a debugger I can see my data 
wrapped in a 'RPCParam' element a few nodes down, and can even 
'getAsString()' but I cannot manipulate it any further using the DOM. I 
can process the 'getAsString()' output  to remove the required elements 
but when I try to set it using the 'rpcParam.setValue(processedStr)' 
method, my  and  tag markers (the one of elements that cant be 
accessed with the DOM programatically) get converted to lt; and 
gt; respectively which obviously screws the xml.


Have I made a mistake further up in my methodology? Wrong WSDL2Java 
options, or their schema is broken in a way that somehow causes this 
strange DOM behaviour (ie 2 nodes of DOM, and the rest hidden in an 
element that returns null when asking for all children - even though 
they are displayed in the debugger)?


Am I being a n00b? I dont know a lot about SOAP/RPC/etc (hence using the 
Axis framework), and so I dont know why I cant access these elements 
programatically. All I want to do is strip out the nillable elements! 
Why doesnt setting nilable=false and/or minOccurs=0 in the WSDL 
stop Axis sending these elements?



Anyway, thankyou for your help and especially your code. Glad to know I 
was not being stupid (I hope!)


Sorry to everyone else for bombing the list so much... I am going nuts! 
I dont wanna try and hack the HTTPSender class!


Thanks

Tim





Kasi, Anand wrote:


Tim,

  I have pasted some code to help guide you. Do the same where you have access to your MessageContext object in your class that extends the 
  BasicHandler interface. 


Anand

 Message response = msg.getResponseMessage();
 SOAPEnvelope responseEnvelope = response.getSOAPEnvelope();
 SOAPEnvelope requestEnvelope = msg.getRequestMessage().getSOAPEnvelope();
 java.util.Vector v = responseEnvelope.getBodyElements();

 Iterator it = v.iterator();

 while (it.hasNext())
 {
  SOAPBodyElement sbe = (SOAPBodyElement) it.next();
  NodeList nodes = doc.getElementsByTagName(NodeNameYouWantToRemove);
  if (nodes != null  nodes.getLength()  0)
  {
removeAll(doc, Node.ELEMENT_NODE, NodeNameYouWantToRemove);  // 
removeAll method defined below
responseEnvelope.removeBodyElement(sbe);  // removing 
soapBodyElement from responseEnvelope
SOAPBodyElement newBody = new SOAPBodyElement(doc.getDocumentElement()); // create soapBody from transformed doc object 
 responseEnvelope.addBodyElement(newBody);  // Add new soap body to responseEnvelope

  }

 }
 

 //A generic removeAll method 
public static void removeAll(Node node, short nodeType, String name) 
{

  if (node.getNodeType() == nodeType 
(name == null || node.getNodeName().equals(name))) 
  {

   node.getParentNode().removeChild(node);
  } 
  else 
  {

   // Visit the children
   NodeList list = node.getChildNodes();
   for (int i=0; ilist.getLength(); i++) 
   {

removeAll(list.item(i), nodeType, name);
   }
  }
 }




From: Tim R J Langford [mailto:[EMAIL PROTECTED]
Sent: Thu 2/16/2006 4:37 AM
To: axis-user@ws.apache.org
Subject: Re: How to not send nillable=true for null elements in a SOAP message



Thanks Kasi,

OK I am trying thsi approach now as it si my final option.

I have created a handler class that extend BasicHandler and have
attached it to my outgoing Request SimpleChain in my
EngineConfiguration. I can grab the message context and display it as a
string. I also have access to the DOM and the various RPC elements, but
it is becoming fairly complicated and bespoke to try and remove these
nil elements. Is there any simple way of getting the string, processing
it to remove the elements and setting my desired string back again at
this level?

Thanks for your time,

Tim



Kasi, Anand wrote:

 


Write up a response flow handler that gets the response message from the
MessageContext object and removes the xsi:nil = true elements.


-Original Message-
From: Tim R J Langford [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 15, 2006 9:42 AM
To: axis-user@ws.apache.org
Subject: Re: How to not send nillable=true for null elements in a SOAP
message

Hello All,

I am still trying to remove 'nil=true' elements from my messages sent
out by axis. I have modified the wsdl in elements where I want

Re: How to not send nillable=true for null elements in a SOAP message

[Tim R J Langford]

Thanks Anne,

Thats what I thought. Unfortunatly our provider does not seem too clued 
up on their tech, and the wsdl does not allow minOccurs=0.  I guess I 
will have to update our automated build process to fix their schema 
before generating my soap beans and classes. The best way to do this 
would be by adding minOccurs=0 to the faulty elements I presume?


Thanks to everybody for their time,

Tim


Anne Thomas Manes wrote:

If the service cannot accept xsi:nil=true then the service provider 
should adjust the schema accordingly. Does the schema allow 
minOccurs=0? If not, then there's no valid way to send no element 
instead of xsi:nil=true.


Anne

On 2/14/06, *Tim R J Langford* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:



Hi Jeff,

Thanks for your response.

Sorry for being unclear. Yes you are correct. I am sending
'xsi:nil=true' and I want to configure axis to send  nothing instead
of this string.  e.g : *

XXX* xsi:type=xsd:string xsi:nil=true/*
YYY* xsi:type=zzz:YYY xsi:nil=true xmlns:zzz=KKK*/

*I think Axis 1.2 did it this way? Is there anyway of configuring
Axis
1.3 to not send these 'xsi:nil=true' elements?

Thanks for you time,

Tim


PS: The service wsdl does have  'xsd:nillable=true' elements in the
message schema, but their system cannot actually handle the situation
where it is null (even if they return it in a response), and they have
asked us to remove the 'xsi:nil=true' elements from our requests. We
could fix the wsdl schema, but this would impede our codegen
system as
we are the client, so were wondering if there was a way to do it from
within axis?*



*

Jeff Greif wrote:

Just to be sure, you're sending xsi:nil=true, not
xsd:nillable=true, right?

The latter is used only in the schema, and means that the element is
allowed to have no content.  The former means that this
particular use
of the element has no content.

Jeff

On 2/14/06, Tim R J Langford [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:


Hello All,

I am writing a client interface into a provider SOAP web
service, and
their system fails and returns a null pointer exception when I
send them
a 'nillable=true' element in my request. I think the reason
for this
is that they are using an older version of axis than we are
using ( 1.3).

Re: How to not send nillable=true for null elements in a SOAP message

[Tim R J Langford]

Thanks Rod,

I agree with you and will handle it this way.

Thankyou everyone for your help and advice,

Tim


Rodrigo Ruiz wrote:

By what you describe, I think you should add minOccurs='0' and remove 
nillable='true'


Regards,
Rodrigo Ruiz

Tim R J Langford wrote:


Thanks Anne,

Thats what I thought. Unfortunatly our provider does not seem too 
clued up on their tech, and the wsdl does not allow minOccurs=0.  I 
guess I will have to update our automated build process to fix their 
schema before generating my soap beans and classes. The best way to 
do this would be by adding minOccurs=0 to the faulty elements I 
presume?


Thanks to everybody for their time,

Tim


Anne Thomas Manes wrote:

If the service cannot accept xsi:nil=true then the service 
provider should adjust the schema accordingly. Does the schema allow 
minOccurs=0? If not, then there's no valid way to send no element 
instead of xsi:nil=true.


Anne

On 2/14/06, *Tim R J Langford* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:



Hi Jeff,

Thanks for your response.

Sorry for being unclear. Yes you are correct. I am sending
'xsi:nil=true' and I want to configure axis to send  nothing 
instead

of this string.  e.g : *

XXX* xsi:type=xsd:string xsi:nil=true/*
YYY* xsi:type=zzz:YYY xsi:nil=true xmlns:zzz=KKK*/

*I think Axis 1.2 did it this way? Is there anyway of configuring
Axis
1.3 to not send these 'xsi:nil=true' elements?

Thanks for you time,

Tim


PS: The service wsdl does have  'xsd:nillable=true' elements 
in the
message schema, but their system cannot actually handle the 
situation
where it is null (even if they return it in a response), and 
they have
asked us to remove the 'xsi:nil=true' elements from our 
requests. We

could fix the wsdl schema, but this would impede our codegen
system as
we are the client, so were wondering if there was a way to do it 
from

within axis?*



*

Jeff Greif wrote:

Just to be sure, you're sending xsi:nil=true, not
xsd:nillable=true, right?

The latter is used only in the schema, and means that the 
element is

allowed to have no content.  The former means that this
particular use
of the element has no content.

Jeff

On 2/14/06, Tim R J Langford [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:


Hello All,

I am writing a client interface into a provider SOAP web
service, and
their system fails and returns a null pointer exception when I
send them
a 'nillable=true' element in my request. I think the reason
for this
is that they are using an older version of axis than we are
using ( 1.3).

Re: How to not send nillable=true for null elements in a SOAP message

[Tim R J Langford]

Hello All,

I am still trying to remove 'nil=true' elements from my messages sent 
out by axis. I have modified the wsdl in elements where I want axis not 
to send these strings (i.e: have a blank element) as follows :


element name=sendNothingIfNull nillable=true type=xsd:string/

to :

element name=sendNothingIfNull nillable=false minOccurs=0 
type=xsd:string/


so that instead of sending :

someXML
   sendNothingIfNull xsi:type=xsd:string xsi:nil=true/
/someXML

I send something like :

someXML/someXML


I have tried a few other methods (such as the one Rod suggested not 
specifying nillable at all in the schema and setting minOccurs=0) 
but axis keeps sending these elements as nillable. Should this work or 
am I making a mistake somwhere?


It may be PEBCAK but I just cant get axis1.3  to exhibit the behavior 
the server expects. Is there any other lower level method in axis to 
deal with this? (I traced the code calls down to the HTTP sender class 
but even at this level there is no easy access to the string as it is 
being passed by chunk encoded HTTP - and of course in some cases the 
server we are trying to attach too actually wants us to send these 
nillable=true elements so this approach is not suitable).


I know I must have exhausted all you guys by now! Sorry, and thanks.


Tim

PS: I am generating the axis code form the wsdl using the following ant 
task configuration :


   axis-wsdl2java
 output=${src.dir}
 deployScope=Application
 verbose=true
 serverSide=true
wrapArrays=true
 url=eurostar_hack2.wsdl   
   /axis-wsdl2java








Rodrigo Ruiz wrote:

By what you describe, I think you should add minOccurs='0' and remove 
nillable='true'


Regards,
Rodrigo Ruiz

Tim R J Langford wrote:


Thanks Anne,

Thats what I thought. Unfortunatly our provider does not seem too 
clued up on their tech, and the wsdl does not allow minOccurs=0.  I 
guess I will have to update our automated build process to fix their 
schema before generating my soap beans and classes. The best way to 
do this would be by adding minOccurs=0 to the faulty elements I 
presume?


Thanks to everybody for their time,

Tim


Anne Thomas Manes wrote:

If the service cannot accept xsi:nil=true then the service 
provider should adjust the schema accordingly. Does the schema allow 
minOccurs=0? If not, then there's no valid way to send no element 
instead of xsi:nil=true.


Anne

On 2/14/06, *Tim R J Langford* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:



Hi Jeff,

Thanks for your response.

Sorry for being unclear. Yes you are correct. I am sending
'xsi:nil=true' and I want to configure axis to send  nothing 
instead

of this string.  e.g : *

XXX* xsi:type=xsd:string xsi:nil=true/*
YYY* xsi:type=zzz:YYY xsi:nil=true xmlns:zzz=KKK*/

*I think Axis 1.2 did it this way? Is there anyway of configuring
Axis
1.3 to not send these 'xsi:nil=true' elements?

Thanks for you time,

Tim


PS: The service wsdl does have  'xsd:nillable=true' elements 
in the
message schema, but their system cannot actually handle the 
situation
where it is null (even if they return it in a response), and 
they have
asked us to remove the 'xsi:nil=true' elements from our 
requests. We

could fix the wsdl schema, but this would impede our codegen
system as
we are the client, so were wondering if there was a way to do it 
from

within axis?*



*

Jeff Greif wrote:

Just to be sure, you're sending xsi:nil=true, not
xsd:nillable=true, right?

The latter is used only in the schema, and means that the 
element is

allowed to have no content.  The former means that this
particular use
of the element has no content.

Jeff

On 2/14/06, Tim R J Langford [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:


Hello All,

I am writing a client interface into a provider SOAP web
service, and
their system fails and returns a null pointer exception when I
send them
a 'nillable=true' element in my request. I think the reason
for this
is that they are using an older version of axis than we are
using ( 1.3).

How to not send nillable=true for null elements in a SOAP message

[Tim R J Langford]

Hello All,

I am writing a client interface into a provider SOAP web service, and 
their system fails and returns a null pointer exception when I send them 
a 'nillable=true' element in my request. I think the reason for this 
is that they are using an older version of axis than we are using (1.3).


I have found a solution that recommends changing the WSDL of the 
generated service :


http://marc.theaimsgroup.com/?l=axis-userm=111793234530147w=2


However, this is not ideal, as we do not have control over this WSDL 
(belongs to the provider) so even though we can modify their file I 
would prefer not to.


Are there any options in Axis that would allow us not to send anything 
when we have a such null element, as opposed to sending 
'nillable=true'? If not where should I make the change? I could add a 
handler to the client to strip these elements out before they are sent, 
but this is probably not very efficient.



Anyhelp would be appreciated!

Thanks for you time,

Tim

Re: How to not send nillable=true for null elements in a SOAP message

[Tim R J Langford]

Hi Jeff,

Thanks for your response.

Sorry for being unclear. Yes you are correct. I am sending  
'xsi:nil=true' and I want to configure axis to send  nothing instead 
of this string.  e.g : *


XXX* xsi:type=xsd:string xsi:nil=true/*
YYY* xsi:type=zzz:YYY xsi:nil=true xmlns:zzz=KKK*/

*I think Axis 1.2 did it this way? Is there anyway of configuring Axis 
1.3 to not send these 'xsi:nil=true' elements?


Thanks for you time,

Tim


PS: The service wsdl does have  'xsd:nillable=true' elements in the 
message schema, but their system cannot actually handle the situation 
where it is null (even if they return it in a response), and they have 
asked us to remove the 'xsi:nil=true' elements from our requests. We 
could fix the wsdl schema, but this would impede our codegen system as 
we are the client, so were wondering if there was a way to do it from 
within axis?*




*

Jeff Greif wrote:


Just to be sure, you're sending xsi:nil=true, not xsd:nillable=true, right?

The latter is used only in the schema, and means that the element is
allowed to have no content.  The former means that this particular use
of the element has no content.

Jeff

On 2/14/06, Tim R J Langford [EMAIL PROTECTED] wrote:
 


Hello All,

I am writing a client interface into a provider SOAP web service, and
their system fails and returns a null pointer exception when I send them
a 'nillable=true' element in my request. I think the reason for this
is that they are using an older version of axis than we are using (1.3).
   



 

Re: Problem with [sequence.choice.element] structure in WSDL2Java?

[Tim R J Langford]

Hello Everyone,

Thanks for your response Iksreal. Unfortunately I cannot change the 
schema because it si published and my webservice is a client of it 
(hence I have no control overs its definition). The schema is valid (if 
a slightly strange way of epxressing the structure) as far as I can see, 
but the beans generated by WSDL are incorrect I think, as it should 
produce a collection of  {URL, Text, Image} elements. Although I can 
imagine why the generation has failed due to the any allowable ordering 
of the elements.


Is this a bug? Should I submit it it to some JIRA/bug tracking mechanism?

Kind Regards,

Tim

PS: Sorry if this is a duplicate posting - we have had some problems 
with our mail servers.



iksrazal wrote:

Just a simple thought - have you thought about defining an Array in your wsdl 
and returning that? Simply create a List on the service side and use 
toArray() ? 


iksrazal

Em Terça 06 Dezembro 2005 10:20, o Tim R J Langford escreveu:
 


Greetings All,


1) I am having a problem with the WSDL2Java code generated from the
current schema element :


s:complexType name=ParagraphType
   s:sequence
   s:choice minOccurs=0 maxOccurs=unbounded
   s:element minOccurs=0 maxOccurs=1 name=Text
type=s1:FormattedTextTextType/
   s:element minOccurs=0 maxOccurs=1 name=Image
type=s:string/
   s:element minOccurs=0 maxOccurs=1 name=URL
type=s:anyURI/
   /s:choice
   /s:sequence
   s:attribute name=ParagraphNumber type=s:nonNegativeInteger/
/s:complexType



2) This schema represents (among other things) such messages as :

VendorMessage Title=XXXImages Language=en InfoType=URI
   SubSection SubTitle=95 SubSectionNumber=1
   Paragraph ParagraphNumber=1
  URLhttp://www.XXX.com/1.gif/URL
  URLhttp://www.XXX.com/2.gif/URL
  URLhttp://www.XXX.com/3.gif/URL
  URLhttp://www.XXX.com/4.gif/URL
  URLhttp://www.XXX.com/5.gif/URL
  URLhttp://www.XXX.com/6.gif/URL
   /Paragraph
   /SubSection
/VendorMessage


3) However the corresponding ParagraphType class generated by WSDL2Java
has the following member variables generated (which are not sets of the
corresponding elements) :

   private org.opentravel.www.OTA._2003._05.FormattedTextTextType text;
   private java.lang.String image;
   private org.apache.axis.types.URI URL;
   private org.apache.axis.types.NonNegativeInteger paragraphNumber;
// attribute

4) So when the message is unmarshalled only the final URL  (in this
example) is available through the accessor method of the unmarshalled
bean and the others are lost...

I have looked though the other WSDL posts on this forum but cannot seem
to find a solution. Is there are special parameter I should set when
generating the Java, or is this possibly a bug in the generator (the
schema does seem a slightly esoteric way of defining the structure)?

Any help would be greatfully appreciated because this has become a bit
of a show stopper to the project.

Thankyou for your time,

Tim
   



 

Problem with [sequence.choice.element] structure in WSDL2Java?

[Tim R J Langford]

Greetings All,


1) I am having a problem with the WSDL2Java code generated from the 
current schema element :



s:complexType name=ParagraphType
   s:sequence
   s:choice minOccurs=0 maxOccurs=unbounded
   s:element minOccurs=0 maxOccurs=1 name=Text 
type=s1:FormattedTextTextType/
   s:element minOccurs=0 maxOccurs=1 name=Image 
type=s:string/
   s:element minOccurs=0 maxOccurs=1 name=URL 
type=s:anyURI/

   /s:choice
   /s:sequence
   s:attribute name=ParagraphNumber type=s:nonNegativeInteger/
/s:complexType



2) This schema represents (among other things) such messages as :

VendorMessage Title=XXXImages Language=en InfoType=URI
   SubSection SubTitle=95 SubSectionNumber=1
   Paragraph ParagraphNumber=1
  URLhttp://www.XXX.com/1.gif/URL
  URLhttp://www.XXX.com/2.gif/URL
  URLhttp://www.XXX.com/3.gif/URL
  URLhttp://www.XXX.com/4.gif/URL
  URLhttp://www.XXX.com/5.gif/URL
  URLhttp://www.XXX.com/6.gif/URL
   /Paragraph
   /SubSection
/VendorMessage


3) However the corresponding ParagraphType class generated by WSDL2Java 
has the following member variables generated (which are not sets of the 
corresponding elements) :


   private org.opentravel.www.OTA._2003._05.FormattedTextTextType text;
   private java.lang.String image;
   private org.apache.axis.types.URI URL;
   private org.apache.axis.types.NonNegativeInteger paragraphNumber;  
// attribute


4) So when the message is unmarshalled only the final URL  (in this 
example) is available through the accessor method of the unmarshalled 
bean and the others are lost...


I have looked though the other WSDL posts on this forum but cannot seem 
to find a solution. Is there are special parameter I should set when 
generating the Java, or is this possibly a bug in the generator (the 
schema does seem a slightly esoteric way of defining the structure)?


Any help would be greatfully appreciated because this has become a bit 
of a show stopper to the project.


Thankyou for your time,

Tim

Re: Sending java.util.Set using AXIS

[Tim R J Langford]

Thank you Iksrazal,

Unfortunately, I am only writing the client to attach to this service 
and have no control over the WSDL. I could theoretically download the 
WSDL and apply some kind of filter to transform the schema into 
something else (that hopefully genrates the correct beans) and generate 
from that, but this will be last choice option and is not ideal for me.


The WSDL uses both types of SOAP message, but the element I am having 
problems with are document objects. Thanks very much however for your 
kind offer an example. I really appreciate it! However, what I really 
require is for the beans to generate from the WSDL correctly or work out 
what my own PEBCACK might be, although I think the problem is most likey 
to do with the strange schema definition.


Thankyou,

Tim


iksrazal wrote:

Define an Array in your wsdl and use set.toArray() . If you're using RPC 
encoded I could give you an example - although I'm using doc / lit at the 
moment I haven't gotten to arrays yet. 


iksrazal

Em Terça 06 Dezembro 2005 10:16, o Markus Plail escreveu:
 


Hi there!

Is it posible to use java.util.Setpackage.Object and use it in a web
service. If yes, how must my beanmapping look like? I am using Hibernate
and it maps collections to java.util.Set and I'd really like to use
them. If it is RTFM just point to the right manual.

Thanks in advance
Markus Plail
   



 

Re: WSDL2Java and client SSL

[Tim R J Langford]

Hi Markus,

Did you manage to find a solution to your problem? I had to do something 
similar once with a test system to get it to accept non certified sites 
across ssl. I could not work out how to do do it correctly in Axis; so I 
ended up creating a custom HTTPSender and setting it up as my pivot in 
the handler chain of Axis. I extended the base HttpSender class from 
Axis, but a lot of variables and methods I wanted to overide were 
private, so unfortunately I ended up having to cut and paste most of the 
extending class into the new class and am not sure of the implications 
of this evne though everything seemed to work fine.


If you use this method then you can pretty much alter the HTTP mechanism 
as you see fit: for example allowing you to support gzip compression (I 
think originally axis did not support this from what I remember?). You 
can also use this class to overide the SocketFactory and get it to 
produce a non-certified sockets if you so desire. Infact this method 
maybe overidable... I cant remember. If not maybe it should be.


Anyway, I am sure there is a more maintainable way of doing this, but I 
was in a rush and it was a while ago. If you are in the same situation 
maybe a simialr approach will get you by for now?



Hope this helps until you find something more suitable,

Tim



Markus Reil wrote:


Hi,

I am currently trying to connect to a SOAP Web Service with Axis. I 
need to use a client certificate to authenticate myself.
I do not want to set the keystore/truststore files globally via system 
properties because I have other http traffic in the same virtual 
machine that uses different or no keys.


I know there are a lot threads out about Axis/SSL out there. But I 
already spent a couple of hours looking for a solution and did not 
find anything of great use. Can anyone help me with this?


E.g. is it possible to create a SocketFactory and pass it to the Axis 
Service or Remote instance?


Thanks.

Regards,
Markus

Problem with WSDL2Java?

[Tim R J Langford]

Hello All,

I am upgrading some SOAP clients from Axis 1.2 to Axis 1.3 Final. One of 
them upgraded with little effort,  just some changes to the code that 
processed the new bean convention style generate by WSDL2Java. The other 
project  is proving very troublesome however.


#1 : Firstly the schema beans appear NOT to generate properly. For 
example the following Schema section :



 s:complexType name=RoomStayCandidateType
   s:sequence
 s:element minOccurs=0 maxOccurs=1 name=GuestCounts 
type=s1:GuestCountType /
 s:element minOccurs=0 maxOccurs=unbounded 
name=RoomAmenity type=s1:RoomAmenityPrefType /

   /s:sequence
   s:attribute name=RoomType type=s:string /
   s:attribute name=RoomTypeCode type=s:string /
   s:attribute name=Quantity type=s:positiveInteger /
   s:attribute name=Composite type=s:boolean /
 /s:complexType
 s:complexType name=GuestCountType
   s:sequence
 s:element minOccurs=0 maxOccurs=unbounded 
name=GuestCount type=s1:GuestCountTypeGuestCount /

   /s:sequence
   s:attribute name=IsPerRoom type=s:boolean /
 /s:complexType
 s:complexType name=GuestCountTypeGuestCount
   s:attribute name=AgeQualifyingCode type=s:string /
   s:attribute name=Age type=s:nonNegativeInteger /
   s:attribute name=Count type=s:positiveInteger /
 /s:complexType


But here WSDL2Java enerates a RoomStayCandidateType object that 
contains an array of GuestCountTypeGuestCount objects as a member. It 
does not generate a GuestCountType at all. This of course breaks the 
service. The old version of WSDL2Java generated all these classes as was 
to be expected, and only messed up setting the action type on one of the 
services (whihc was easilly fixed with a code post processor). I assume 
this is a bug. The schema seems valid to me.



#2 : Another problem occured in the generated source where a constructor 
was created thats calls Object.super() as follows...


public class VendorMessageType  implements java.io.Serializable {
   private java.lang.String infoType;  // attribute

   private 
org.opentravel.www.OTA._2003._05.FormattedTextSubSectionTypeParagraph[][] 
formattedTextType;  // attribute


   public VendorMessageType() {
   }

   public VendorMessageType(
  
org.opentravel.www.OTA._2003._05.FormattedTextSubSectionTypeParagraph[][] 
param1,

  java.lang.String Title,
  org.apache.axis.types.Language Language,
  java.lang.String infoType) {
   super(
   param1,
   Title);
   this.Language = Language;
   this.infoType = infoType;
   }

...
etc
...

}

???


When I searched the mailing list I noticed a few possibly similar 
questions to this, but no reponse I could act on. Is there any 
possibility of fixing these problems? If not is there any method of 
fixing/altering the generated source form the old version of Axis 
WSDL2Java to work with new 1.3 library? For example could I code to the 
correctly generated old 1.1 SOAP beans to get them to work with 1.3?


Thanks very much for your help and time! This has become a real show 
stopper, and I got deadlines and a crazy boss!


Tim

Re: Problem with WSDL2Java?

[Tim R J Langford]

Hello Christian!

Thankyou very much for your swift response, and you are indeed correct! 
I added the 'wrapArrays=true' to the ant task and everything generated 
as expected and now my messages are full of extra nilable elements and 
work just fine with no changes to my processing code at all! A direct 
upgrade - great!


Thankyou Sir, and much respect to you.

Regards,

Tim


PS: Maybe it would be worth setting 'wrapArrays=true' by default, 
because in my case when set to false WSDL2Java actually created 
non-compilable code in one case, and in the others forced me to change 
alot of the message processing code? Or is my usage an exception to 
normal usage?







Christian Schmitz wrote:


Hi Tim,

I think my problem discussed on the title wsdl2java does not generate 
class-files for complexTypes seems to be the same as yours. Try the 
--wrapArrays (-w) option when generating the sources.


Regards,
Christian

Tim R J Langford schrieb:


Hello All,

I am upgrading some SOAP clients from Axis 1.2 to Axis 1.3 Final. One 
of them upgraded with little effort,  just some changes to the code 
that processed the new bean convention style generate by WSDL2Java. 
The other project  is proving very troublesome however.


#1 : Firstly the schema beans appear NOT to generate properly. For 
example the following Schema section :



 s:complexType name=RoomStayCandidateType
   s:sequence
 s:element minOccurs=0 maxOccurs=1 name=GuestCounts 
type=s1:GuestCountType /
 s:element minOccurs=0 maxOccurs=unbounded 
name=RoomAmenity type=s1:RoomAmenityPrefType /

   /s:sequence
   s:attribute name=RoomType type=s:string /
   s:attribute name=RoomTypeCode type=s:string /
   s:attribute name=Quantity type=s:positiveInteger /
   s:attribute name=Composite type=s:boolean /
 /s:complexType
 s:complexType name=GuestCountType
   s:sequence
 s:element minOccurs=0 maxOccurs=unbounded 
name=GuestCount type=s1:GuestCountTypeGuestCount /

   /s:sequence
   s:attribute name=IsPerRoom type=s:boolean /
 /s:complexType
 s:complexType name=GuestCountTypeGuestCount
   s:attribute name=AgeQualifyingCode type=s:string /
   s:attribute name=Age type=s:nonNegativeInteger /
   s:attribute name=Count type=s:positiveInteger /
 /s:complexType


But here WSDL2Java enerates a RoomStayCandidateType object that 
contains an array of GuestCountTypeGuestCount objects as a member. 
It does not generate a GuestCountType at all. This of course breaks 
the service. The old version of WSDL2Java generated all these classes 
as was to be expected, and only messed up setting the action type on 
one of the services (whihc was easilly fixed with a code post 
processor). I assume this is a bug. The schema seems valid to me.



#2 : Another problem occured in the generated source where a 
constructor was created thats calls Object.super() as follows...


public class VendorMessageType  implements java.io.Serializable {
   private java.lang.String infoType;  // attribute

   private 
org.opentravel.www.OTA._2003._05.FormattedTextSubSectionTypeParagraph[][] 
formattedTextType;  // attribute


   public VendorMessageType() {
   }

   public VendorMessageType(
  
org.opentravel.www.OTA._2003._05.FormattedTextSubSectionTypeParagraph[][] 
param1,

  java.lang.String Title,
  org.apache.axis.types.Language Language,
  java.lang.String infoType) {
   super(
   param1,
   Title);
   this.Language = Language;
   this.infoType = infoType;
   }

...
etc
...

}

???


When I searched the mailing list I noticed a few possibly similar 
questions to this, but no reponse I could act on. Is there any 
possibility of fixing these problems? If not is there any method of 
fixing/altering the generated source form the old version of Axis 
WSDL2Java to work with new 1.3 library? For example could I code to 
the correctly generated old 1.1 SOAP beans to get them to work with 1.3?


Thanks very much for your help and time! This has become a real show 
stopper, and I got deadlines and a crazy boss!


Tim