On Fri, Jul 29, 2011 at 08:15, Amila Suriarachchi <[email protected]> wrote: > > > On Fri, Jul 29, 2011 at 1:31 AM, Andreas Veithen <[email protected]> > wrote: >> >> On Thu, Jul 28, 2011 at 08:49, Amila Suriarachchi >> <[email protected]> wrote: >> > >> > >> > On Wed, Jul 27, 2011 at 5:25 PM, Andreas Veithen >> > <[email protected]> >> > wrote: >> >> >> >> 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? >> > >> > I did check your suggestion with Axis2. It passes the test as you have >> > mentioned. >> > >> > But it hits AxisEngine.receive twice. One from the handleResponse of the >> > localResponder and other one is >> > handleResponse method of the OutIn operation. So it is not a proper fix. >> >> The JMS transport also invokes AxisEngine.receive for the response >> message. Does this mean that we have the same problem (double >> invocation of AxisEngine.receive) there too? > > I am not sure. If you look at the commons http transport you will see after > getting the response it just saves the message and returns without calling > AxisEngine.receive.
I made a statement about the JMS transport. Why do you reply with a statement about the HTTP transport? > AxisEngine.receive is called by OutInAxisOperationClient. > > And also you can see here[1] serverSide is set to true. But it is not > invoked through a listener thread. > > What I try to say is that there is not such convention as you have defined. > But people use this property appropriate manner depending on whether they > want to invoke the message receiver or not. Whether or not a message receiver should be invoked is a concern of the operation client and the kernel. It is not a concern of the transport. Your argument means that when writing a transport, one has to take into account how the operation client interacts with the kernel. This introduces a strong coupling between the transport and the application code. If we declare that this is OK, then this is an indication that Axis2 has started to degenerate from a framework (which implies some degree of architectural consistency) into a mere library that provides components to downstream projects without enforcing a consistent architecture and programming model. > As I mentioned earlier I agree that the NonBlockingLocalTransport is only > useful with synapse. But it having here as an improvement to existing local > transport is more sensible options to take. > > thanks, > Amila. > > [1] > https://svn.apache.org/repos/asf/axis/axis2/java/core/branches/1_6/modules/transport/local/src/org/apache/axis2/transport/local/LocalTransportReceiver.java > > > >> >> > As I mentioned earlier reason for this is the two thread models (which >> > are >> > not enforced through and API) assumed by the synapse and Axis2. >> > >> > thanks, >> > Amila. >> > >> >> >> >> Or did you guys completely ignore my comment in AXIS2-4944? >> >> >> >> >> >> >> >> All transports in the Axis2 project (including the Transports >> >> >> project) >> >> >> satisfy this requirement, except for NonBlockingLocalTransportSender >> >> >> which is the reason why it doesn't work. See my comment in >> >> >> AXIS2-4944 >> >> >> for more information about where the incorrect code is located and >> >> >> how >> >> >> to test this. >> >> >> >> >> >> > thanks, >> >> >> > Amila. >> >> >> >> >> >> >> >> 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/ >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > 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/ >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> 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/ > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
