axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: WSDL generation for the services exposed only in local transport
Date Mon, 01 Aug 2011 21:16:57 GMT
On Fri, Jul 29, 2011 at 08:15, Amila Suriarachchi
<amilasuriarachchi@gmail.com> wrote:
>
>
> On Fri, Jul 29, 2011 at 1:31 AM, Andreas Veithen <andreas.veithen@gmail.com>
> wrote:
>>
>> On Thu, Jul 28, 2011 at 08:49, Amila Suriarachchi
>> <amilasuriarachchi@gmail.com> wrote:
>> >
>> >
>> > On Wed, Jul 27, 2011 at 5:25 PM, Andreas Veithen
>> > <andreas.veithen@gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Jul 27, 2011 at 13:13, Amila Suriarachchi
>> >> <amilasuriarachchi@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Wed, Jul 27, 2011 at 2:04 PM, Andreas Veithen
>> >> > <andreas.veithen@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Wed, Jul 27, 2011 at 07:52, Amila Suriarachchi
>> >> >> <amilasuriarachchi@gmail.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Jul 27, 2011 at 10:45 AM, Amila Suriarachchi
>> >> >> > <amilasuriarachchi@gmail.com> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> On Tue, Jul 26, 2011 at 6:07 PM, Andreas Veithen
>> >> >> >> <andreas.veithen@gmail.com> 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
>> >> >> >>> <amilasuriarachchi@gmail.com> wrote:
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > On Mon, Jul 25, 2011 at 10:55 PM, Andreas Veithen
>> >> >> >>> > <andreas.veithen@gmail.com> 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
>> >> >> >>> >> <heshan.suriyaarachchi@gmail.com> wrote:
>> >> >> >>> >> > Hi Amila,
>> >> >> >>> >> >
>> >> >> >>> >> > On Sat, Jun 25, 2011 at 12:29 PM, Amila Suriarachchi
>> >> >> >>> >> > <amilasuriarachchi@gmail.com> wrote:
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >> On Mon, Jun 20, 2011 at 10:55 AM, Heshan Suriyaarachchi
>> >> >> >>> >> >> <heshan.suriyaarachchi@gmail.com> 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
>> >> >> >>> >> >>> <andreas.veithen@gmail.com> 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
>> >> >> >>> >> >>>> <heshan.suriyaarachchi@gmail.com> wrote:
>> >> >> >>> >> >>>> >
>> >> >> >>> >> >>>> >
>> >> >> >>> >> >>>> > On Wed, Jun 15, 2011 at 1:27 AM, Andreas Veithen
>> >> >> >>> >> >>>> > <andreas.veithen@gmail.com>
>> >> >> >>> >> >>>> > wrote:
>> >> >> >>> >> >>>> >>
>> >> >> >>> >> >>>> >> On Tue, Jun 14, 2011 at 08:48, Heshan Suriyaarachchi
>> >> >> >>> >> >>>> >> <heshan.suriyaarachchi@gmail.com> 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:
>> >> >> >>> >> >>>> >> > java-dev-unsubscribe@axis.apache.org
>> >> >> >>> >> >>>> >> > For additional commands, e-mail:
>> >> >> >>> >> >>>> >> > java-dev-help@axis.apache.org
>> >> >> >>> >> >>>> >> >
>> >> >> >>> >> >>>> >>
>> >> >> >>> >> >>>> >>
>> >> >> >>> >> >>>> >>
>> >> >> >>> >> >>>> >>
>> >> >> >>> >> >>>> >>
>> >> >> >>> >> >>>> >>
>> >> >> >>> >> >>>> >> ---------------------------------------------------------------------
>> >> >> >>> >> >>>> >> To unsubscribe, e-mail:
>> >> >> >>> >> >>>> >> java-dev-unsubscribe@axis.apache.org
>> >> >> >>> >> >>>> >> For additional commands, e-mail:
>> >> >> >>> >> >>>> >> java-dev-help@axis.apache.org
>> >> >> >>> >> >>>> >>
>> >> >> >>> >> >>>> >
>> >> >> >>> >> >>>> >
>> >> >> >>> >> >>>> >
>> >> >> >>> >> >>>> > --
>> >> >> >>> >> >>>> > Regards,
>> >> >> >>> >> >>>> > Heshan Suriyaarachchi
>> >> >> >>> >> >>>> >
>> >> >> >>> >> >>>> > http://heshans.blogspot.com/
>> >> >> >>> >> >>>> >
>> >> >> >>> >> >>>>
>> >> >> >>> >> >>>>
>> >> >> >>> >> >>>>
>> >> >> >>> >> >>>>
>> >> >> >>> >> >>>>
>> >> >> >>> >> >>>> ---------------------------------------------------------------------
>> >> >> >>> >> >>>> To unsubscribe, e-mail:
>> >> >> >>> >> >>>> java-dev-unsubscribe@axis.apache.org
>> >> >> >>> >> >>>> For additional commands, e-mail:
>> >> >> >>> >> >>>> java-dev-help@axis.apache.org
>> >> >> >>> >> >>>>
>> >> >> >>> >> >>>
>> >> >> >>> >> >>>
>> >> >> >>> >> >>>
>> >> >> >>> >> >>> --
>> >> >> >>> >> >>> Regards,
>> >> >> >>> >> >>> Heshan Suriyaarachchi
>> >> >> >>> >> >>>
>> >> >> >>> >> >>> http://heshans.blogspot.com/
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >> --
>> >> >> >>> >> >> Amila Suriarachchi
>> >> >> >>> >> >> WSO2 Inc.
>> >> >> >>> >> >> blog: http://amilachinthaka.blogspot.com/
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >> ---------------------------------------------------------------------
>> >> >> >>> >> >> To unsubscribe, e-mail:
>> >> >> >>> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> >>> >> >> For additional commands, e-mail:
>> >> >> >>> >> >> java-dev-help@axis.apache.org
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >> > --
>> >> >> >>> >> > Regards,
>> >> >> >>> >> > Heshan Suriyaarachchi
>> >> >> >>> >> >
>> >> >> >>> >> > http://heshans.blogspot.com/
>> >> >> >>> >> >
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >> ---------------------------------------------------------------------
>> >> >> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> >>> >> For additional commands, e-mail:
>> >> >> >>> >> java-dev-help@axis.apache.org
>> >> >> >>> >>
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > --
>> >> >> >>> > Amila Suriarachchi
>> >> >> >>> > WSO2 Inc.
>> >> >> >>> > blog: http://amilachinthaka.blogspot.com/
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> ---------------------------------------------------------------------
>> >> >> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Amila Suriarachchi
>> >> >> >> WSO2 Inc.
>> >> >> >> blog: http://amilachinthaka.blogspot.com/
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Amila Suriarachchi
>> >> >> > WSO2 Inc.
>> >> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >> >
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message