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? thanks, Amila. > Did somebody actually check what happens in Synapse > when NonBlockingLocalTransportSender is made compliant with the Axis2 > API? Some time ago there was a similar problem with other transports > (WSCOMMONS-444) and the conclusion was that it required a change in > Synapse to make these transports work properly with both Axis2 and > Synapse. It is likely that this fix in Synapse also covers the case of > NonBlockingLocalTransportSender. > > Andreas > > On Tue, Jul 26, 2011 at 11:22, Amila Suriarachchi > <[email protected]> wrote: > > > > > > On Mon, Jul 25, 2011 at 10:55 PM, Andreas Veithen > > <[email protected]> wrote: > >> > >> Just to summarize: > >> > >> * We have added a NonBlockingLocalTransportSender into the Axis2 code > >> base that doesn't respect the Axis2 APIs and that only works in > >> Synapse (see AXIS2-4944). > >> * I took us 5 JIRA issues (AXIS2-4967, AXIS2-5035, AXIS2-5036, > >> AXIS2-5037 and AXIS2-5043) to add a TransportListener for the local > >> transport. That TransportListener only implements the methods to > >> calculate the EPR, but it actually calculates the wrong EPR (see > >> AXIS2-5043). > >> * Now the proposal is to hardcode something into the kernel to exclude > >> these EPRs from WSDL generation. > >> > >> Can somebody please explain me what we are trying to achieve here? > > > > If you go through this thread you can see the answers. But let me tell > you > > again. > > > > 1. Exposing a service only with local transport. The motivation is the > > security. When you expose a service only with local transport then that > > service is automatically secured. Can you suggest a way to do this with > > Axis2 1.6? > > > > 2. Second is to improve the existing local transport to work within a > > synapse proxy service. This does not have a use case only at axis2 level > > (same as axis2 can't use synapse nhttp transport to send/receive > messages). > > But I think improving the existing thing rather than having a separate > > transport in synapse does not make any problem. > > > > thanks, > > Amila. > > > > > >> > >> Andreas > >> > >> On Mon, Jul 4, 2011 at 15:06, Heshan Suriyaarachchi > >> <[email protected]> wrote: > >> > Hi Amila, > >> > > >> > On Sat, Jun 25, 2011 at 12:29 PM, Amila Suriarachchi > >> > <[email protected]> wrote: > >> >> > >> >> > >> >> On Mon, Jun 20, 2011 at 10:55 AM, Heshan Suriyaarachchi > >> >> <[email protected]> wrote: > >> >>> > >> >>> Hi Andreas, > >> >>> So, in that case does that mean, we are going to > >> >>> 1) revert all the improvements did to the local transport OR > >> >>> 2) just remove the NonBlockingTransportListener class only? > >> >>> If it is the first option, then we have to improve the local > transport > >> >>> in > >> >>> such a way that a user should be able to extended the local > transport > >> >>> implementation and write a custom implementation. That will help us > to > >> >>> move > >> >>> the Synapse specific local transport to Synapse itself. > >> >>> If it is the second option, then we wont have to change that much of > >> >>> code > >> >>> level change. > >> >>> Although we have discussed about local transport here, my original > >> >>> question still remains ie. improving WSDL generation logic to > support > >> >>> WSDL > >> >>> generation for serivces that is only exposed in local transport. > >> >> > >> >> Can you please test the given patch with the attached local transport > >> >> sender. This should allow you to export the service with only local > >> >> transport. > >> >> > >> >> It has hard coded the name local. but if you see this method same > thing > >> >> has done for http and https as well. > >> > > >> > I tested your patch and with the given patch, the local endpoints are > >> > not > >> > shown in the generated WSDL. I have created a jira [1] to track the > >> > issue. > >> > There were some test failures and I will fix them and attach the patch > >> > to > >> > the jira. > >> > > >> > [1] - https://issues.apache.org/jira/browse/AXIS2-5085 > >> >> > >> >> thanks, > >> >> Amila. > >> >>> > >> >>> On Thu, Jun 16, 2011 at 1:09 PM, Andreas Veithen > >> >>> <[email protected]> wrote: > >> >>>> > >> >>>> Since there is a consensus that NonBlockingLocalTransportSender > >> >>>> doesn't work with a pure Axis2 setup, is not unit testable and is > >> >>>> only > >> >>>> relevant for Synapse, the logical conclusion would be that it > should > >> >>>> not be included in Axis2 but in Synapse. > >> >>>> > >> >>>> Andreas > >> >>>> > >> >>>> On Thu, Jun 16, 2011 at 08:43, Heshan Suriyaarachchi > >> >>>> <[email protected]> wrote: > >> >>>> > > >> >>>> > > >> >>>> > On Wed, Jun 15, 2011 at 1:27 AM, Andreas Veithen > >> >>>> > <[email protected]> > >> >>>> > wrote: > >> >>>> >> > >> >>>> >> On Tue, Jun 14, 2011 at 08:48, Heshan Suriyaarachchi > >> >>>> >> <[email protected]> wrote: > >> >>>> >> > Hi Devs, > >> >>>> >> > I am opening up this thread to discuss $subject. > >> >>>> >> > Recently, I did some improvements [1] to the Axis2 local > >> >>>> >> > transport, > >> >>>> >> > inorder > >> >>>> >> > to get it working against Synapse nhttp transport. Now the > local > >> >>>> >> > transport > >> >>>> >> > is working fine against the nhttp transport. > >> >>>> >> > >> >>>> >> To me the statement "getting transport A working against > transport > >> >>>> >> B" > >> >>>> >> doesn't make sense. Two distinct transports A and B never > interact > >> >>>> >> directly. Each of them interacts with the Axis2 engine through > (in > >> >>>> >> principle) well defined APIs. If a component (Synapse in this > >> >>>> >> case) > >> >>>> >> based on Axis2 has an issue when using A and B together, then > >> >>>> >> either > >> >>>> >> transport A, transport B, the component or the Axis2 engine has > an > >> >>>> >> issue (or multiple components have an issue), but saying that > >> >>>> >> transport A needs to be fixed to work with transport B doesn't > >> >>>> >> make > >> >>>> >> sense and is an indication that the fundamental issue has not > been > >> >>>> >> identified properly. > >> >>>> >> > >> >>>> >> At this point, what we know is this: > >> >>>> >> * NHTTP doesn't work as a transport sender in a standard Axis2 > >> >>>> >> setup > >> >>>> >> [1]. It only works in Synapse. That means that from the point of > >> >>>> >> view > >> >>>> >> of Axis2, the NHTTP transport is broken. That is of course OK, > >> >>>> >> because > >> >>>> >> NHTTP is shipped with Synapse and nobody claims that it is > >> >>>> >> supported > >> >>>> >> in a plain Axis2 setup. > >> >>>> >> * At some point I tried to figure out what would need to be > >> >>>> >> changed > >> >>>> >> to > >> >>>> >> make the NHTTP transport work in Axis2. IIRC the conclusion was > >> >>>> >> that > >> >>>> >> one can make it work in Axis2, but then it no longer works in > >> >>>> >> Synapse. > >> >>>> >> This would indicate that Synapse actually uses the transport API > >> >>>> >> in a > >> >>>> >> way it was not designed for. > >> >>>> >> * As indicated in AXIS2-4944, the current version of > >> >>>> >> NonBlockingLocalTransportSender doesn't work in Axis2. Unless > >> >>>> >> somebody > >> >>>> >> can come up with a valid unit test that exercises this piece of > >> >>>> >> code, > >> >>>> >> this would mean that we introduced a broken piece of code in > Axis2 > >> >>>> >> in > >> >>>> >> order to work around another broken piece of code in a > downstream > >> >>>> >> project. That is of course not OK. > >> >>>> >> > >> >>>> >> Note that the issue with NonBlockingLocalTransportSender is also > >> >>>> >> blocking the review of other issues such as AXIS2-4991, because > it > >> >>>> >> is > >> >>>> >> not possible to construct a unit test that validates (or > >> >>>> >> invalidates) > >> >>>> >> the proposed patch. That is BTW a general issue with the recent > >> >>>> >> patches for the local transport. As far as I can tell, none of > >> >>>> >> them > >> >>>> >> added any new unit tests. > >> >>>> >> > >> >>>> >> [1] At least that was my conclusion when I last looked at it. > I'm > >> >>>> >> ready to retract that claim if somebody comes up with an example > >> >>>> >> that > >> >>>> >> shows how to set up a simple Axis2 client that uses NHTTP as > >> >>>> >> outgoing > >> >>>> >> transport. > >> >>>> > > >> >>>> > As Amila has pointed out earlier, NonBlockingLocalTransportSender > >> >>>> > is > >> >>>> > used to > >> >>>> > talk to a proxy service from another proxy service. Since the > nhttp > >> >>>> > transport is written in a non blocking manner, > >> >>>> > NonBlockingLocalTransport > >> >>>> > will work seamlessly against nhttp transport. Since, we are using > >> >>>> > this > >> >>>> > TransportSender to talk between proxy services, it's difficult to > >> >>>> > come > >> >>>> > up > >> >>>> > with a test case (test client) for this particular usecase. > >> >>>> > > >> >>>> >> > >> >>>> >> > Now, my requirement is to expose an Synapse Proxy Service only > >> >>>> >> > in > >> >>>> >> > local > >> >>>> >> > transport. The reason behind is that, these proxy services > which > >> >>>> >> > are > >> >>>> >> > exposed > >> >>>> >> > only in local transport will be used by other proxy services > and > >> >>>> >> > will > >> >>>> >> > not be > >> >>>> >> > available for outside parties. Earlier, axis2 local transport > >> >>>> >> > did > >> >>>> >> > not > >> >>>> >> > have a > >> >>>> >> > TransportListener. > >> >>>> >> > With a TransportListener > >> >>>> >> > ==================== > >> >>>> >> > I introduced [2] a TransportListener to the local transport. > The > >> >>>> >> > transport > >> >>>> >> > listener's methods are used to calculate the endpoints for the > >> >>>> >> > service > >> >>>> >> > which > >> >>>> >> > will be used in generating the WSDL for the service. > Therefore, > >> >>>> >> > now > >> >>>> >> > if > >> >>>> >> > the > >> >>>> >> > service exposed in the local transport, the local endpoint is > >> >>>> >> > also > >> >>>> >> > shown > >> >>>> >> > in > >> >>>> >> > the WSDL. Although the local endpoints are shown in the WSDL, > >> >>>> >> > outside > >> >>>> >> > parties can not access the local endpoint. > >> >>>> >> > The problem this patch introduce is, now the WSDL shows the > >> >>>> >> > local > >> >>>> >> > transport > >> >>>> >> > endpoints. Which is wrong since external users can not access > >> >>>> >> > local > >> >>>> >> > transport. > >> >>>> >> > So the solution is not to show the local transport endpoints > in > >> >>>> >> > generated > >> >>>> >> > wsdl. For that we may have to change Axis2 code. > >> >>>> >> > eg: As an example, I am attaching the following resources to > >> >>>> >> > prove > >> >>>> >> > my > >> >>>> >> > point. > >> >>>> >> > The synapse-config.xml is the Synapse Configuration and the > >> >>>> >> > attached > >> >>>> >> > WSDLs > >> >>>> >> > are for the proxy servivces, LocalTransportProxy and > >> >>>> >> > SecondProxy. > >> >>>> >> > The > >> >>>> >> > SecondProxy is exposed only via the local transport and the > >> >>>> >> > local > >> >>>> >> > endpoints > >> >>>> >> > are shown in the WSDL which is wrong IMV. > >> >>>> >> > Without a TransportListener > >> >>>> >> > ====================== > >> >>>> >> > If we did not have a LocalTransportListener and if a service > is > >> >>>> >> > exposed > >> >>>> >> > through local transport only, the WSDL for the service will > not > >> >>>> >> > be > >> >>>> >> > generated. The reason behind is that; inorder to generate the > >> >>>> >> > WSDL, > >> >>>> >> > there > >> >>>> >> > should be a mechanism to derive the endpoints for the service. > >> >>>> >> > Since, > >> >>>> >> > the > >> >>>> >> > TransportListener is not there, there is no mechanism to > derive > >> >>>> >> > the > >> >>>> >> > endpoints for the service(which is only exposed through the > >> >>>> >> > local > >> >>>> >> > transport). > >> >>>> >> > In case the service exposed through http,https,local > transports; > >> >>>> >> > this > >> >>>> >> > wont > >> >>>> >> > be the case. Then the WSDL will be generated and only the > >> >>>> >> > http,https > >> >>>> >> > endpoints will be shown. > >> >>>> >> > Without the listener, if we expose a service only in local > >> >>>> >> > transport, > >> >>>> >> > WSDL > >> >>>> >> > generation fails since the endpoints can not be derived for > that > >> >>>> >> > particular > >> >>>> >> > service. > >> >>>> >> > > >> >>>> >> > Your ideas and feedback on $subject is much appreciated. > >> >>>> >> > [1] - https://issues.apache.org/jira/browse/AXIS2-4944 > >> >>>> >> > [2] - https://issues.apache.org/jira/browse/AXIS2-5043 > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > -- > >> >>>> >> > Regards, > >> >>>> >> > Heshan Suriyaarachchi > >> >>>> >> > > >> >>>> >> > http://heshans.blogspot.com/ > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > --------------------------------------------------------------------- > >> >>>> >> > To unsubscribe, e-mail: [email protected] > >> >>>> >> > For additional commands, e-mail: > [email protected] > >> >>>> >> > > >> >>>> >> > >> >>>> >> > >> >>>> >> > --------------------------------------------------------------------- > >> >>>> >> To unsubscribe, e-mail: [email protected] > >> >>>> >> For additional commands, e-mail: [email protected] > >> >>>> >> > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > -- > >> >>>> > Regards, > >> >>>> > Heshan Suriyaarachchi > >> >>>> > > >> >>>> > http://heshans.blogspot.com/ > >> >>>> > > >> >>>> > >> >>>> > --------------------------------------------------------------------- > >> >>>> To unsubscribe, e-mail: [email protected] > >> >>>> For additional commands, e-mail: [email protected] > >> >>>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Regards, > >> >>> Heshan Suriyaarachchi > >> >>> > >> >>> http://heshans.blogspot.com/ > >> >> > >> >> > >> >> > >> >> -- > >> >> Amila Suriarachchi > >> >> WSO2 Inc. > >> >> blog: http://amilachinthaka.blogspot.com/ > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> > > >> > > >> > > >> > -- > >> > Regards, > >> > Heshan Suriyaarachchi > >> > > >> > http://heshans.blogspot.com/ > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > > > > > -- > > Amila Suriarachchi > > WSO2 Inc. > > blog: http://amilachinthaka.blogspot.com/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
