security and request/response format in RESTFUL web services
Hi, All, I am trying to use axis2/c to develop a web service client that will consume RESTFUL web services. I have the following questions: (1) What security mechanisms are supported for consuming restful web services? BASIC authentication (both plainText and Digest)? HTTPS/SSL? and anything else? I assume WS-security does not apply here, right? (2) I also wonder what the format of the request and resposne has to be for consuming RESTFUL web services? Do they have to be in XML format (including html)? or can be just anything like plaintext string or even empty? It seems to be that at least in HTTP GET, all you need is a URL that points to the resource, you really don't need anything in the payload. (3) I am wondering if AXIS2/c can deal with a request with no payload, and in the case of plainText string in the request and respone, how the payload is going to look like. The examples I read from the axis2/c distribution all suggests that an XML format (there are XML tags) is assume for the payload, is this assumption correct? Thanks! Vivian
Re: SOAP styles
Hi http://ws.apache.org/axis/java/reference.html hopefully answers your last question, dont expect bugfixes any more ;-) there is a migration guide for axis1 to axis2 webservices, http://ws.apache.org/axis2/1_5/migration.html dont think there is any special attention to preserving soap-styles however. its really not in the spirit nowadays, see http://ws-i.org/ you didnt mention why you would want to migrate good luck, Wolfgang --- On Fri, 8/28/09, Demetris demet...@ece.neu.edu wrote: From: Demetris demet...@ece.neu.edu Subject: Re: SOAP styles To: axis-dev@ws.apache.org Date: Friday, August 28, 2009, 7:41 PM Well I will certainly push the notion of upgrading the target servers but there are cases where the customer does not want to do that. So we NEED to deal with deprecated styles - so the question will remain if Axis 1.4 can generate one and only or multiple (even if deprecated) styles programmatically? Cheers WJ Krpelan wrote: Hi, all SOAP styles except doc/lit are kind of deprecated by now and are no longer fully supported by most frameworks, if at all. You better migrate everything to doc/lit, resp. doc/lit wrapped I suppose Cheers, Wolfgang --- On Thu, 8/27/09, Demetris demet...@ece.neu.edu wrote: From: Demetris demet...@ece.neu.edu Subject: SOAP styles To: axis-dev@ws.apache.org Date: Thursday, August 27, 2009, 10:10 PM Hi all, we have some legacy systems still using Axis 1.4 and we need clients from them to generate SOAP rpc/lit or doc/lit instead of rpc/enc - does anyone know if the latter is the default for Axis 1.4 and how it can be manipulated programmatically? Thanks Ruwan Linton wrote: On Thu, Aug 27, 2009 at 11:21 PM, Deepal jayasinghe deep...@gmail.com mailto:deep...@gmail.com wrote: No I can't, I guess I have explained why I can't use it as well, because I cannot differentiate the undeployment call for the hot update and real undeployment. Well, what Amila suggested will work though :-) Of course you can if the file is there then that is hot-update else it is un deployment. I propose adding a update method to the Deployer interface or passing the state as an argument, I would consider undeploy as the update method you can do whatever you want there, and you can just ignore at when it call deploy method. (I know in undeploy method you only get the filename, but since your deployer is domain specific you know what to do with the file name) No, the issue is we need to invoke a different code in the case of hot update. Yes, as I mentioned earlier if the file is there then that is hot-update, else un-deployment. So it should not be a big issues. Anyway I feel I should go for a synapse deployer :-) I though you already have deployer for synapse. I mean a new deployer framework implementation, not an deployer.. anyway synapse doesn't have a deployer yet. Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com mailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
[jira] Resolved: (AXIS2-4481) JAX-WS Marshaling is not optimized if xsi:type is requested
[ https://issues.apache.org/jira/browse/AXIS2-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4481. --- Resolution: Fixed JAX-WS Marshaling is not optimized if xsi:type is requested --- Key: AXIS2-4481 URL: https://issues.apache.org/jira/browse/AXIS2-4481 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle Priority: Minor Original Estimate: 24h Remaining Estimate: 24h The JAX-WS engine uses the marshal methods provided by JAX-B. The JAX-B supports marshaling to an XMLStreamWriter or an OutputStream. In most cases, the JAX-WS runtime uses the latter (marshaling to OutputStream). This is accomplished by getting the target OutputStream from the XMLStreamWriter. However, there is one path where this optimization is not being used. This JIRA corrects this path -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4482) WebServiceContext contents persist after the JAX-WS call
WebServiceContext contents persist after the JAX-WS call Key: AXIS2-4482 URL: https://issues.apache.org/jira/browse/AXIS2-4482 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle The @WebServiceContext information is only applicable during the server invocation of the JAX-WS web service message. After the invocation, the resources (ie. soap message) held by the @WebServiceContext should be released so that it can be properly garbage collected. Failure to do this causes a memory leak. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4482) WebServiceContext contents persist after the JAX-WS call
[ https://issues.apache.org/jira/browse/AXIS2-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rich Scheuerle resolved AXIS2-4482. --- Resolution: Fixed The fix and a verification test is provided in revision 809569. WebServiceContext contents persist after the JAX-WS call Key: AXIS2-4482 URL: https://issues.apache.org/jira/browse/AXIS2-4482 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Rich Scheuerle Assignee: Rich Scheuerle The @WebServiceContext information is only applicable during the server invocation of the JAX-WS web service message. After the invocation, the resources (ie. soap message) held by the @WebServiceContext should be released so that it can be properly garbage collected. Failure to do this causes a memory leak. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SOAP styles
Hi Wolfgang, thanks for the good info - I did see some of these links and I will go over them. We have an underlying p2p infrastructure that intercepts the SOAP messages from clients to servers without distrupting the operation of the upper layers ( so the soap enginers and the WS implementations remain as is) and routes them across peers. Now that we are adding mobile peers in the mix, including CXF-based ones, Axis2 ones etc. we are seeing some incompatability issues - for ex. CXF does not handle rcp/encoded styles. So how do you suggest we avoid the migration and manage to handle these issues? Thanks again WJ Krpelan wrote: Hi http://ws.apache.org/axis/java/reference.html hopefully answers your last question, dont expect bugfixes any more ;-) there is a migration guide for axis1 to axis2 webservices, http://ws.apache.org/axis2/1_5/migration.html dont think there is any special attention to preserving soap-styles however. its really not in the spirit nowadays, see http://ws-i.org/ you didnt mention why you would want to migrate good luck, Wolfgang --- On Fri, 8/28/09, Demetris demet...@ece.neu.edu wrote: From: Demetris demet...@ece.neu.edu Subject: Re: SOAP styles To: axis-dev@ws.apache.org Date: Friday, August 28, 2009, 7:41 PM Well I will certainly push the notion of upgrading the target servers but there are cases where the customer does not want to do that. So we NEED to deal with deprecated styles - so the question will remain if Axis 1.4 can generate one and only or multiple (even if deprecated) styles programmatically? Cheers WJ Krpelan wrote: Hi, all SOAP styles except doc/lit are kind of deprecated by now and are no longer fully supported by most frameworks, if at all. You better migrate everything to doc/lit, resp. doc/lit wrapped I suppose Cheers, Wolfgang --- On Thu, 8/27/09, Demetris demet...@ece.neu.edu wrote: From: Demetris demet...@ece.neu.edu Subject: SOAP styles To: axis-dev@ws.apache.org Date: Thursday, August 27, 2009, 10:10 PM Hi all, we have some legacy systems still using Axis 1.4 and we need clients from them to generate SOAP rpc/lit or doc/lit instead of rpc/enc - does anyone know if the latter is the default for Axis 1.4 and how it can be manipulated programmatically? Thanks Ruwan Linton wrote: On Thu, Aug 27, 2009 at 11:21 PM, Deepal jayasinghe deep...@gmail.com mailto:deep...@gmail.com wrote: No I can't, I guess I have explained why I can't use it as well, because I cannot differentiate the undeployment call for the hot update and real undeployment. Well, what Amila suggested will work though :-) Of course you can if the file is there then that is hot-update else it is un deployment. I propose adding a update method to the Deployer interface or passing the state as an argument, I would consider undeploy as the update method you can do whatever you want there, and you can just ignore at when it call deploy method. (I know in undeploy method you only get the filename, but since your deployer is domain specific you know what to do with the file name) No, the issue is we need to invoke a different code in the case of hot update. Yes, as I mentioned earlier if the file is there then that is hot-update, else un-deployment. So it should not be a big issues. Anyway I feel I should go for a synapse deployer :-) I though you already have deployer for synapse. I mean a new deployer framework implementation, not an deployer.. anyway synapse doesn't have a deployer yet. Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com
[jira] Commented: (AXIS2-2326) WSDL2Java generates too many if sentences in MessageReceiver's fromOM method with xmlbeans
[ https://issues.apache.org/jira/browse/AXIS2-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12749549#action_12749549 ] Sudhakar V Chellam commented on AXIS2-2326: --- Hi, Where is this issue resolved. I tried using AXIS1.4.1 and 1.5 version of the code gent, the fromOM method still contains duplicate entries. Due to this I am getting java compiler error ( code too large ) issue. Please let me know where the patch or the fix is. Thanks and Regards Sudhakar WSDL2Java generates too many if sentences in MessageReceiver's fromOM method with xmlbeans -- Key: AXIS2-2326 URL: https://issues.apache.org/jira/browse/AXIS2-2326 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: codegen Affects Versions: 1.1.1 Environment: Windows XP SP2, Java 1.5, Eclipse 3.2.2, Eclipse Axis Plugin 1.2.1 Reporter: Jorge Fernández Assignee: Amila Chinthaka Suriarachchi Priority: Blocker Attachments: API.wsdl, Medici_LinkMessageReceiverInOut.java If I define in a wsdl that different methods are throwing the same exception, in the fromOM method of the MessageReceiver class generated, it appears a if statement for the exception as many times as methods are throwing it. Something similar happens in the generated stub's method populateFaults. Each fault is defined many times, I think as many as methods are throwing them in the skeleton. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2-4477) wsdl2java should only prettify files it has generated itself
[ https://issues.apache.org/jira/browse/AXIS2-4477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIS2-4477. Resolution: Fixed Fix Version/s: 1.6 Committed the patch. wsdl2java should only prettify files it has generated itself Key: AXIS2-4477 URL: https://issues.apache.org/jira/browse/AXIS2-4477 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: codegen Affects Versions: 1.5.1, 1.5, 1.4.1 Reporter: Andreas Veithen Priority: Minor Fix For: 1.6 Attachments: AXIS2-4477.patch.txt, codegen.patch In AXIS2-2947 it was requested to make the prettify feature in wsdl2java more selective, but this has only been done for XML files. The problem still persists for Java files: if the output directory contains Java files that have not been generated by wsdl2java, then these files will be reformatted too. The prettify feature should be strictly limited to files that have been generated by wsdl2java. Additional notes: - The fact that JavaPrettyPrinterExtension scans the entire output directory is the actual root cause of AXIS2-4107. - The change in AXIS2-2947 has a severe design flaw because it changed AbstractPrettyPrinterExtension to limit itself to generated XML files. It should limit itself to files of any type generated by wsdl2java and give subclasses the opportunity to filter these files by type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
