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/
