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? > 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]
