RE: How best to transform a XML file into a message.
Hi Mike. The Java route for different versions of the WSDL is a very good solution. Especially if you couple this with Maven2 and the use of an artifact repository such as Archiva (http://archiva.apache.org/). Then, you can construct an individual, versioned JAR file for each version of the WSDL. In your Java code the run the application you can then simply configure it to use the appropriate version as necessary. This would remove the need to update your classpath - you'd simply let Maven2 manage the dependencies. Another follow on question to your previous email: Are they changing the WSDL or the Schema of the web services? Alastair This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments. The entire content of this e-mail is for information purposes only and should not be relied upon by the recipient in any way unless otherwise confirmed in writing by way of letter or facsimile. -Original Message- From: Mike Marchywka [mailto:marchy...@hotmail.com] Sent: Thursday, April 02, 2009 9:18 AM To: axis-c-user@ws.apache.org Subject: RE: How best to transform a XML file into a message. Date: Thu, 2 Apr 2009 08:37:01 -0700 Subject: Re: How best to transform a XML file into a message. From: To: axis-c-user@ws.apache.org Sam, IMHO, it isn't worth doing web services unless you use the autogenerated code. I learned from experience to stop hand jamming xml. If your WSDL changes, you want to re-autogenerate the plumbing code on both your client and server side ... and with any luck, any code changes you have are isolated in the code you had to write in order to use the objects generated on your client side. I spent a lot of time with the C generated code and never did get it to work well I so went back to java axis and everything pretty much worked right away. But, the reason for mentioning this now, is that I have subsequently found that our service provider often updates the WSDL file. This turns out to be fine in java since I can diff the wsdl files, re generate the class files unless there is something gross that has been changed, and then almost all of my reflection-invoked code still runs: I can archive, upload, and download things in a complete and consistent manner by just looking for public get/set methods. Is there some similar facility in the C- axis to reflection invokation? I guess if you put all that in a DLL/SO you can load the library of your choice. With java, if I really need to, I can point the class path to pick up either the current or prior WSDL class files with little effort. _ Rediscover Hotmail(r): Now available on your iPhone or BlackBerry http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover _Mobile1_042009
RE: How best to transform a XML file into a message.
Mike. Thanks, I'll look at that but couldn't I just use subversion for that? If I find a new wsdl file, I can just copy if over a local svn check out, commit the new one, and then go back and play around if needed. That's true you can do that. I would only suggest going that route if you only move forward and will never need to support a previous version. For our project we get a new version of the WSDL file every few months. Thus we use the Archiva method for management of these artifacts as not all client operations of our service update to the latest immediately so we end up supporting multiple versions of a single WSDL. This in itself is it's own task especially when dealing with generated code and namespaces... I hate to ask but does the XML file actually relate to your WSDL or is it unrelated DATA, intended for a local XML parser to examine? You may be just asking a question like, how do I send a JPEG or PDF file in a SOAP response? I prefer to think of web services as a combination of operations/signatures and payloads. The XML is the payload and is defined by the XML Schema which is generally referenced from or embedded in the WSDL. The operation signature is defined by the WSDL with wsdl:operation and wsdl:message. Example: !-- Message payload -- wsdl:types xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:msg=http://www.mycompany.com; xs:element name=MyOperationRequestElement type=xs:string/ xs:element name=MyOperationResponseElement type=xs:string/ /xs:schema /wsdl:types !-- binding the operation input/output to the payload -- wsdl:message name=MyOperationRequest wsdl:part name=body element=msg:MyOperationRequestElement/ /wsdl:message wsdl:message name=MyOperationResponse wsdl:part name=body element=msg:MyOperationResponseElement/ /wsdl:message !-- defining the operations -- wsdl:portType name=MyPortType wsdl:operation name=MyOperation wsdl:input message=tns:MyOperationRequest/ wsdl:output message=tns:MyOperationResponse/ /wsdl:operation /wsdl:portType wsdl:binding name=MyPortBinding type=tns:MyPortType soap:binding transport=http://schemas.xmlsoap.org/soap/http; style=document/ wsdl:operation name=MyOperation soap:operation soapAction=MyOperation/ wsdl:input soap:body parts=body use=literal/ /wsdl:input wsdl:output soap:body parts=body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding It's fine to have the WSDL but you need a schema definition to go along with it. It ends up looking something like this: Request message: soap:envelope soap:body msg:MyOperationRequestElementfoo/msg:MyOperationRequestElement /soap:body /soap:envelope Response message: soap:envelope soap:body msg:MyOperationResponseElementfoo/msg:MyOperationResponseElement /soap:body /soap:envelope There's a quick and dirty intro to WSDL. This is why I was asking if the XML Schema was changing or just the operation signatures... Disclaimer: I did this off the top of my head! Alastair This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments. The entire content of this e-mail is for information purposes only and should not be relied upon by the recipient in any way unless otherwise confirmed in writing by way of letter or facsimile. -Original Message- From: Mike Marchywka [mailto:marchy...@hotmail.com] Sent: Thursday, April 02, 2009 9:40 AM To: axis-c-user@ws.apache.org Subject: RE: How best to transform a XML file into a message. Subject: RE: How best to transform a XML file into a message. Date: Thu, 2 Apr 2009 09:32:47 -0700 From: spam haven CT To: axis-c-user@ws.apache.org Hi Mike. The Java route for different versions of the WSDL is a very good solution. Especially if you couple this with Maven2 and the use of an artifact repository such as Archiva (http://archiva.apache.org/). Then, you can construct an individual, versioned JAR file for each version of the WSDL. In your Java code the run the application you can then simply configure it to use the appropriate version as necessary. This would remove the need to update your classpath - you'd simply let Maven2 manage the dependencies. Thanks, I'll look at that but couldn't I just use subversion for that? If I find a new wsdl
RE: SOAP-ENV versus soapenv
Hi Andrew. Theoretically soapenv should be perfectly acceptable. Irregardless of what the prefix is, as long as the actual namespace is the same it should recognize things appropriately. Take this silly example: soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; ... /SOAP-ENV:Envelope Theoretically that should work without error. Cheers. Alastair -Original Message- From: Andrew Wood [mailto:[EMAIL PROTECTED] Sent: Friday, January 11, 2008 11:32 AM To: axis-user@ws.apache.org Subject: SOAP-ENV versus soapenv When creating SOAP tags is there a choice of using either SOAP-ENV or soapenv? I thought it had to be SOAP-ENV but my Axis client is using soapenv, and I think this is probably the cause for the server moaning that the start or end tags of the SOAP message are missing. For example Axis sends soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/ envelope/ xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body And the server (not Axis) says SOAP-ENV:faultcodeClient.ImproperlyFormattedMessage/SOAP- ENV:faultcode SOAP-ENV:faultstringThe message either has no begin tag or is missing the end tag. In either case, the message was not formatted correctly./SOAP-ENV:faultstring Am I right or is soapenv perfectly acceptable? Thanks Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2C] Casting away const
Axis2C Developers:
There seems to be a fundamental problem with functions that return
values of type axis2_chart_t*. We have only investigated a couple of
them but it appears that const values are being casted away in some
instances. Please view the following example:
snippet
AXIS2_EXTERN
axis2_char_t*
axiom_attribute_get_value(
axiom_attribute_t * attribute,
const axutil_env_t * env)
{
if (attribute-value)
{
return (axis2_char_t *)
axutil_string_get_buffer(attribute-value, env);
}
return NULL;
}
/snippet
Note that the return value of axiom_attribute_get_value is a NON-const
axis2_char_t*. Note the cast on the return value of function
axutil_string_get_buffer. Here is the declaration of
axutil_string_get_buffer.
snippet
AXIS2_EXTERN
const axis2_char_t*
axutil_string_get_buffer(
const struct axutil_string *string,
const axutil_env_t * env);
/snippet
Note that the return value is a CONST axis2_char_t*. The const attribute
of this pointer is being removed via the cast.
Is this expected functionality? If not I suggest you research all
functions that return axis2_char_t*.
Regards.
Alastair Fettes
This e-mail and any attachments are intended solely for the use of the
intended recipient(s) and may contain legally privileged, proprietary
and/or confidential information. Any use, disclosure, dissemination,
distribution or copying of this e-mail and any attachments for any
purposes that have not been specifically authorized by the sender is
strictly prohibited. If you are not the intended recipient, please
immediately notify the sender by reply e-mail and permanently delete all
copies and attachments.
The entire content of this e-mail is for information purposes only and
should not be relied upon by the recipient in any way unless otherwise
confirmed in writing by way of letter or facsimile.
[Axis2] Changes to WSDL2Java generated MessageReceiverInOut class
Apache Axis2 Team:
During our work with Apache Axis2 version 1.3 we have run into a
deficiency in the generated output from WSDL2Java in the form of the
MessageReceiverInOut class. The problem lies in the order of
operations.
In the generated MessageReceiverInOut.java class, the out message
context does not have a valid SOAP envelope when the message handler in
the application supplied skeleton interface is called. Therefore, the
message handler cannot populate the contents of the out message SOAP
header. To solve the problem the out message SOAP envelope must be
created prior to calling the skeleton interface message handler.
Current implementation:
snippet
if((op.getName() != null)
((methodName =
org.apache.axis2.util.JavaUtils.xmlNameToJava(op.getName()
.getLocalPart())) != null))
{
if(MessageName.equals(methodName))
{
com.foo.messages.MessageNameResponseDocument
messageNameResponse170 =
null;
com.foo.messages.MessageNameRequestDocument wrappedParam =
(com.foo.messages.MessageNameRequestDocument) fromOM(
msgContext.getEnvelope().getBody()
.getFirstElement(),
com.foo.messages.MessageNameRequestDocument.class,
getEnvelopeNamespaces(msgContext.getEnvelope()));
messageNameResponse170 = skel.MessageName(wrappedParam);
envelope = toEnvelope(getSOAPFactory(msgContext),
messageNameResponse170, false);
}
else
{
throw new java.lang.RuntimeException(method not found);
}
newMsgContext.setEnvelope(envelope);
}
/snippet
Possible solution:
snippet
if((op.getName() != null)
((methodName =
org.apache.axis2.util.JavaUtils.xmlNameToJava(op.getName()
.getLocalPart())) != null))
{
if(MessageName.equals(methodName))
{
com.foo.messages.MessageNameResponseDocument
messageNameResponse170 =
null;
com.foo.messages.MessageNameRequestDocument wrappedParam =
(com.foo.messages.MessageNameRequestDocument) fromOM(
msgContext.getEnvelope().getBody()
.getFirstElement(),
com.foo.messages.MessageNameRequestDocument.class,
getEnvelopeNamespaces(msgContext.getEnvelope()));
/*
* Changes begin here
*/
// Create the envelope and associate it with the message context
// BEFORE the operation call
envelope = getSOAPFactory(msgContext).getDefaultEnvelope();
newMsgContext.setEnvelope(envelope);
// operation call as normal
messageNameResponse170 = skel.MessageName(wrappedParam);
//
if (messageNameResponse170 != null)
{
envelope.getBody().addChild(toOM(messageNameResponse170,
false));
}
/*
* Changes end here
*/
}
else
{
throw new java.lang.RuntimeException(method not found);
}
newMsgContext.setEnvelope(envelope);
}
/snippet
The solution splits the functionality of the toEnvelope function into
two separate calls on either side of the operation call. This allows
the operation to have access to the envelope and thus add custom SOAP
headers as appropriate.
Once again, thanks very much for your time and efforts on this project.
Sincerely,
Alastair Fettes
This e-mail and any attachments are intended solely for the use of the
intended recipient(s) and may contain legally privileged, proprietary
and/or confidential information. Any use, disclosure, dissemination,
distribution or copying of this e-mail and any attachments for any
purposes that have not been specifically authorized by the sender is
strictly prohibited. If you are not the intended recipient, please
immediately notify the sender by reply e-mail and permanently delete all
copies and attachments.
The entire content of this e-mail is for information purposes only and
should not be relied upon by the recipient in any way unless otherwise
confirmed in writing by way of letter or facsimile.
RE: [Axis2] trimming down the xml in axis2 1.3
Samir. If your clients can't handle the difference between ns:fieldName xmlns:ns=foo0/ns:fieldName and fieldName xmlns=foo0/fieldName then I wouldn't bother using SOAP or web services. These are equivalent in XML. I can understand suppressing the prefix in regards to efficency and the size of the message but not to support a client that doesn't handle XML properly. Otherwise it's just a glorified text reader... Alastair -Original Message- From: samir shaikh [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 12, 2007 5:31 PM To: axis-user@ws.apache.org Subject: Re: [Axis2] trimming down the xml in axis2 1.3 Martin, You mean using QName in the client code? I'm trying to tune my server to not send back excessive xml. I cannot change the xml I send back to my clients. the extra ns: is causing me trouble after upgrading from axis2 1.1.1 to axis2 1.3 e.g. ns:fieldName0/ns:fieldName. My clients expect fieldName0/fieldName. Samir --- Martin Gainty [EMAIL PROTECTED] wrote: you can always use null..e.g. QName paramQName = new QName(, paramName); M-- - Original Message - From: samir shaikh [EMAIL PROTECTED] To: axis-user@ws.apache.org Sent: Wednesday, December 12, 2007 7:20 PM Subject: RE: [Axis2] trimming down the xml in axis2 1.3 Raghu, Thanks for your help. I tried that out but I want to suppress it on the server. I think WSDL2Java is for generating a client, right? I'm hoping to find some configuration in services.xml or axis2.xml... any idea? Samir --- Raghu Upadhyayula [EMAIL PROTECTED] wrote: Samir, Try WSDL2Java with -sp option to suppress the namespace prefix. Thanks Raghu -Original Message- From: samir shaikh [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 12, 2007 2:20 PM To: axis-user@ws.apache.org Subject: [Axis2] trimming down the xml in axis2 1.3 Hi, I'm trying to trim down the xml exchanged when using a axis2 client and server. Is there a way I can configure the serializer to not prefix namespace with every element e.g. ns:errorCode0/ns:errorCode can just be errorCode0errorCode. Also not send back the additional headers and field types with each call. I was able to do that in Axis1.3 with the wsdd file. Can someone point me to where that is done in Axis2. Thanks a lot. Samir Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Axis2] trimming down the xml in axis2 1.3
Hi Samir. First off let me state that I understand about not changing the clients of your webservice and feel your pain. I agree that you can't just go changing your clients because of a COTS product upgrade. :) My point was more along the lines of the fact that I wasn't sure _why_ they have to change. The two XML documents that you showed are technically equivalent: ns:getAuthXResponse xmlns:ns=http://edge.avaya.com/xsd; ns:return type=com.avaya.edge.ResultBean ns:errorCode0/ns:errorCode ns:errorMsgSuccess/ns:errorMsg /ns:return /ns:getAuthXResponse Is this not technically the same as...? (except for the type attribute on the return?) ns:getAuthXResponse xmlns:ns=http://edge.avaya.com/xsd; ns:return errorCode xmlns=http://edge.avaya.com/xsd;0/errorCode errorMsg xmlns=http://edge.avaya.com/xsd;Success/errorMsg /ns:return /ns:getAuthXResponse Would the first and second not both validate off the same XML Schema? Unless they aren't XML aware readers. Alastair -Original Message- From: samir shaikh [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 12, 2007 5:59 PM To: axis-user@ws.apache.org Subject: RE: [Axis2] trimming down the xml in axis2 1.3 Alastair, I have a very convincing argument for glorified text readers who want to hit a url and get text back to use my service. Rather then custom coding all that I've configured Axis2 to accept HTTP GET parameters as input and return back an xml, just as it would for an xml call. If I can somehow configure my response to them the same as what it was with axis1.1.1 i.e. without the ns: in the field tags then I'll be able to not force a change on their end. This is what I return back. - ns:getAuthXResponse xmlns:ns=http://edge.avaya.com/xsd; - ns:return type=com.avaya.edge.ResultBean ns:errorCode0/ns:errorCode ns:errorMsgSuccess/ns:errorMsg /ns:return /ns:getAuthXResponse This is what they expect - ns:getAuthXResponse xmlns:ns=http://edge.avaya.com/xsd; - ns:return errorCode xmlns=http://edge.avaya.com/xsd;0/errorCode errorMsg xmlns=http://edge.avaya.com/xsd;Success/errorMsg /ns:return /ns:getAuthXResponse Samir --- Alastair FETTES [EMAIL PROTECTED] wrote: Samir. If your clients can't handle the difference between ns:fieldName xmlns:ns=foo0/ns:fieldName and fieldName xmlns=foo0/fieldName then I wouldn't bother using SOAP or web services. These are equivalent in XML. I can understand suppressing the prefix in regards to efficency and the size of the message but not to support a client that doesn't handle XML properly. Otherwise it's just a glorified text reader... Alastair -Original Message- From: samir shaikh [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 12, 2007 5:31 PM To: axis-user@ws.apache.org Subject: Re: [Axis2] trimming down the xml in axis2 1.3 Martin, You mean using QName in the client code? I'm trying to tune my server to not send back excessive xml. I cannot change the xml I send back to my clients. the extra ns: is causing me trouble after upgrading from axis2 1.1.1 to axis2 1.3 e.g. ns:fieldName0/ns:fieldName. My clients expect fieldName0/fieldName. Samir --- Martin Gainty [EMAIL PROTECTED] wrote: you can always use null..e.g. QName paramQName = new QName(, paramName); M-- - Original Message - From: samir shaikh [EMAIL PROTECTED] To: axis-user@ws.apache.org Sent: Wednesday, December 12, 2007 7:20 PM Subject: RE: [Axis2] trimming down the xml in axis2 1.3 Raghu, Thanks for your help. I tried that out but I want to suppress it on the server. I think WSDL2Java is for generating a client, right? I'm hoping to find some configuration in services.xml or axis2.xml... any idea? Samir --- Raghu Upadhyayula [EMAIL PROTECTED] wrote: Samir, Try WSDL2Java with -sp option to suppress the namespace prefix. Thanks Raghu -Original Message- From: samir shaikh [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 12, 2007 2:20 PM To: axis-user@ws.apache.org Subject: [Axis2] trimming down the xml in axis2 1.3 Hi, I'm trying to trim down the xml exchanged when using a axis2 client and server. Is there a way I can configure the serializer to not prefix namespace with every element e.g. ns:errorCode0/ns:errorCode can just be errorCode0errorCode. Also not send back the additional headers and field types with each call. I was able to do that in Axis1.3 with the wsdd file. Can someone point me to where that is done in Axis2. Thanks a lot. Samir Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
[Axis2] Server response message headers
We are using WSDL-2-Code generated SkeletonInterface/MessageReceiverInOut
classes in our Apache Axis2 v1.3 doc/lit SOAP 1.2 based web service. We are
attempting to set headers for the response message that will be used for
traceability within our SOA system.
From what I can see there is nowhere for us to set headers that will
actually be retained in the response SOAP message. For example, let me show
the simple case of copying input headers to the output message.
snippet
MessageContext inMessageContext =
MessageContext.getCurrentMessageContext();
OperationContext operationContext =
inMessageContext.getOperationContext();
MessageContext outMessageContext =
operationContext.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE
);
org.apache.axis2.description.AxisMessage inMessage =
inMessageContext.getAxisMessage();
org.apache.axis2.description.AxisMessage outMessage =
outMessageContext.getAxisMessage();
for (Iterator it = inMessage.get; it.hasNext();)
{
SOAPHeaderMessage header = (SOAPHeaderMessage )it.next();
outMessage.addSoapHeader(header);
}
/snippet
This code does not seem to work. Also, if I simply add new
SOAPHeaderMessage objects that I create manually I can set their qname, etc
but how do I set the _contents_ of this header?
Example header:
soapenv:Header
Server xmlns=foo.orgbar.server.com/Server
/soapenv:Header
Thanks in advance.
Alastair Fettes
MacDonald, Dettwiler and Associates
afettes at mdacorporation dot com
This e-mail and any attachments are intended solely for the use of the
intended recipient(s) and may contain legally privileged, proprietary and/or
confidential information. Any use, disclosure, dissemination, distribution
or copying of this e-mail and any attachments for any purposes that have not
been specifically authorized by the sender is strictly prohibited. If you
are not the intended recipient, please immediately notify the sender by
reply e-mail and permanently delete all copies and attachments.
The entire content of this e-mail is for information purposes only and
should not be relied upon by the recipient in any way unless otherwise
confirmed in writing by way of letter or facsimile.
RE: log4j use in skeletons
I suggest using commons-logging as your wrapper around log4j.
Make sure to code it for optimization:
if (log.isDebugEnabled())
{
log.log(Message);
}
Things like that.
Cheers.
From: Rachel Primrose [mailto:[EMAIL PROTECTED]
Sent: Monday, December 10, 2007 4:00 PM
To: axis-user@ws.apache.org
Subject: Re: log4j use in skeletons
The only advice I would give is make sure you use the correct levels,
axis2 outputs a lot of debug and info and at some point, perhaps when
you deploy, you may want to lower the amount coming out.
Apart from that, it's just log4j.
On Dec 11, 2007 10:22 AM, Michael Potter [EMAIL PROTECTED] wrote:
Axis2 Crew,
I am interested in adding log4j logging in my hand coded
*skeleton classes.
Does anyone have some hard learned lessons that I can benefit
from?
--
Michael Potter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Kind regards,
Rachel Primrose
E: [EMAIL PROTECTED]
M: 021 969 728
WSDL2C Defects
=msg:MyOperationResponse/ /wsdl:message wsdl:message name=MyException wsdl:part name=body element=msg:MyException/ /wsdl:message wsdl:portType name=MyPortType !-- MyOperation -- wsdl:operation name=MyOperation wsdl:input message=tns:MyOperationRequest/ wsdl:output message=tns:MyOperationResponse/ wsdl:fault message=tns:MyException name=MyException/ /wsdl:operation /wsdl:portType wsdl:binding name=MyPortBinding type=tns:MyPortType soap12:binding transport=http://schemas.xmlsoap.org/soap/http; style=document/ wsdl:operation name=MyOperation soap12:operation soapAction=http://location.org/services/MyOperation; soapActionRequired=true style=document/ wsdl:input soap12:header part=header use=literal message=tns:InterfaceVersion/ soap12:body parts=body use=literal/ /wsdl:input wsdl:output soap12:body parts=body use=literal/ /wsdl:output wsdl:fault name=MyException soap12:body use=literal/ /wsdl:fault /wsdl:operation /wsdl:binding wsdl:service name=MyService wsdl:port name=MySoapPort binding=tns:MyPortBinding wsdl:documentation wsi:Claim conformsTo=http://ws-i.org/profiles/basic/1.0; / /wsdl:documentation soap12:address location=http://location.org// /wsdl:port /wsdl:service /wsdl:definitions === Also note that I believe these same mistakes are made in all three versions of this function that are created dependent upon if it is asyn, sync or mep only. The question is now since the stub generation does not use the header parameters supplied, where abouts can I find an example of setting custom headers on the client side? I.e. I need to add my interface version to the SOAP header but do not know how to do this. Thanks in advance. Alastair Fettes MacDonald, Dettwiler and Associates This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments. The entire content of this e-mail is for information purposes only and should not be relied upon by the recipient in any way unless otherwise confirmed in writing by way of letter or facsimile. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AXIOM as XML Beans alternative
Hi Samisa. I have generated some code successfully but have yet to actually put it to the test. For you and the other team members interest, the tool does not generate code properly for the AIXM 5.0 Release Candidate Schema (http://www.aixm.aero/public/standard_page/download.html) - it gets an invocation target exception. I've up'd the memory allocation and maxperm memory but no avail. I will post a bug report if interested though that schema is quite large and ugly (generated from a rational UML diagram). Cheers, Alastair -Original Message- From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] Sent: Wed 5/30/2007 6:42 PM To: Apache AXIS C User List Subject: Re: AXIOM as XML Beans alternative Alastair FETTES wrote: I have a question about using AXIOM in a slightly different way than the Axis2/C group probably intends. I'm looking for an alternative to XML Beans that I can use in the world of C++ but none of the solutions that I have found have been adequate. With the release of 1.0.0 it got me thinking that I could theoretically just use the AXIOM part of the project. Leave out all the W/S skeletons and stubs and solely use generated OM as my XML Beans alternative. Is this a sane idea? Comments? Concerns? That would be a good idea. There is the ADB (Axis Data Biding) framework that we have implemented in C. You can code generate with ADB support and use that hopefully. Please see: http://ws.apache.org/axis2/c/docs/axis2c_manual.html#wsdl2c Samisa... Thanks in advance. Alastair This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments. The entire content of this e-mail is for information purposes only and should not be relied upon by the recipient in any way unless otherwise confirmed in writing by way of letter or facsimile. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] winmail.dat- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AXIOM as XML Beans alternative
I have a question about using AXIOM in a slightly different way than the Axis2/C group probably intends. I'm looking for an alternative to XML Beans that I can use in the world of C++ but none of the solutions that I have found have been adequate. With the release of 1.0.0 it got me thinking that I could theoretically just use the AXIOM part of the project. Leave out all the W/S skeletons and stubs and solely use generated OM as my XML Beans alternative. Is this a sane idea? Comments? Concerns? Thanks in advance. Alastair This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments. The entire content of this e-mail is for information purposes only and should not be relied upon by the recipient in any way unless otherwise confirmed in writing by way of letter or facsimile.
RE: Namespace problem between header and body
Just a note: I have encountered this problem as well, quite often I'm afraid. This occurred when I was subclassing and specifically seemed to occur when I ref'd elements from a foreign namespace. To work around this I simply included all items in one namespace. Not an ideal approach but it was a work around none the less. I've also noticed an interesting generation quirk on the server side (Axis Java Server) when ref'ing elements from another namespace: fooParent xmlns=foo ns1:barChild xmlns:ns1=bar/ ns2:barChild xmlns:ns2=bar/ ns3:barChild xmlns:ns3=bar/ ns4:barChild xmlns:ns4=bar/ ns5:barChild xmlns:ns5=bar/ /fooParent Was this intentional? Cheers, Alastair -Original Message- From: Dan Ciarniello [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 9:45 AM To: axis-c-user@ws.apache.org Subject: Namespace problem between header and body I am trying to use the wsdl2ws tool to write a C++ client for a web service that I have implemented using Java Axis. I am using Axis-C++ v1.6 and Java Axis v1.2. When making a call using the wsdl2ws generated code, the SOAP envelope sent is, for example, |?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body ns1:getUser xmlns:ns1=http://cityxpress.com/external; ns1:siteinfo ns1:partnercityxpress/ns1:partner ns1:deploymentmaster/ns1:deployment ns1:sitenew_demo/ns1:site /ns1:siteinfo ns1:id123456/ns1:id /ns1:getUser /SOAP-ENV:Body /SOAP-ENV:Envelope | This is fine but I need to add a header to the envelope so I subclassed the stub and added the following to the constructor: | IHeaderBlock *phb = this-createSOAPHeaderBlock(authinfo, http://cityxpress.com/external;, ai); BasicNode *el_node = phb-createChild(ELEMENT_NODE, user, NULL, http://cityxpress.com/external;, NULL); BasicNode *t_node = phb-createChild(CHARACTER_NODE); t_node-setValue(user); el_node-addChild(t_node); phb-addChild(el_node); el_node = phb-createChild(ELEMENT_NODE, password, NULL, http://cityxpress.com/external;, NULL); t_node = phb-createChild(CHARACTER_NODE); t_node-setValue(pass); el_node-addChild(t_node); phb-addChild(el_node); | Now, when I make the call to the service, the SOAP envelope is |?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Header ai:authinfo xmlns:ai=http://cityxpress.com/external; ai:userusername/ai:user ai:passwordpassword/ai:password /ai:authinfo/SOAP-ENV:Header SOAP-ENV:Body ns1:getUser xmlns:ns1=http://cityxpress.com/external; ns1:siteinfo partnercityxpress/partner deploymentmaster/deployment sitenew_demo/site /ns1:siteinfo ns1:id123456/ns1:id /ns1:getUser /SOAP-ENV:Body /SOAP-ENV:Envelope | Note that the partner, deployment and site subelements of siteinfo have lost their namespace prefix. This means that the web service ignores the values given because the elements are not in the expected namespace. For the sake of comparison, here is the envelope created by a Java version of the client created with WSDL2Java which is understood by the web service: |?xml version=1.0 encoding=UTF-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Header ns1:authinfo soapenv:actor=http://schemas.xmlsoap.org/soap/actor/next; soapenv:mustUnderstand=0 xmlns:ns1=http://cityxpress.com/external; ns1:userusername/ns1:user ns1:passwordpassword/ns1:password /ns1:authinfo /soapenv:Header soapenv:Body getUser xmlns=http://cityxpress.com/external; siteinfo partnercityxpress/partner deploymentmaster/deployment sitenew_demo/site /siteinfo id123456/id /getUser /soapenv:Body /soapenv:Envelope |The obvious question is how do I get the C++ client to generate a SOAP Envelope that is comparable to the one created by the Java client? As an aside, I wanted to try a C client to see if the same problem existed but, though wsdl2ws will generate C-code, there don't seem to be any C libraries that I can link to. Are C libraries missing or is there a way that I can link C code to the C++ libraries? Thanks, Dan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[AxisCPP] Bug in code generation for array types
Title: [AxisCPP] Bug in code generation for array types Using the following sample XSD you can cause the code generation bug: xs:element name=fooParent xs:complexType xs:element ref=tns:fooElement minOccurs=0 maxOccurs=1/ xs:element ref=tns:barElement minOccurs=0 maxOccurs=1/ xs:complexType /xs:element xs:element name=fooElement type=tns:fooListType/ xs:element name=barElement type=tns:fooListType/ xs:complexType name=fooListType xs:sequence !-- some content here -- /xs:sequence /xs:complexType fooListType_Array.hpp/.cpp is correctly created (and used correctly). However, in the portType generated class file it attempts to #include fooElement_Array.hpp. This is incorrect and is a bug. Cheers, Alastair Fettes This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments. The entire content of this e-mail is for information purposes only and should not be relied upon by the recipient in any way unless otherwise confirmed in writing by way of letter or facsimile.
RE: Namespace problem between header and body
Hrm, that wasn't what was causing my problems. I wasn't even using the header section when I got this. I simply found a work around that worked for me and stuck with it. Good luck and hopefully this gets looked in to. Alastair -Original Message- From: Dan Ciarniello [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 2:37 PM To: Apache AXIS C User List Subject: Re: Namespace problem between header and body Alastair FETTES wrote: Just a note: I have encountered this problem as well, quite often I'm afraid. This occurred when I was subclassing and specifically seemed to occur when I ref'd elements from a foreign namespace. To work around this I simply included all items in one namespace. Not an ideal approach but it was a work around none the less. But all elements are in the same namespace. If I modify the header so that it's in a different namespace then I get: |?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Header ai:authinfo xmlns:ai=http://cityxpress.com; ai:userdciarniello/ai:user ai:passwordadmin/ai:password /ai:authinfo /SOAP-ENV:Header SOAP-ENV:Body ns1:getUser xmlns:ns1=http://cityxpress.com/external; ns1:siteinfo ns1:partnercityxpress/ns1:partner ns1:deploymentmaster/ns1:deployment ns1:sitenew_demo/ns1:site /ns1:siteinfo ns1:id123456/ns1:id /ns1:getUser /SOAP-ENV:Body /SOAP-ENV:Envelope | The namespace prefix is now back on the siteinfo subelements. For some reason, the value of the namespace in the authinfo element in the header affects the way that the siteinfo element is serialized in the body. Dan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Axis2][ANN] Apache Axis2/C 0.93 Released
Early feedback: The WSDL2C tool would be useful before 1.0. This would allow (potential) users, such as myself, a chance to try things out. Cheers, Alastair -Original Message- From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] Sent: Friday, September 01, 2006 4:18 PM To: Apache AXIS C Developers List; axis-c-user@ws.apache.org Subject: [Axis2][ANN] Apache Axis2/C 0.93 Released We are pleased to announce the release of Apache Axis2/C version 0.93. You can download this release from http://ws.apache.org/axis2/c/download.cgi Key Features 1. AXIOM, an XML object model optimized for SOAP 1.1/1.2 Messages. This has complete XML infoset support. 2. Support for one-way messaging (In-Only) and request response messaging (In-Out) 3. Description hierarchy (configuration, service groups, services, operations and messages) 4. Directory based deployment model 5. Archive based deployment model 6. Context hierarchy (corresponding contexts to map to each level of description hierarchy) 7. Raw XML message receiver 8. Module architecture, mechanism to extend the SOAP processing model 9. Module version support 10. Transports supports: HTTP o Both simple axis server and Apache2 httpd module for server side o Client transport with ability to enable SSL support 11. Service client and operation client APIs 12. REST support (HTTP POST case) 13. WS-Addressing, both the submission (2004/08) and final (2005/08) versions 14. MTOM/XOP support 15. Code generation tool for stub and skeleton generation for a given WSDL (based on Java tool) o Axis Data Binding (ADB) support 16. Security module with UsernameToken support 17. REST support (HTTP GET case) - New 18. Dynamic invocation support (based on XML schema and WSDL implementations) - New Major Changes Since Last Release 1. REST support for HTTP GET case 2. XML Schema implementation 3. Woden/C implementation that supports both WSDL 1.1 and WSDL 2.0 4. Dynamic client invocation (given a WSDL, consume services dynamically) 5. Numerous improvements to API and API documentation 6. Many bug fixes, especially, many paths of execution previously untouched were tested along with Sandesha2/C implementation TODOs Remaining for 1.0 1. Complete API documentation and API improvements 2. Fix major memory leaks 3. Test codegen for both ADB and none cases 4. Put in place a comprehensive functional test framework 5. WSDL2C tool We welcome your early feedback on this implementation. Thanks for your interest in Axis2C -- Apache Axis2C Team -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NullPointerException on invalid URI
Title: NullPointerException on invalid URI We've encountered a null pointer exception when initializing a generated object constructor const char* pchEndpointUri with an invalid URI such as foo. If you have http:// it works fine, as well as any other URI that doesn't actually have a resource there. Has this been noted before? As for my experience with attributes I've unfortunately just had to leave them behind as they were preventing me from proceeding. Is there any plan to support attributes in future versions? Has anyone added a unit test that checks specifically for these in both java and c++? Thanks, Alastair Fettes This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments. The entire content of this e-mail is for information purposes only and should not be relied upon by the recipient in any way unless otherwise confirmed in writing by way of letter or facsimile.
[Axis] Null message contents with AXISCPP
I'm currently having a problem running the Axis-C 1.6b.
All environment settings have been set as appropriate and I am able to
run *simple* methods. I.e. The echoString test case works for me (see
attached wsdl). I am correctly able to send the value out and retrieve
the mssage back. However, when I try to run more complex services I run
into problems. I.e. echoMessageFromString (see attached wsdl).
Attached is a copy of my WSDL. Server side is java and I have tested it
through the URL interface and visibily inspected the response XML to be
the following:
?xml version=1.0 encoding=UTF-8?
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
soapenv:Body
echoMessageFromStringResponse
soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
returnMessage href=#id0/
/echoMessageFromStringResponse
multiRef id=id0 soapenc:root=0
soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
xsi:type=ns1:messageOutputType
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:ns1=http://foo.com/;
attr3 xsi:type=xsd:stringmy attribute value 3/attr3
attr4 xsi:type=xsd:stringmy attribute value 4/attr4
/multiRef
/soapenv:Body
/soapenv:Envelope
This is as expected therefore I am not worried about the java-server
side (other than the lack of default namespace and the foo.com namespace
declared top level). The problem lies on the cpp-client side.
The following bit of (generated) code always returns null:
messageOutputType* foo::echoMessageFromString(xsd__string Value0)
{
...
pReturn = (messageOutputType *) m_pCall-getCmplxObject(
(void *) Axis_DeSerialize_messageOutputType,
(void *) Axis_Create_messageOutputType,
(void *) Axis_Delete_messageOutputType,
returnMessage,
0);
...
}
Another problem is when I switch from using child elements to attributes
for transfer of data. I run into problems that Axis is unable to
serialize/deserialize the messages in this case. The following is an
example of a schema type that I have encountered this problem with:
xs:complexType name=messageOutputType
xs:sequence/
xs:attribute name=attr3 type=xs:string/
xs:attribute name=attr4 type=xs:string/
/xs:complexType
All problems are occuring on the CPP side mind you. To sum up what this
means is I'm able to pass strings and other simple types back and forth
but not (slightly) more complex messages, rending the CPP side useless
for me. I could use Axis2 but have had no luck with code generation on
that side (see [Axis2] Code generation to C email from 2/8/2006).
Any help would be most appreciated.
Cheers,
Alastair
This e-mail and any attachments are intended solely for the use of the
intended recipient(s) and may contain legally privileged, proprietary
and/or confidential information. Any use, disclosure, dissemination,
distribution or copying of this e-mail and any attachments for any
purposes that have not been specifically authorized by the sender is
strictly prohibited. If you are not the intended recipient, please
immediately notify the sender by reply e-mail and permanently delete all
copies and attachments.
The entire content of this e-mail is for information purposes only and
should not be relied upon by the recipient in any way unless otherwise
confirmed in writing by way of letter or facsimile.
example.wsdl
Description: example.wsdl
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis] xs:simpleType mapped to class file
Title: [Axis] xs:simpleType mapped to class file This occurs with WSDL to C++ generation in Axis 1.6b. Alastair Fettes [EMAIL PROTECTED] ext. 2507 This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments. The entire content of this e-mail is for information purposes only and should not be relied upon by the recipient in any way unless otherwise confirmed in writing by way of letter or facsimile.
Recall: [Axis] xs:simpleType mapped to class file
Title: Recall: [Axis] xs:simpleType mapped to class file Alastair FETTES would like to recall the message, [Axis] xs:simpleType mapped to class file.
[Axis2] Code generation to C
I've modified the WSDL2Code.bat file from the latest snapshot of the Java trunk. I've changed the code gen call to be: %_RUNJAVA% %JAVA_OPTS% -cp %AXIS2_CLASS_PATH% org.apache.axis2.wsdl.WSDL2Code -D org.apache.adb.properties=/org/apache/axis2/schema/c-schema-compile.prop erties -l c -uri %1 -d none Where %1 is the paramterized name of the wsdl file that I pass in to the batch script. I am trying to convert the attached two files but without luck. 1. Versions.wsdl (this is the exact wsdl that is served from the Axis2 java installation running on Tomcat): stackTrace org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name getVersion with namespace http://axisversion.sample/xsd at org.apache.axis2.wsdl.databinding.TypeMappingAdapter.getTypeMappingNa me(TypeMappingAdapter.java:73) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEm itter.getInputParamElement(AxisServiceBasedMultiLanguageEmitter.java:185 5) at org.apache.axis2.wsdl.codegen.emitter.CEmitter.getInputParamElement(C Emitter.java:350) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEm itter.getInputElement(AxisServiceBasedMultiLanguageEmitter.java:1713) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEm itter.loadOperations(AxisServiceBasedMultiLanguageEmitter.java:1454) at org.apache.axis2.wsdl.codegen.emitter.CEmitter.createDOMDocumentForIn terfaceImplementation(CEmitter.java:224) at org.apache.axis2.wsdl.codegen.emitter.CEmitter.writeCStubSource(CEmit ter.java:104) at org.apache.axis2.wsdl.codegen.emitter.CEmitter.emitStub(CEmitter.java :46) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGener ationEngine.java:224) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32) /stackTrace 2. echoTest.wsdl (a wsdl provided by the axis 1 installation). stackTrace Exception in thread main org.apache.axis2.wsdl.codegen.CodeGenerationException : Error parsing WSDL at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.init(CodeGenerat ionEngine.java:123) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32) Caused by: org.apache.axis2.AxisFault: null; nested exception is: java.lang.NullPointerException at org.apache.axis2.description.WSDL11ToAxisServiceBuilder.populateServi ce(WSDL11ToAxisServiceBuilder.java:234) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.init(CodeGenerat ionEngine.java:114) ... 1 more Caused by: java.lang.NullPointerException at org.apache.axis2.description.WSDL11ToAxisServiceBuilder.populateSchem aMap(WSDL11ToAxisServiceBuilder.java:247) at org.apache.axis2.description.WSDL11ToAxisServiceBuilder.populateServi ce(WSDL11ToAxisServiceBuilder.java:189) ... 2 more /stackTrace So some questions: 1. Why am I getting these errors? 2. Are you going to simplify this process for conversion in a similar fashion to Axis1. 3. When will this be included in an actual release of either Axis2 java or c? Thanks in advance. Alastair This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments. The entire content of this e-mail is for information purposes only and should not be relied upon by the recipient in any way unless otherwise confirmed in writing by way of letter or facsimile. version.wsdl echoTest.wsdl version.wsdl Description: version.wsdl echoTest.wsdl Description: echoTest.wsdl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
