> > I think in summary we are talking of two improvements here: > > 1. Make allowedMethods optional > 2. Drop operationRequestMap >
I have done both the above improvements. Tests are successful. Thanks, Samisa... > Thanks, > Samisa... > > > -----Original Message----- > > From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 16, 2005 2:55 PM > > To: Apache AXIS C Developers List > > Subject: Re: Fw: [jira] Assigned: (AXISCPP-792) Auto generated > deploy.wsdd > > file hasa bug. > > > > Hi John, > > I agree that what you are suggesting is better in terms of > > usability. (I was focusing on how to get rid of SOAPAction, and did > not > > bother about user friendliness of the solution :( ) > > > > Please see more comments below > > > > On Mon, 2005-08-15 at 13:00, John Hawkins wrote: > > > Hi Samisa, > > > > > > OK, so I worked out a way to do this so we avoid putting more > > > configuration burden on the poor user :-) > > > > > > method name Mappings: When we create the Wrapper we can create a new > > > method that gets the mapping from the wrapper. All this information > is > > > in the WSDL right? Then, just before we do init we can ask the > service > > > wrapper for its mappings? What do you think? > > > > As I already said this is a better approach. However I only had a > glance > > at the code so far on how possible this would be. I need a bit more > time > > to come up with the exact solution - may be towards the end of this > > week. > > > > > > > > allowed methods: Does the user have to put this detail in ? What > > > happens if they don't ? > > > > As of now, if there is no allowedMethods entry in server.wsdd, the > > server segfaults. This is because the wsdd parsing assumes that the > > allowedMethods entry must be there. Also, if the method to be invoked > is > > not mentioned in the allowedMethods list the invocation fails. > > > > If we wish so, we could drop this altogether from the server.wsdd. > > > > Thanks, > > Samisa... > > > > > cheers, > > > John. > > > > > > > > > > > > > > > > > > > > > Samisa Abeysinghe > > > <[EMAIL PROTECTED]> > > > > > > 12/08/2005 15:59 > > > Please respond to > > > "Apache AXIS C Developers List" > > > To > > > Apache AXIS C > > > Developers List > > > <[email protected]> > > > cc > > > > > > Subject > > > Re: Fw: [jira] > > > Assigned: > > > (AXISCPP-792) > > > Auto generated > > > deploy.wsdd file > > > has a bug. > > > > > > > > > > > > > > > Hi John, > > > We have this new mapping in the wsdd file, because in order to > > > pick the operation from the SOAP message, we have to be able to look > > > at the SOAP tag name and map it to the operation to invoke. This > > > mapping is mentioned in the WSDL and we capture this and put this in > > > wsdd file while generating service code. > > > The decision to place this in the server.wsdd came after looking > at > > > the way Axis Java is doing it. > > > I think allowed methods are there to hide some operations from > > > being invoked. Anyway, we already have logic to throw an exception > if > > > we do not have a method that is being requested by client. > > > > > > Thanks, > > > Samisa... > > > > > > On 8/12/05, John Hawkins <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Folks, > > > > > > > > I've been out of the loop on the server-wsdd file changes we had > to > > > do to > > > > get the server working without the SOAPAction so I apologise in > > > advance... > > > > Why do we have to have these extra mappings now? e.g. > > > add:addRequest? What > > > > is this for why isn't add just related to the add method on the > > > class? > > > > > > > > And why have allowed methods? Surely if we find that a method is > not > > > there > > > > then we can simply throw an exception back? > > > > > > > > thanks, > > > > John. > > > > > > > > > > > > ----- Forwarded by John Hawkins/UK/IBM on 12/08/2005 11:54 ----- > > > > > > > > "Chinthana Danapala (JIRA)" <[email protected]> > > > > > > > > 12/08/2005 10:39 > > > > > > > > Please respond to > > > > "Apache AXIS C Developers List" > > > > > > > > > > > > To [email protected] > > > > > > > > cc > > > > > > > > Subject [jira] Assigned: (AXISCPP-792) Auto generated deploy.wsdd > > > file has a > > > > bug. > > > > > > > > > > > > > > > > > > > > > > > > [ > > > > http://issues.apache.org/jira/browse/AXISCPP-792?page=all ] > > > > > > > > Chinthana Danapala reassigned AXISCPP-792: > > > > ------------------------------------------ > > > > > > > > Assign To: Chinthana Danapala > > > > > > > > > Auto generated deploy.wsdd file has a bug. > > > > > ------------------------------------------ > > > > > > > > > > Key: AXISCPP-792 > > > > > URL: > > > > http://issues.apache.org/jira/browse/AXISCPP-792 > > > > > Project: Axis-C++ > > > > > Type: Bug > > > > > Versions: 1.5 Final > > > > > Environment: Windows > > > > > Reporter: Chinthana Danapala > > > > > Assignee: Chinthana Danapala > > > > > Priority: Minor > > > > > > > > > > > > > > Deploy.WSDD file always written for support for Linux. > > > > > E.g. in calculator test > > > > > <service name="Calculator" provider="CPP:RPC" description="Axis > > > C++ web > > > > service"> > > > > > <parameter name="className" > > > > value="/user/local/apache/axis/Calculator.so"/> > > > > > <parameter > > > name="allowedMethods" > > > > value="add sub mul div "/> > > > > > <parameter > > > name="operationRequestMap" > > > > value="add:addRequest sub:subRequest mul:mulRequest div:divRequest > > > "/> > > > > > </service> > > > > > In Windows it should Calculator.dll not Calculator.so. > > > > > > > > -- > > > > This message is automatically generated by JIRA. > > > > - > > > > If you think it was sent incorrectly contact one of the > > > administrators: > > > > http://issues.apache.org/jira/secure/Administrators.jspa > > > > - > > > > For more information on JIRA, see: > > > > http://www.atlassian.com/software/jira > > > > > > > > > > -- > > Samisa Abeysinghe <[EMAIL PROTECTED]> > > Virtusa Corporation
