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/
