Re: [Axis2] Summery of todays Hackathon
>>As Dennis suggested , having annon name as public static seems not that >>good , so we need to remove them I mean we need to make the private. >> >> > >Sorry I don't understand what you're referring to. If its the constants >we used to make the simple API work then I don't agree there's any >problem. > > I mean we want to make those public variable into private , currently there are four public static variable with annon name. > > >>Rather than giving two client API to client cant we have one API , we >>can have all the methods in serviceClient then no one need to know about >>the operationClient (service client will use that internally ). So our >>proposal is to add few more methods into ServiceCleint; >> >>public MessageContext sendReceive(MessageContext req){} >>public void sendReceiveNonBlocking(MessageContext req){} >>public fireAndForget(MessageContext req){} >>public sendRobust(MessageContext req){} >> >> > >This only works for the 4 built-in MEPs. Have we decided to narrow Axis2 >down to the built in MEPs? If so half of the machinery in Axis2 can be >removed. > > I didnt mean it , what I mean was those are the most commonly use MEP so adding those method into ServiceClinet provide a way to access message context and SOAPEnvelop w.o creating operation client. Yes , I agree that adding four methods make service client API bit ugly :) > > >>if we introduce these methods into ServiceClient then we do not too much >>worry about how to create operationClient etc... >> >>I am +1 on adding these four methods in to serviceClient. >> >> > >Sorry, I'm -1 to this change. No way. It fundamentally breaks the client >API > > Then forget abt that , I do not really want to break any fundamental design. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Summery of todays Hackathon
On Tue, 2006-10-10 at 17:54 -0500, Deepal Jayasinghe wrote: > Why do we need operation client ? ??? You gotta be kidding. We have it because that's the client API for a generic MEP. > As Dennis suggested , having annon name as public static seems not that > good , so we need to remove them I mean we need to make the private. Sorry I don't understand what you're referring to. If its the constants we used to make the simple API work then I don't agree there's any problem. > Rather than giving two client API to client cant we have one API , we > can have all the methods in serviceClient then no one need to know about > the operationClient (service client will use that internally ). So our > proposal is to add few more methods into ServiceCleint; > > public MessageContext sendReceive(MessageContext req){} > public void sendReceiveNonBlocking(MessageContext req){} > public fireAndForget(MessageContext req){} > public sendRobust(MessageContext req){} This only works for the 4 built-in MEPs. Have we decided to narrow Axis2 down to the built in MEPs? If so half of the machinery in Axis2 can be removed. > if we introduce these methods into ServiceClient then we do not too much > worry about how to create operationClient etc... > > I am +1 on adding these four methods in to serviceClient. Sorry, I'm -1 to this change. No way. It fundamentally breaks the client API If you want to do this then in the minimum it has to be after 1.1. No way we're going to change the client API after RC1 has been cut! > === > How do we reflect service group concept in to client , and manage > session using that. Well I do understand if we use Axis2 client <-> > Axis2 service this will work , but what if we use .Net client <-> Axis2 > Service. Is there any kind of specification sending session related data > in SOAP message ? , if there is such a thing then we need to use them. You're forgetting a design decision we made a while ago: to make the service group concept not visible to the outside. That's why we said services withing group become top level services. I was against it but that's what we decided. As such there's no need to expose it to the client. What will be useful is for one service in a group to be able to get the EPR of another service in a group. Something like ServiceGroupContext.getEPRForService ("serviceName"). That can propagate the contextID etc. so that they share the same interaction session. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Summery of todays Hackathon
Deepal, Please create JIRA issue(s) and let's work on them. thanks, dims On 10/10/06, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: Hi All; Few note from todays Hackathon we had at ApacheCon US. We are having very ugly name called finalizeInvoke() in service client with restriction, so we (Glen and I agreed) to remove that method and move the code into cleanup (well I am doing the changes in current codebase). Why do we need operation client ? As Dennis suggested , having annon name as public static seems not that good , so we need to remove them I mean we need to make the private. Rather than giving two client API to client cant we have one API , we can have all the methods in serviceClient then no one need to know about the operationClient (service client will use that internally ). So our proposal is to add few more methods into ServiceCleint; public MessageContext sendReceive(MessageContext req){} public void sendReceiveNonBlocking(MessageContext req){} public fireAndForget(MessageContext req){} public sendRobust(MessageContext req){} if we introduce these methods into ServiceClient then we do not too much worry about how to create operationClient etc... I am +1 on adding these four methods in to serviceClient. === How do we reflect service group concept in to client , and manage session using that. Well I do understand if we use Axis2 client <-> Axis2 service this will work , but what if we use .Net client <-> Axis2 Service. Is there any kind of specification sending session related data in SOAP message ? , if there is such a thing then we need to use them. Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Summery of todays Hackathon
Hi All; Few note from todays Hackathon we had at ApacheCon US. We are having very ugly name called finalizeInvoke() in service client with restriction, so we (Glen and I agreed) to remove that method and move the code into cleanup (well I am doing the changes in current codebase). Why do we need operation client ? As Dennis suggested , having annon name as public static seems not that good , so we need to remove them I mean we need to make the private. Rather than giving two client API to client cant we have one API , we can have all the methods in serviceClient then no one need to know about the operationClient (service client will use that internally ). So our proposal is to add few more methods into ServiceCleint; public MessageContext sendReceive(MessageContext req){} public void sendReceiveNonBlocking(MessageContext req){} public fireAndForget(MessageContext req){} public sendRobust(MessageContext req){} if we introduce these methods into ServiceClient then we do not too much worry about how to create operationClient etc... I am +1 on adding these four methods in to serviceClient. === How do we reflect service group concept in to client , and manage session using that. Well I do understand if we use Axis2 client <-> Axis2 service this will work , but what if we use .Net client <-> Axis2 Service. Is there any kind of specification sending session related data in SOAP message ? , if there is such a thing then we need to use them. Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]