>>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]
