Re: Advantages of Axis2 over Axis 1.3
And just to clarify the assertion made on Axis1: Support for WS-Addressing and asynchronous requests has been added in the current SVN code, after the release of 1.4, and AFAIK it has not been released yet. Definetely, it was not present in Axis 1.3, which is the one I assume this thread is about ;-) Cheers, Rodrigo Demetris G wrote: Gotcha. Thanks for the clarification Paul - and no harm done. Paul Fremantle wrote: Yes Axis2 supports Async. My mistake wasn't about Axis2! My mistake was that I implied that Axis1 didn't do it. Paul On 5/4/07, Demetris G [EMAIL PROTECTED] wrote: Paul - I thought you were referring to the advantages of Axis2. So that we don't confuse one too many people, Axis2 does support Async mode - is that correct ? Doug Davis wrote: Paul Fremantle [EMAIL PROTECTED] wrote on 05/04/2007 06:17:43 AM: ... * Asynchronous calling model * Better support for WS-Addressing Current axis1 code does support async and both versions of WS-Addressing (2004,2005) -Doug - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AbstractHTTPSender not releasing connection
Dims, what do you mean? Maybe there has been a misunderstanding, I'll try to restate the issue. You suggested me to cache the operation context, then to get the message context and thus clean up the resources, right? When should I call messageContext.getTransportOut().getSender().cleanup(messageContext); ?, just after sending the request, i.e. sender.invokeNonBlocking(request, callback); // get the msg. context and cleanup, as mentioned above or sender.invokeNonBloking(request, callback); and in callback.onComplete/onError free the resources? I've tried the second way (i.e. the resources are freed only when the response is received), without success. The first way, if NIO sockets are used (but I think it's not the case of Axis2, at least a present) has the potential problem of closing the connection before the message is effectively sent (because of the asynchronous communication). Does it make sense? I'll try the first method as well, but I guess I won't solve the problem because after just a few minutes netstat shows a huge number of connections in CLOSE_WAIT (about 1000). Michele On 4 May 2007, at 21:10, Davanum Srinivas wrote: Do you have a stripped down test? thanks, dims On 5/4/07, Michele Mazzucco [EMAIL PROTECTED] wrote: I've tried it (see my previous post), but with no success :(. BTW, since I'm using asynchronous invocations (with a separate channel for responses) I guess the connection should be closes immediately after sending the request, not after receiving the response. Am I right? Michele On 4 May 2007, at 20:41, Davanum Srinivas wrote: Resending email...somehow this did not make it to the list. Can you please try this? -- dims -- Forwarded message -- From: Davanum Srinivas [EMAIL PROTECTED] Date: May 4, 2007 11:25 AM Subject: Re: AbstractHTTPSender not releasing connection To: axis-user@ws.apache.org Ok then try this tactic. Can you get hold of the OperationContext for each invocation? Typically you can use myServiceContext.getLastOperationContext() to get the last OperationContext. You will have to start caching them though by calling myServiceClient.setCachingOperationContext(true) or you can create the OperationContext by calling myServiceContext.createOperationContext as well. Either way after the invocation is done you can call the following snippet to cleanup the HttpMethod. myOperationContext.getMessageContext (WSDLConstants.MESSAGE_LABEL_OUT_VALUE); _messageContext.getTransportOut().getSender().cleanup (_messageContext); thanks, dims On 5/4/07, Michele Mazzucco [EMAIL PROTECTED] wrote: Dims, what do you mean by calling the complete method?. In this scenario I'm using simple ServiceClient(s) sharing the same conf. context and attached to custom callbacks (I'm reusing the same ServiceClients for thousands of asynchronous requests). For my knowledge (see the link below) the cleanup (on the ServiceClient) should be called only at the end which, as I said, is after receiving thousands of responses. Are you then suggesting me to share an OperationClient for all my requests and to free resources as soon as I receive the response? Thanks, Michele - 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] -- Davanum Srinivas :: http://davanum.wordpress.com - 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] Re: XMLBeans, Attachments and Rampart
Hi Dennis, Thanks for the information. I wonder if there is a limit on the size of attachments only when I want to encrypt them because in some cases I don't need to do it and AFAIK, with rampart you can choose which parts you want to encrypt. A question for Thilina: When a client invokes a method from my Axis2 Web Service and the response message is going to be very big, so I use http chunking: Does axis build all the message at once in memory and then break it pieces?? I possible to build each part in memory and send it, release memory and build - send the next one?? I'm having some memory issues after invoking some methods that build big messages. I'm using Axis2 under Tomcat and the memory size ot Tomcat increases from 50 MB to 300 MB and I didn't see it decreasing. Thanks and regards, Jorge Fernández Dennis Sosnoski [EMAIL PROTECTED] escribió: Hi Jorge, I haven't verified Rampart handling of attachments, but based on what I've seen in other cases I suspect it will build an in-memory representation of the entire document (including attachments, as embedded base64 text) any time Rampart is engaged for a service. This should really only be necessary when you're signing or encrypting the body, but in my trials Rampart built the in-memory tree even when just adding timestamps. The reason why the attachments need to be part of the tree goes back to the design of XOP/MTOM and WS-Security. Attachments using XOP/MTOM are treated just as if they were embedded directly in the XML document, using base64 encoding - MTOM is *only* a transport level optimization. This means that when you use WS-Security you need to have a view of the document with the attachments present as the base64 strings. AFAIK there's no way around this issue, since it was by design. It would be possible in theory for the WS-Security implementation to be smart about handling attachments, and basically just generate a streaming version of the base64 representation for the attachment data as needed when signing (digesting, actually) or encrypting. But this would require changes all the way down to the underlying XML Signature and XML Encryption implementations, and I'd suspect such changes are unlikely to occur without a lot of user demand. In the meantime, I suspect the practical limit for attachment size with Rampart engaged will be somewhere in the 10 MB range. - Dennis Dennis M. Sosnoski SOA and Web Services in Java Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 Jorge Fernandez wrote: Hi again, I didn't have answer for my question. So I'll try again. My problem is that I was using XMLBeans for my project. But XMLBeans doesn't support MTOM. So I tried to use ADB but I have some problems with the mapping of my objects to xml so I would like keep using XMLBeans. Also I want to secure my message also and I found that Rampart and MTOM have memory problems. This are my questions: - When I used ADB and MTOM I could see that if I don't enable MTOM, the attachment is sent in binary code as a String inside de SOAP message but if I enable MTOM, it's send outside the message in clear text (I used an xml file as example of attachment). I would like to send the attachment outside the message in binary code. Is this possible?? - I know that MTOM is better than SwA, but what are the reasons? - Is there any limit in the size of messages that axis2 can send, I mean in both the envelope and as attachments?? I'll have to send huge arrays of int or other data. I'll have to send some of them as attachments to avoid the multiple tags the xml would generate. - The last one: As I'm building big messages, I'm having memory problems and I would like to know if axis can build this messages in parts, like build the first part of the message when it reach a limit size and send it, then build another one and send it.. Any help will be appreciated. Thanks in advance, Jorge Fernández */Jorge Fernandez /* escribió: Hi all, I would like to know if it's possible to use XMLBeans and Rampart with attachtments cos I heard that XMLBeans doesn't support MTOM and I doubt if Rampart supports SwA or there is any problem in that combination. Thanks and regards, Jorge Fernández LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
RE: [Axis2] Re: XMLBeans, Attachments and Rampart
Also the last thing I would like to know is how can I transfer a short array because in the xml it generates lots of tags so I thought of sending it as an attachment but I think that I have to transform it to I byte array, am I right? Is it possible to transfer it as an attachment without having to transform it?? Jorge Fernandez [EMAIL PROTECTED] escribió: Hi Dennis, Thanks for the information. I wonder if there is a limit on the size of attachments only when I want to encrypt them because in some cases I don't need to do it and AFAIK, with rampart you can choose which parts you want to encrypt. A question for Thilina: When a client invokes a method from my Axis2 Web Service and the response message is going to be very big, so I use http chunking: Does axis build all the message at once in memory and then break it pieces?? I possible to build each part in memory and send it, release memory and build - send the next one?? I'm having some memory issues after invoking some methods that build big messages. I'm using Axis2 under Tomcat and the memory size ot Tomcat increases from 50 MB to 300 MB and I didn't see it decreasing. Thanks and regards, Jorge Fernández Dennis Sosnoski [EMAIL PROTECTED] escribió: Hi Jorge, I haven't verified Rampart handling of attachments, but based on what I've seen in other cases I suspect it will build an in-memory representation of the entire document (including attachments, as embedded base64 text) any time Rampart is engaged for a service. This should really only be necessary when you're signing or encrypting the body, but in my trials Rampart built the in-memory tree even when just adding timestamps. The reason why the attachments need to be part of the tree goes back to the design of XOP/MTOM and WS-Security. Attachments using XOP/MTOM are treated just as if they were embedded directly in the XML document, using base64 encoding - MTOM is *only* a transport level optimization. This means that when you use WS-Security you need to have a view of the document with the attachments present as the base64 strings. AFAIK there's no way around this issue, since it was by design. It would be possible in theory for the WS-Security implementation to be smart about handling attachments, and basically just generate a streaming version of the base64 representation for the attachment data as needed when signing (digesting, actually) or encrypting. But this would require changes all the way down to the underlying XML Signature and XML Encryption implementations, and I'd suspect such changes are unlikely to occur without a lot of user demand. In the meantime, I suspect the practical limit for attachment size with Rampart engaged will be somewhere in the 10 MB range. - Dennis Dennis M. Sosnoski SOA and Web Services in Java Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 Jorge Fernandez wrote: Hi again, I didn't have answer for my question. So I'll try again. My problem is that I was using XMLBeans for my project. But XMLBeans doesn't support MTOM. So I tried to use ADB but I have some problems with the mapping of my objects to xml so I would like keep using XMLBeans. Also I want to secure my message also and I found that Rampart and MTOM have memory problems. This are my questions: - When I used ADB and MTOM I could see that if I don't enable MTOM, the attachment is sent in binary code as a String inside de SOAP message but if I enable MTOM, it's send outside the message in clear text (I used an xml file as example of attachment). I would like to send the attachment outside the message in binary code. Is this possible?? - I know that MTOM is better than SwA, but what are the reasons? - Is there any limit in the size of messages that axis2 can send, I mean in both the envelope and as attachments?? I'll have to send huge arrays of int or other data. I'll have to send some of them as attachments to avoid the multiple tags the xml would generate. - The last one: As I'm building big messages, I'm having memory problems and I would like to know if axis can build this messages in parts, like build the first part of the message when it reach a limit size and send it, then build another one and send it.. Any help will be appreciated. Thanks in advance, Jorge Fernández */Jorge Fernandez /* escribió: Hi all, I would like to know if it's possible to use XMLBeans and Rampart with attachtments cos I heard that XMLBeans doesn't support MTOM and I doubt if Rampart supports SwA or there is any problem in that combination. Thanks and regards, Jorge Fernández LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto.
Re: AbstractHTTPSender not releasing connection
I did mean the 2nd way. Could you please share your test case so that i can try to recreate the problem? thanks, dims On 5/5/07, Michele Mazzucco [EMAIL PROTECTED] wrote: Dims, what do you mean? Maybe there has been a misunderstanding, I'll try to restate the issue. You suggested me to cache the operation context, then to get the message context and thus clean up the resources, right? When should I call messageContext.getTransportOut().getSender().cleanup(messageContext); ?, just after sending the request, i.e. sender.invokeNonBlocking(request, callback); // get the msg. context and cleanup, as mentioned above or sender.invokeNonBloking(request, callback); and in callback.onComplete/onError free the resources? I've tried the second way (i.e. the resources are freed only when the response is received), without success. The first way, if NIO sockets are used (but I think it's not the case of Axis2, at least a present) has the potential problem of closing the connection before the message is effectively sent (because of the asynchronous communication). Does it make sense? I'll try the first method as well, but I guess I won't solve the problem because after just a few minutes netstat shows a huge number of connections in CLOSE_WAIT (about 1000). Michele On 4 May 2007, at 21:10, Davanum Srinivas wrote: Do you have a stripped down test? thanks, dims On 5/4/07, Michele Mazzucco [EMAIL PROTECTED] wrote: I've tried it (see my previous post), but with no success :(. BTW, since I'm using asynchronous invocations (with a separate channel for responses) I guess the connection should be closes immediately after sending the request, not after receiving the response. Am I right? Michele On 4 May 2007, at 20:41, Davanum Srinivas wrote: Resending email...somehow this did not make it to the list. Can you please try this? -- dims -- Forwarded message -- From: Davanum Srinivas [EMAIL PROTECTED] Date: May 4, 2007 11:25 AM Subject: Re: AbstractHTTPSender not releasing connection To: axis-user@ws.apache.org Ok then try this tactic. Can you get hold of the OperationContext for each invocation? Typically you can use myServiceContext.getLastOperationContext() to get the last OperationContext. You will have to start caching them though by calling myServiceClient.setCachingOperationContext(true) or you can create the OperationContext by calling myServiceContext.createOperationContext as well. Either way after the invocation is done you can call the following snippet to cleanup the HttpMethod. myOperationContext.getMessageContext (WSDLConstants.MESSAGE_LABEL_OUT_VALUE); _messageContext.getTransportOut().getSender().cleanup (_messageContext); thanks, dims On 5/4/07, Michele Mazzucco [EMAIL PROTECTED] wrote: Dims, what do you mean by calling the complete method?. In this scenario I'm using simple ServiceClient(s) sharing the same conf. context and attached to custom callbacks (I'm reusing the same ServiceClients for thousands of asynchronous requests). For my knowledge (see the link below) the cleanup (on the ServiceClient) should be called only at the end which, as I said, is after receiving thousands of responses. Are you then suggesting me to share an OperationClient for all my requests and to free resources as soon as I receive the response? Thanks, Michele - 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] -- Davanum Srinivas :: http://davanum.wordpress.com - 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] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Re: XMLBeans, Attachments and Rampart
Hi Jorge, My understanding of how Rampart works now is that if you do *any* security processing on your service it will always build the full model of the document in memory. Chunking is not going to effect this at all. - Dennis Dennis M. Sosnoski SOA and Web Services in Java Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 Jorge Fernandez wrote: Hi Dennis, Thanks for the information. I wonder if there is a limit on the size of attachments only when I want to encrypt them because in some cases I don't need to do it and AFAIK, with rampart you can choose which parts you want to encrypt. A question for Thilina: When a client invokes a method from my Axis2 Web Service and the response message is going to be very big, so I use http chunking: Does axis build all the message at once in memory and then break it pieces?? I possible to build each part in memory and send it, release memory and build - send the next one?? I'm having some memory issues after invoking some methods that build big messages. I'm using Axis2 under Tomcat and the memory size ot Tomcat increases from 50 MB to 300 MB and I didn't see it decreasing. Thanks and regards, Jorge Fernández */Dennis Sosnoski [EMAIL PROTECTED]/* escribió: Hi Jorge, I haven't verified Rampart handling of attachments, but based on what I've seen in other cases I suspect it will build an in-memory representation of the entire document (including attachments, as embedded base64 text) any time Rampart is engaged for a service. This should really only be necessary when you're signing or encrypting the body, but in my trials Rampart built the in-memory tree even when just adding timestamps. The reason why the attachments need to be part of the tree goes back to the design of XOP/MTOM and WS-Security. Attachments using XOP/MTOM are treated just as if they were embedded directly in the XML document, using base64 encoding - MTOM is *only* a transport level optimization. This means that when you use WS-Security you need to have a view of the document with the attachments present as the base64 strings. AFAIK there's no way around this issue, since it was by design. It would be possible in theory for the WS-Security implementation to be smart about handling attachments, and basically just generate a streaming version of the base64 representation for the attachment data as needed when signing (digesting, actually) or encrypting. But this would require changes all the way down to the underlying XML Signature and XML Encryption implementations, and I'd suspect such changes are unlikely to occur without a lot of user demand. In the meantime, I suspect the practical limit for attachment size with Rampart engaged will be somewhere in the 10 MB range. - Dennis Dennis M. Sosnoski SOA and Web Services in Java Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117 Jorge Fernandez wrote: Hi again, I didn't have answer for my question. So I'll try again. My problem is that I was using XMLBeans for my project. But XMLBeans doesn't support MTOM. So I tried to use ADB but I have some problems with the mapping of my objects to xml so I would like keep using XMLBeans. Also I want to secure my message also and I found that Rampart and MTOM have memory problems. This are my questions: - When I used ADB and MTOM I could see that if I don't enable MTOM, the attachment is sent in binary code as a String inside de SOAP message but if I enable MTOM, it's send outside the message in clear text (I used an xml file as example of attachment). I would like to send the attachment outside the message in binary code. Is this possible?? - I know that MTOM is better than SwA, but what are the reasons? - Is there any limit in the size of messages that axis2 can send, I mean in both the envelope and as attachments?? I'll have to send huge arrays of int or other data. I'll have to send some of them as attachments to avoid the multiple tags the xml would generate. - The last one: As I'm building big messages, I'm having memory problems and I would like to know if axis can build this messages in parts, like build the first part of the message when it reach a limit size and send it, then build another one and send it.. Any help will be appreciated. Thanks in advance, Jorge Fernández */Jorge Fernandez /* escribió: Hi all, I would like to know if it's possible to use XMLBeans and Rampart with
Re: WSDL2Java: WSDLProcessingException: Encoded use is not supported?
Stefan, There were a number of reasons why the Axis2 team decided not to implement support for SOAP encoding: 1- it's prohibited by WS-I Basic Profile 2- SOAP encoding is an optional feature in SOAP 1.2 3- It would have been a ton of work to implement support for a feature that is being deprecated by the standards community. 4- There are still tons of other more useful features to be implemented that have a higher priority. If you need to maintain use of SOAP encoding, you should stick with Axis 1.x. If you want to migrate to Axis2, you will have to convert the service to either document/literal or rpc/literal. The easier conversion is to rpc/literal, but I advise against that, because there are still many environments that don't support it (especially .Net 1.x). To convert to rpc/literal, simply change all instances of use=encoded to use=literal and remove the encodingStyle attribute from the bindings. You should also review all your type definitions, and convert any soap encoding types to schema types (e.g., type=soapenc:string to type=xsd:string), and convert all soap encoding arrays to simple XSD arrays defined using maxOccurs=unbounded. The conversion to document/literal requires the following: - change style=rpc to style=document - change use=encoded to use=literal - remove the namespace and encodingStyle attributes from the bindings - define wrapper elements for all your input and output message parameters. Input message elements should be given the same name as the operation. Output message elements should be given a name in the form of methodNameResponse. Each element should be defined as a sequence containing elements of the types you've currently defined as your message parts. - remove all your current message parts and replace them with a single message part referencing your newly defined wrapper elements. For example: Current message description: w:message name=fooMethodRequest w:part name=foo1 type=s:string/ w:part name=foo2 type=s:int/ /w:message Should be change to this: w:types s:schema targetNamespace=urn:foo:types xmlns:ns1=urn:foo:types s:element name=fooMethod s:complexType s:sequence s:element name=foo1 type=s:string/ s:element name=foo2 type=s:int/ /s:sequence /s:complexType /s:element /s:schema /w:types w:message name=fooMethodRequest w:part name=parameters element=ns1:fooMethod/ /w:message Anne On 5/3/07, stefan_dragnev [EMAIL PROTECTED] wrote: Dims, I'm sure the wsdl uses rpc/encoded because it contains the following section: binding name=WebServiceSoap type=s0:WebServiceSoap soap:binding transport=http://schemas.xmlsoap.org/soap/http; style=document/ operation name=UpdateCategoriesReq soap:operation soapAction=http://www.openuri.org/UpdateCategoriesReq; style=rpc/ input soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /input output soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /output /operation operation name=BPDataReq soap:operation soapAction=http://www.openuri.org/BPDataReq; style=rpc/ input soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /input output soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /output /operation .. /binding I know that rpc/encoded is not supported in WS-I basic profile but this WSDL was developed some time ago and is used in production so I'm not sure whether I will be allowed to modify. If I'm allowed to modify it what will be the best way to do it so Axis2 1.2's wsdl2java will not throw errors? Thanks. Stefan I believe we are throwing better exceptions now...if you post the wsdl in a bug report, we can take a look to confirm that it is indeed an rpc/encoded wsdl which we don't support. thanks, dims -- View this message in context: http://www.nabble.com/WSDL2Java%3A-WSDLProcessingException%3A-Encoded-use-is-not-supported--tf3678548.html#a10312820 Sent from the Axis - User mailing list archive at Nabble.com. - 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: Sequence of choices, or no serializer for AnyType
Try using Axis2 with the XMLBeans databinding.
On 5/4/07, Axel Bock [EMAIL PROTECTED] wrote:
Hi list,
Using Axis 1.4 I ran into a very annoying problem, based on this thing in my
web service schema:
element name=SignDocumentResponse
complexType
sequence
element ref=C:Status/
element name=DocumentList minOccurs=0
complexType
choice maxOccurs=unbounded
element name=Document type=base64Binary/
element name=Deselected/
/choice
/complexType
/element
/sequence
/complexType
/element
Now every time axis tries to parse the answer with more than one element in
the DocumentList type I get the following error:
No deserializer for
{http://www.w3.org/2001/XMLSchema}anyTypeorg.xml.sax.SAXException:
No deserializer for {
http://www.w3.org/2001/XMLSchema}anyType
I found a post concerning that topic back from 2002, which basically said
bad luck, axis does not do this. (see here:
http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200204.mbox/[EMAIL
PROTECTED]
).
I tried to change the choise(0..n) thing to a sequence(0..n)--choice thing,
or a sequence(1)--choice(0..n) thing, but both did not help. I had a look
into the stubs and they always look the same - they only seem to expect ONE
sub-element under DocumentList.
This is ... well, kind of mission-critical for us here, so I would be
thankful for every suggestion.
cheers thanks in advance,
Axel.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSDL2Java: WSDLProcessingException: Encoded use is not supported?
Dims, It is a service which currently runs on BEA Weblogic but we are migrating to open source. The plan was to migrate it to Axis2. Since Axis2 v1.1.1 was not throwing exceptions I was able to generate skeleton and stub files using WSDL with rpc/encoded bindings. Then I wrote, compiled and deployed a service using XMLBeans binding but when I deployed on the server I kept getting faults each time when I invoked the service. That's when I saw Axis 1.2 is already release and thought that it might solve the problem. It didn't as with 1.2 I could not even generate stubs and skeletons and that is when I wrote for first time to the email list. The WSDL which I inherited and is currently used in production is using rpc/encoded style. I have no control over the client side to make them change their code. But on Friday I modified the WSDL to use rpc/literal style and was able to run wsdl2java on it without any problems. Hopefully the client side will be willing to change their code to use rpc/literal style. I'm using XMLbeans as data binding. What is more efficient when it comes to speed - running a standalone Axis2 server or running it under Tomcat? Are there any advantages using one or the other? Thanks, Stefan Davanum Srinivas wrote: Stefan, Is this an Axis2 based service in production? and you have a custom wsdl? -- dims On 5/3/07, stefan_dragnev [EMAIL PROTECTED] wrote: Dims, I'm sure the wsdl uses rpc/encoded because it contains the following section: binding name=WebServiceSoap type=s0:WebServiceSoap soap:binding transport=http://schemas.xmlsoap.org/soap/http; style=document/ operation name=UpdateCategoriesReq soap:operation soapAction=http://www.openuri.org/UpdateCategoriesReq; style=rpc/ input soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /input output soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /output /operation operation name=BPDataReq soap:operation soapAction=http://www.openuri.org/BPDataReq; style=rpc/ input soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /input output soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /output /operation .. /binding I know that rpc/encoded is not supported in WS-I basic profile but this WSDL was developed some time ago and is used in production so I'm not sure whether I will be allowed to modify. If I'm allowed to modify it what will be the best way to do it so Axis2 1.2's wsdl2java will not throw errors? Thanks. Stefan I believe we are throwing better exceptions now...if you post the wsdl in a bug report, we can take a look to confirm that it is indeed an rpc/encoded wsdl which we don't support. thanks, dims -- View this message in context: http://www.nabble.com/WSDL2Java%3A-WSDLProcessingException%3A-Encoded-use-is-not-supported--tf3678548.html#a10312820 Sent from the Axis - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/WSDL2Java%3A-WSDLProcessingException%3A-Encoded-use-is-not-supported--tf3678548.html#a10341325 Sent from the Axis - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSDL2Java: WSDLProcessingException: Encoded use is not supported?
Stefan, Thanks for the summary. Regarding Axis2 v1.1.1, even though wsdl2java did not complain, the current client would have failed to interop with the generated service. Since the server-side code does not really support rpc/encoded. That's exactly the reason why we throw the exception in Axis2 1.2 so that people are not led down the garden path and then get to know the limitation in the end and get frustrated. Yes, it's better to use rpc/lit. Just make sure the client is not on .NET 1.x which does not support rpc/lit. XMLBeans is a bit slow under some circumstances. But if it works for you, just stick to it. Alternative is to use the ADB (which is the default data binding). I'd definitely run it under Tomcat. SimpleHTTPServer is getting there for production use, but i am more inclined to use tomcat for production purposes. Also FYI, If you decide to switch to ADB, we'd definitely back you up if you run into codegen issues or runtime issues as both are under our control. XMLBeans is a separate project as you know... thanks, dims On 5/5/07, stefan_dragnev [EMAIL PROTECTED] wrote: Dims, It is a service which currently runs on BEA Weblogic but we are migrating to open source. The plan was to migrate it to Axis2. Since Axis2 v1.1.1 was not throwing exceptions I was able to generate skeleton and stub files using WSDL with rpc/encoded bindings. Then I wrote, compiled and deployed a service using XMLBeans binding but when I deployed on the server I kept getting faults each time when I invoked the service. That's when I saw Axis 1.2 is already release and thought that it might solve the problem. It didn't as with 1.2 I could not even generate stubs and skeletons and that is when I wrote for first time to the email list. The WSDL which I inherited and is currently used in production is using rpc/encoded style. I have no control over the client side to make them change their code. But on Friday I modified the WSDL to use rpc/literal style and was able to run wsdl2java on it without any problems. Hopefully the client side will be willing to change their code to use rpc/literal style. I'm using XMLbeans as data binding. What is more efficient when it comes to speed - running a standalone Axis2 server or running it under Tomcat? Are there any advantages using one or the other? Thanks, Stefan Davanum Srinivas wrote: Stefan, Is this an Axis2 based service in production? and you have a custom wsdl? -- dims On 5/3/07, stefan_dragnev [EMAIL PROTECTED] wrote: Dims, I'm sure the wsdl uses rpc/encoded because it contains the following section: binding name=WebServiceSoap type=s0:WebServiceSoap soap:binding transport=http://schemas.xmlsoap.org/soap/http; style=document/ operation name=UpdateCategoriesReq soap:operation soapAction=http://www.openuri.org/UpdateCategoriesReq; style=rpc/ input soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /input output soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /output /operation operation name=BPDataReq soap:operation soapAction=http://www.openuri.org/BPDataReq; style=rpc/ input soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /input output soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /output /operation .. /binding I know that rpc/encoded is not supported in WS-I basic profile but this WSDL was developed some time ago and is used in production so I'm not sure whether I will be allowed to modify. If I'm allowed to modify it what will be the best way to do it so Axis2 1.2's wsdl2java will not throw errors? Thanks. Stefan I believe we are throwing better exceptions now...if you post the wsdl in a bug report, we can take a look to confirm that it is indeed an rpc/encoded wsdl which we don't support. thanks, dims -- View this message in context: http://www.nabble.com/WSDL2Java%3A-WSDLProcessingException%3A-Encoded-use-is-not-supported--tf3678548.html#a10312820 Sent from the Axis - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/WSDL2Java%3A-WSDLProcessingException%3A-Encoded-use-is-not-supported--tf3678548.html#a10341325 Sent from the Axis - User mailing list archive at Nabble.com.
Re: WSDL2Java: WSDLProcessingException: Encoded use is not supported?
Dims, Thanks for the suggestion to use ADB and answering all my other questions. I already read in AIXS2 documentation that ADB is the most stable and the preferred data binding for Axis2. The reason I decided to stick with XMLBeans is the current codebase which I have to port to Axis2 contains couple of thousands lines of code and all of it uses XMLBeans. All this combined with I being new to Axis2 and having a tight deadline made XMLBeans the better choice for now. If time allows I will move everything to ADB later on. Thanks, Stefan Davanum Srinivas wrote: Stefan, Thanks for the summary. Regarding Axis2 v1.1.1, even though wsdl2java did not complain, the current client would have failed to interop with the generated service. Since the server-side code does not really support rpc/encoded. That's exactly the reason why we throw the exception in Axis2 1.2 so that people are not led down the garden path and then get to know the limitation in the end and get frustrated. Yes, it's better to use rpc/lit. Just make sure the client is not on .NET 1.x which does not support rpc/lit. XMLBeans is a bit slow under some circumstances. But if it works for you, just stick to it. Alternative is to use the ADB (which is the default data binding). I'd definitely run it under Tomcat. SimpleHTTPServer is getting there for production use, but i am more inclined to use tomcat for production purposes. Also FYI, If you decide to switch to ADB, we'd definitely back you up if you run into codegen issues or runtime issues as both are under our control. XMLBeans is a separate project as you know... thanks, dims On 5/5/07, stefan_dragnev [EMAIL PROTECTED] wrote: Dims, It is a service which currently runs on BEA Weblogic but we are migrating to open source. The plan was to migrate it to Axis2. Since Axis2 v1.1.1 was not throwing exceptions I was able to generate skeleton and stub files using WSDL with rpc/encoded bindings. Then I wrote, compiled and deployed a service using XMLBeans binding but when I deployed on the server I kept getting faults each time when I invoked the service. That's when I saw Axis 1.2 is already release and thought that it might solve the problem. It didn't as with 1.2 I could not even generate stubs and skeletons and that is when I wrote for first time to the email list. The WSDL which I inherited and is currently used in production is using rpc/encoded style. I have no control over the client side to make them change their code. But on Friday I modified the WSDL to use rpc/literal style and was able to run wsdl2java on it without any problems. Hopefully the client side will be willing to change their code to use rpc/literal style. I'm using XMLbeans as data binding. What is more efficient when it comes to speed - running a standalone Axis2 server or running it under Tomcat? Are there any advantages using one or the other? Thanks, Stefan Davanum Srinivas wrote: Stefan, Is this an Axis2 based service in production? and you have a custom wsdl? -- dims On 5/3/07, stefan_dragnev [EMAIL PROTECTED] wrote: Dims, I'm sure the wsdl uses rpc/encoded because it contains the following section: binding name=WebServiceSoap type=s0:WebServiceSoap soap:binding transport=http://schemas.xmlsoap.org/soap/http; style=document/ operation name=UpdateCategoriesReq soap:operation soapAction=http://www.openuri.org/UpdateCategoriesReq; style=rpc/ input soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /input output soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /output /operation operation name=BPDataReq soap:operation soapAction=http://www.openuri.org/BPDataReq; style=rpc/ input soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /input output soap:body use=encoded namespace=http://www.openuri.org/; encodingStyle=http://schemas.xmlsoap.org/soap/encoding// /output /operation .. /binding I know that rpc/encoded is not supported in WS-I basic profile but this WSDL was developed some time ago and is used in production so I'm not sure whether I will be allowed to modify. If I'm allowed to modify it what will be the best way to do it so Axis2 1.2's wsdl2java will not throw errors? Thanks. Stefan I believe we are throwing better exceptions now...if you post the wsdl in a bug report, we can take a look to confirm that it is indeed an rpc/encoded wsdl which we don't support. thanks, dims -- View this message in context: http://www.nabble.com/WSDL2Java%3A-WSDLProcessingException%3A-Encoded-use-is-not-supported--tf3678548.html#a10312820 Sent from the Axis -
Soap Over JMS using Embedded Axis2 Engine
Anyone able to successfully send Soap messages over JMS using Embedded Axis2 Engine ? Hi Ted, Were you able to get your code to work ? Thanks in Advance Pavan
Re: WSDL2Java: WSDLProcessingException: Encoded use is not supported?
Anne, Thanks a lot for your help. Your explanations were really helpful. I've already switched the style to rpc/literal and removed the encoding attribute, but before reading your message I have missed to remove the soap encoded parts from the types part of the WSDL file. Now I can successfully run wsdl2java from Axis2 and generate skeleton and stubs. Stefan -- View this message in context: http://www.nabble.com/WSDL2Java%3A-WSDLProcessingException%3A-Encoded-use-is-not-supported--tf3678548.html#a10342158 Sent from the Axis - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
