axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Suriarachchi <amilasuriarach...@gmail.com>
Subject Re: WSDL generation for the services exposed only in local transport
Date Tue, 02 Aug 2011 08:47:35 GMT
On Tue, Aug 2, 2011 at 2:46 AM, Andreas Veithen
<andreas.veithen@gmail.com>wrote:

> 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.


yes. I think no one has to say it is ok or not. Simply it is the way it has
written.

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.
>

I think just having an improvement to local transport doesn't make such a
big impact :)

thanks,
Amila.

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


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Mime
View raw message