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/
