I guess my thoughts are that any changes should not break conventions within Axis2. We should follow standards and conventions.
Nadir Amra Integrated Web Services for IBM i Operating System Internet: [email protected] Andreas Veithen <[email protected]> wrote on 07/27/2011 06:55:17 AM: > From: Andreas Veithen <[email protected]> > To: [email protected] > Date: 07/27/2011 06:56 AM > Subject: Re: WSDL generation for the services exposed only in local transport > > On Wed, Jul 27, 2011 at 13:13, Amila Suriarachchi > <[email protected]> wrote: > > > > > > On Wed, Jul 27, 2011 at 2:04 PM, Andreas Veithen <[email protected]> > > wrote: > >> > >> On Wed, Jul 27, 2011 at 07:52, Amila Suriarachchi > >> <[email protected]> wrote: > >> > > >> > > >> > On Wed, Jul 27, 2011 at 10:45 AM, Amila Suriarachchi > >> > <[email protected]> wrote: > >> >> > >> >> > >> >> On Tue, Jul 26, 2011 at 6:07 PM, Andreas Veithen > >> >> <[email protected]> wrote: > >> >>> > >> >>> So, the bottom line is that it is OK to introduce a component into > >> >>> Axis2 that violates the Axis2 API (NonBlockingLocalTransportSender > >> >>> sets an incorrect value for the serverSide property) and it is not > >> >>> worth trying to understand how this can be fixed such that it works > >> >>> both in a pure Axis2 context and in Synapse? > >> >> > >> >> Here no new component is introduced. It is improving an existing thing. > >> >> > >> >> > >> >>> > >> >>> NonBlockingLocalTransportSender actually works just fine with the > >> >>> ServiceClient API if the incorrect code is changed so that it sets > >> >>> serverSide=false. > >> >> > >> >> Which line you talk about? if your concern about this property? > >> > > >> > And also how to define the server side and client side of Axis2? Can you > >> > please explain why it works with server side false and not server side > >> > true? > >> > >> serverSide is set to true if and only if the message context > >> corresponds to an incoming message received by a transport listener. > > > > if you look at where isServerSide is used it is used in the AxisEngine as a > > means of kipping the message receiver invocation. But in synapse it always > > registers a callback handler and hence this parameter is needed. > > > > And also if you make this parameter twice I think it calls > > AxisEngine.receive twice. > > > > Heshan can you please double check this? > > > > If someone wants to do a local transport in axis2 level then they can always > > use the existing local transport sender and the new code does not make any > > alternation to the existing transport execution paths. What is the reason > > for making NonBlockingLocalTransport sender also making the same usage? The > > idea of NonBlockingLocal transport is to make it work even the response > > receives in a different thread. > > > > Axis2 is a project one can use as it is. But there are some other projects > > use it as a library as well. And also local transport is not a part of axis2 > > kernel. So I still think it is reasonable improvement to existing local > > transport to make it work with synapse. > > > > thanks, > > Amila. > > > > I don't know any project that (knowingly) ships code that is not > interoperable with its own API. If the community is OK to go down that > road and starts doing such things, then this will likely be a turning > point in the evolution of the project. > > Anyway, it is likely that the fix in Synapse done by Ruwan for > WSCOMMONS-444 also solves the issue with NonBlockingLocalTransport and > that the argument that we need two different local transports > completely breaks down. Therefore I repeat my question: Did somebody > actually check what happens in Synapse when > NonBlockingLocalTransportSender is made compliant with the Axis2 API? > Or did you guys completely ignore my comment in AXIS2-4944? > > >>
